date:20120130

> Mark Morgan Lloyd wrote on Mon, 30 Jan 2012 21:46:28 +
> 
> Although Linux/390 is closer to what the bulk of us are used to, so 
> please humour us.
 
I am a Linux user so I am sympathetic.  It's just that I really don't do
development on Linux and am therefore unaware of it's requirements.

> One question if I may, and I hope this doesn't sound too stupid. When 
> Paul Robinson first raised an S/390 port a few days ago, he proposed 
> using MUSIC/SP as his target operating system. This has the advantages 
> that it's free and has TCP/IP, but the major disadvantage that the prime 
> maintainer is... no longer active. I find it difficult keeping track of 
> things on account of the name changes over the years: what is the 
> situation as regards OS, is there a free version that can be run locally 
> under (e.g.) Hercules, or would anybody who wanted to look at what you 
> were up to have to have a login account on a mainframe somewhere? Or 
> does MUSIC/SP have any/adequate binary compatibility?

Why should it sound stupid?  I've spent 25 years doing this stuff, I can't
reasonably expect everyone else to know how it works.

MUSIC/SP as I understand it (from wikipedia I'm afraid) was a proprietry time
sharing system writtem by McGill university in the states.  It's sole use to
us in this discussion was that it had an OS/VS1 emulation mode.  OS/VS1 had 
no terminal based development environment at all (at least not a standard IBM
one.  It did, later, have systems called TONE and ROSCOE).  I think Paul chose
this because he either knew it was available or because it was the system
he used to use.  OS/VS1 has hideous storage limitations by todays standards.
However, this emulation mode should give us a good binary comatibilty level
storage limitations allowing.

Hercules can run all, or almost all, IBM OS systems. from OS/MFT - OS/MVT
from the 1960's up to the latest z/OS 64 bit systems.  The problem is with
licensing.  The ones we can run legally are OS/MFT, OS/MVT, OS/VS2, MVS 3.8
along with various others such as early DOS and VM systems and MUSIC/SP.  All
of these are free.

These, generally, don't have TCP/IP yet, but Hercules provides us with TCP/IP
connection using TN3270 (telnet in 3270 mode) so we can use Linux or Windows
based terminal emulators such as x3270 to connect to the guests. People are
working on a TCP/IP stack for MVS.

It's also possible to have a logon to a remote MVS system running inside a
window running in your favourite web browser.  I can't find it on the web
at the moment and I don't know what version of MVS it used, but I will keep
an eye out for it.
 
> But as I understand it JCL is distinct from binary programs- different 
> areas of application, different facilities. On the unix-derived systems 
> that most of us are more used to there is no such distinction: a shell 
> script has access to all the facilities that a binary has, you could (in 
> principle) write a compiler in it.

But we don't need to write a compiler, we just need to feed various source
programs into a compiler and assemble and linkedit the resulting output with
a modicum of "intelligence"  to stop on errors.  This is what JCL does.
Think of it as using a pipe to link the output of one program into the input
of another, just not as straightforward.  

You can use the terminal script languages to write more complicated stuff,
CLIST the original would probably be capable of this, I wouldn't want to
write it though because it's ghastly.  But REXX is available for MVS 3.8
and REXX can do anything! :)

--
Regards
Steve
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: EBCDIC ( was On a port of Free Pascal to the IBM 370)

2012-01-30 Thread Tomas Hajny

On 30 Jan 12, at 20:38, Sven Barth wrote:
> On 30.01.2012 20:31, steve smithers wrote:
> >> Hans-Peter Diettrich wrote on Mon, 30 Jan 2012 17:40:27 +0100
> >> Existing source code frequently assumes ASCII encoding. The obvious are
> >> upper/lowercase conversions, by and/or or add/sub constant values to the
> >> characters. It will be hell to find and fix all such code in the
> >> compiler and RTL, even if only the constants have to be modified for
> >> EBCDIC. Even code with the assumed order of common characters (' '<  '0'
> >> <  'A'<  'a') has to be found and fixed manually - how would you even
> >> *find* code with such implicit assumptions?
> >
> > It does indeed.  I am aware of the problems inherent in this.  But the RTL
> > has to be more or less rewritten anyway to support OS.  OS is a very 
> > different
> > animal to Windows or Linux.
> 
> The RTL consists of two parts (though the border is not easily visible): 
> a platform independant one and a platform dependant one. A port to a 
> different target normally only includes touching the platform dependant 
> one, but a port to 370 also requires touching the platform independant 
> one. This is what DoDi talks about.
> 
> @other devs: Could the code page aware AnsiString type be of any help here?

I suspect that this would not be enough since there are still hard-
coded assumption about control codes to be located in #0..#31 on all 
SBCS encodings, etc.

Tomas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)


steve smithers wrote:

I seem to have messed up the subject lines on some of these posts.  Sorry.


Don't worry about it.


It's not any problem to move the binary itself, but there is more required
than the binary itself in order to produce an executable load module on any
OS version.  (I can't comment on VM or DOS cause they are a mystery to me).
An OS binary consists of more than the binary and I know of no way to build
that information on Linux or Windows.

That's not the case when the target is Linux: as with all distreaux and 
variants, the program compiles to a single file:



Yeah.  Hence the repeated references to OS :)  I have had no contact with
Linux/390 so I can't possibly comment.


Although Linux/390 is closer to what the bulk of us are used to, so 
please humour us.


One question if I may, and I hope this doesn't sound too stupid. When 
Paul Robinson first raised an S/390 port a few days ago, he proposed 
using MUSIC/SP as his target operating system. This has the advantages 
that it's free and has TCP/IP, but the major disadvantage that the prime 
maintainer is... no longer active. I find it difficult keeping track of 
things on account of the name changes over the years: what is the 
situation as regards OS, is there a free version that can be run locally 
under (e.g.) Hercules, or would anybody who wanted to look at what you 
were up to have to have a login account on a mainframe somewhere? Or 
does MUSIC/SP have any/adequate binary compatibility?


We look forward to your notes. My understanding is that at least one 
variant of FPC (the one targeting x86) can use multiple assembler 
notations, so the exact format of the assembly source might turn out not 
to be a problem. More of a problem would be is 370 Assembler conventions 
turned out to be incompatible with FPC code generation.
 
That sounds useful.


Once a initial port to 370 has been made and the assembler output 
generator is implemented (which means that the compiler can basically 
generate 370 capable assembler files) this is rather easy as FPC can 
generate "link on target" scripts (and AFAIK also "assemble on target").


That too!
 
Assuming that the target operating system has any concept of an 
executable script. Steve's already told us that you can't generate a 
binary externally, and it might turn out that the compiler will have to 
generate a JCL (or comparable) deck which is then processed in some way 
on the target rather than being executed directly.


JCL IS an executable script.  But there are terminal based scripting
facilities available too.  Running such a task on a terminal however,
would have less storage available to it.


But as I understand it JCL is distinct from binary programs- different 
areas of application, different facilities. On the unix-derived systems 
that most of us are more used to there is no such distinction: a shell 
script has access to all the facilities that a binary has, you could (in 
principle) write a compiler in it.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS


Andrew Haines wrote:

On 01/30/12 07:19, Mark Morgan Lloyd wrote:

Nikolai Zhubr wrote:

Hi,
29.01.2012 19:32, Jy V:
[...]

on the WNDR3800 the OpenWRT installed gives
root@OpenWrt:~# uname -a
Linux OpenWrt 2.6.32.27 #5 Wed Dec 21 01:59:33 CET 2011 mips GNU/Linux

I've got wndr3800 too, and moreover I don't use it for the moment. So
instead of collecting dust it could do something usefull. Installing
debian on it will probably not be as quick and easy as openwrt but
still if debian mips userspace is able to run on it, I could give it a
try and then ssh will be available for FPC developers if installation
succeeds. It is apparently big endian though. Would it make sense to try?

Bear in mind that there's Debian for both endiannesses of MIPS, I'm
running mipsel via Qemu to reasonable effect. Experience with small ARM
systems suggests that having enough memory is crucial, 128Mb with swap
to 512 should be OK but these days I'd not like to try smaller.

But I don't know to what extent trying to implement the compiler and
runtimes for mips and mipsel simultaneously would complicate things.



I spent a little time researching qemu with MIPS but couldn't find
anything current. Can you give me some pointers on setting that up?


http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators

Note that on that page I've rolled several Debian guest systems together 
into one section, showing appropriate differences in configuration files 
etc. Some of the scripts I've given are probably a bit idiosyncratic, 
but they're what I've found has worked for me over the 5+ years I've 
been using Qemu on various systems.


Most guest systems are built (not by me) to expect that they can display 
their console in an xterm. I normally start up in a VNC session, then 
log in over SSH.


Please yell if anything's unclear.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)

I seem to have messed up the subject lines on some of these posts.  Sorry.

>> It's not any problem to move the binary itself, but there is more required
>> than the binary itself in order to produce an executable load module on any
>> OS version.  (I can't comment on VM or DOS cause they are a mystery to me).
>> An OS binary consists of more than the binary and I know of no way to build
>> that information on Linux or Windows.
>>
> 
> That's not the case when the target is Linux: as with all distreaux and 
> variants, the program compiles to a single file:
> 
Yeah.  Hence the repeated references to OS :)  I have had no contact with
Linux/390 so I can't possibly comment.
> 
> We look forward to your notes. My understanding is that at least one 
> variant of FPC (the one targeting x86) can use multiple assembler 
> notations, so the exact format of the assembly source might turn out not 
> to be a problem. More of a problem would be is 370 Assembler conventions 
> turned out to be incompatible with FPC code generation.
 
That sounds useful.

> > Once a initial port to 370 has been made and the assembler output 
> > generator is implemented (which means that the compiler can basically 
> > generate 370 capable assembler files) this is rather easy as FPC can 
> > generate "link on target" scripts (and AFAIK also "assemble on target").

That too!
 
> Assuming that the target operating system has any concept of an 
> executable script. Steve's already told us that you can't generate a 
> binary externally, and it might turn out that the compiler will have to 
> generate a JCL (or comparable) deck which is then processed in some way 
> on the target rather than being executed directly.

JCL IS an executable script.  But there are terminal based scripting
facilities available too.  Running such a task on a terminal however,
would have less storage available to it.

--
Regards,
Steve
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS

2012-01-30 Thread Andrew Haines

On 01/30/12 07:19, Mark Morgan Lloyd wrote:
> Nikolai Zhubr wrote:
>> Hi,
>> 29.01.2012 19:32, Jy V:
>> [...]
>>> on the WNDR3800 the OpenWRT installed gives
>>> root@OpenWrt:~# uname -a
>>> Linux OpenWrt 2.6.32.27 #5 Wed Dec 21 01:59:33 CET 2011 mips GNU/Linux
>>
>> I've got wndr3800 too, and moreover I don't use it for the moment. So
>> instead of collecting dust it could do something usefull. Installing
>> debian on it will probably not be as quick and easy as openwrt but
>> still if debian mips userspace is able to run on it, I could give it a
>> try and then ssh will be available for FPC developers if installation
>> succeeds. It is apparently big endian though. Would it make sense to try?
> 
> Bear in mind that there's Debian for both endiannesses of MIPS, I'm
> running mipsel via Qemu to reasonable effect. Experience with small ARM
> systems suggests that having enough memory is crucial, 128Mb with swap
> to 512 should be OK but these days I'd not like to try smaller.
> 
> But I don't know to what extent trying to implement the compiler and
> runtimes for mips and mipsel simultaneously would complicate things.
> 

I spent a little time researching qemu with MIPS but couldn't find
anything current. Can you give me some pointers on setting that up?

Andrew
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS


Pierre Free Pascal wrote:
Anyhow, I just discovered that 
the /home directory is 99% full on that GCC compile farm machine,

meaning that only  remote tests will be possible ☹

It seems that lots of developers have the same issue about finding 
MIPS machines for testing ….

Would you consider the NetGear WNDR3800 680Mhz, 128MB RAM with a USB Flash 
drive of 32GB to be good enough for the development of the FPC toolchain ?
(in this case, I can purchase and ship such device to your place),

or would you consider that only a qemu virtual MIPS machine which can handle 
more memory and more disk space to be suitable for the development ?


  I just googled a bit and read that the
USB flash drives are considered as having only a limited number of writes
before that fail... (http://en.wikipedia.org/wiki/USB_flash_drive)
So I wonder how long such a system like that would last (it probably also depends on 
the USB key quality itself?) if I run the testsuite each night

on it...

 Would a small USB hard drive be better? But does the device
have enough power to support such an external drive?
Would the speed be significantly lower or is the USB 2.0 
speed the real limitation?


My understanding is that "naked" Flash devices have limited write 
capability, but that "thumb drives" have an embedded microcontroller 
that levels the wear. There is still the issue that some filesystems 
work better with this type of device than others.


My experience with external USB-connected drives is that their power 
demands exceed that of most (internal and external) USB hubs, that they 
might not describe themselves accurately to the hub, and that in many 
cases they lack an external PSU socket. In practice, the ports on the 
back of an NSLU2 "Slug" will drive the notebook-style drives I've got.


I've also got an external (Buffalo?) USB-connected drive which has a 
200Gb SATA internally, this has its own PSU. I can't remember whether 
I've compared the speed of this with the notebook-style drives, I'd 
expect it to be faster.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: EBCDIC ( was On a port of Free Pascal to the IBM 370)

2012-01-30 Thread Daniël Mantione




Op Mon, 30 Jan 2012, schreef steve smithers:


Hans-Peter Diettrich wrote on Mon, 30 Jan 2012 17:40:27 +0100
Existing source code frequently assumes ASCII encoding. The obvious are
upper/lowercase conversions, by and/or or add/sub constant values to the
characters. It will be hell to find and fix all such code in the
compiler and RTL, even if only the constants have to be modified for
EBCDIC. Even code with the assumed order of common characters (' ' < '0'
< 'A' < 'a') has to be found and fixed manually - how would you even
*find* code with such implicit assumptions?


It does indeed.  I am aware of the problems inherent in this.  But the RTL
has to be more or less rewritten anyway to support OS.  OS is a very different
animal to Windows or Linux.


If you try to achieve a port by modifying all code that deals with 
characters you will fail. The amount of work becomes then far too big for 
a single person, and the modifications become too huge and wide-spread 
that you will raise objections for merging it with the SVN trunk.


In other words, do yourself a favour and keep ALL processing in ASCII. You 
can convert between ASCII & EBCDIC on input/output. That way the 
modifications in order to support EBCDIC are well concentrated in a single 
piece of code, which can be easily merged without risk of destabilizing 
the code base.


You can then use your manpower, and you still need *a* *lot* of it, to 
write a code generator & RTL.


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Inline Constants (was On a port of Free Pascal to the IBM 370)

> Mark Morgan Lloyd wrote
>
> Are you saying that IN ALL CASES it is completely transparent, and will 
> work with functions of any size, even on e.g. S/390 preceding G5?
>
> My reading of that document- and I stress that I will be very happy to 
> be corrected- is that the assembly source would have to be interrupted 
> every few K for a literal table.
> 
> Bear in mind that since FPC generates assembly source code (for whatever 
> target CPU), it might be very inconvenient to interrupt the flow of a 
> large function. And please note that I am being very careful to 
> distinguish here between generic "assembler source" and "IBM Assembler", 
> which as I understand it is a large and complex field with its own 
> culture and conventions (like referring to an "output deck" :-)

Sorry?  Output deck is the output file that the Assembler writes object code
to. It used to be on cards, so card deck.  Remember, this stuff was designed 
50 years ago. Some of the terminology is like a bad smell.

You're getting ahead of my notes again! :)  As there isn't a simple yes/no 
answer to this (is there ever a simple yes/no answer?) Can I defer answering
this until episode 3 when I talk about the mystical 4k limit on function or
data sizes.

Something to bear in mind though is a) that the differences are more between 
gas and the IBM assembler (whichever one you use) than between model numbers
of processor;  That b) The Porting GCC manual was written by microcode 
developers.  Lots of stuff that is available to us Assembler programmers is
implemented, not in the chip but in microcode.  As such it is available to me
but not to them.  and c) IBM have ulterior motives when they restrict the
development of GCC to a particular model, they sell processors.  A G5 would
fetch a considerable sum. (Cynical? Moi?)

--
Regards
Steve
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] Bounty for MIPS

2012-01-30 Thread Pierre Free Pascal


>>Anyhow, I just discovered that 
>>the /home directory is 99% full on that GCC compile farm machine,
>>meaning that only  remote tests will be possible ☹
>> 
>>It seems that lots of developers have the same issue about finding 
>>MIPS machines for testing ….
>
>Would you consider the NetGear WNDR3800 680Mhz, 128MB RAM with a USB Flash 
>drive of 32GB to be good enough for the development of the FPC toolchain ?
>(in this case, I can purchase and ship such device to your place),
>
>or would you consider that only a qemu virtual MIPS machine which can handle 
>more memory and more disk space to be suitable for the development ?

  I just googled a bit and read that the
USB flash drives are considered as having only a limited number of writes
before that fail... (http://en.wikipedia.org/wiki/USB_flash_drive)
So I wonder how long such a system like that would last (it probably also 
depends on 
the USB key quality itself?) if I run the testsuite each night
on it...

 Would a small USB hard drive be better? But does the device
have enough power to support such an external drive?
Would the speed be significantly lower or is the USB 2.0 
speed the real limitation?

 Pierre Muller
  

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: EBCDIC ( was On a port of Free Pascal to the IBM 370)

2012-01-30 Thread Sven Barth


On 30.01.2012 20:31, steve smithers wrote:

Hans-Peter Diettrich wrote on Mon, 30 Jan 2012 17:40:27 +0100
Existing source code frequently assumes ASCII encoding. The obvious are
upper/lowercase conversions, by and/or or add/sub constant values to the
characters. It will be hell to find and fix all such code in the
compiler and RTL, even if only the constants have to be modified for
EBCDIC. Even code with the assumed order of common characters (' '<  '0'
<  'A'<  'a') has to be found and fixed manually - how would you even
*find* code with such implicit assumptions?


It does indeed.  I am aware of the problems inherent in this.  But the RTL
has to be more or less rewritten anyway to support OS.  OS is a very different
animal to Windows or Linux.


The RTL consists of two parts (though the border is not easily visible): 
a platform independant one and a platform dependant one. A port to a 
different target normally only includes touching the platform dependant 
one, but a port to 370 also requires touching the platform independant 
one. This is what DoDi talks about.


@other devs: Could the code page aware AnsiString type be of any help here?

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: EBCDIC ( was On a port of Free Pascal to the IBM 370)

> Hans-Peter Diettrich wrote on Mon, 30 Jan 2012 17:40:27 +0100
> Existing source code frequently assumes ASCII encoding. The obvious are 
> upper/lowercase conversions, by and/or or add/sub constant values to the 
> characters. It will be hell to find and fix all such code in the 
> compiler and RTL, even if only the constants have to be modified for 
> EBCDIC. Even code with the assumed order of common characters (' ' < '0' 
> < 'A' < 'a') has to be found and fixed manually - how would you even 
> *find* code with such implicit assumptions?

It does indeed.  I am aware of the problems inherent in this.  But the RTL
has to be more or less rewritten anyway to support OS.  OS is a very different
animal to Windows or Linux.

But, you would start with various searches using grep or something
and scan for bits of the code that use constants like '#7' and change them to
fpc_Char_Bell or something similar that would live in an fpcASCII or fpcEBCDIC
unit or something similar.  You would search for all the combinations you could
think of '['a'..'z']', '['A'..'Z']' etc.  Finally, exhausting your ingenuity
you would be left with the old stand-by of testing.

A God-awful task I know.  But what's the alternative?  A note in the 
documentation
for FreePascal/MVS that whenever you reference any external data it is the 
user's
responsibility to convert from ASCII to EBCDIC.  Really?  
AssignFile(f,'SYS1.PARMLIB'),
sorry doesn't work, you forgot the ASCII conversion;  WRITELN('Hello World') 
produces
garbage on the user's terminal.  Who will they blame then.  
JobSubmit(asciifile) will
disappear from the face of the planet because JES won't have a clue what to do 
with
an ASCII file.

You can't convert automatically because you don't necessarily know whether the 
user
is writing ASCII, EBCDIC or binary.  What happens to

  MyRec = record
     Field1 : string;
     Field2 : char;
     Field3 : integer;
     end;

If we are using ASCII should we be using Little-Endian numbers too!

> Next come character ranges, where letters are assumed contiguous in all 
> existing code and examples. Clearly this is true only for ASCII 
> ('a'..'z'), not for national characters like 'Ã¤' or 'Ã©', but the 
> compiler assumes ASCII source encoding all over. Fixing the set 
> constructor to make Set Of Char work with EBCDIC will be a challenge.
> 
> When a user e.g. picks up such example or library code from somewhere, 
> and finds that it doesn't work, he'll blame the compiler for malfunction.
> 
> An EBCDIC based compiler will disallow the use of any foreign libraries, 
> because a simple (syntactic) conversion from ASCII to EBCDIC encoding 
> doesn't cover beforementioned (semantic) issues :-(

A compiler is not just a tool for syntax analysis.  It has semantic routines 
built
into already.  It's up to us to use enough ingenuity to cater for as many of 
these
as possible.  Surely it should be possible to pick up stuff like 'a'..'z' at 
compile-
time

Regards
Steve
> 
> Mark Morgan Lloyd wrote:

> I repeat: IBM is now happily using ASCII on zSeries. That includes the 
> CDSL system made available to developers 
> http://www-03.ibm.com/systems/z/os/linux/support/community.html

Yes. The Community Software Development for Linux on System/Z would use ASCII.  
As
we have already ascertained, Linux/390 is an ASCII system;  Using EBCDIC would 
be
slightly south of stupid.

CDSL doesn't run on OS.  Except possibly under USS.  Does anyone know if USS is
ASCII or EBCDIC?

(USS is Unix System Services, formerly known as Open/MVS.  It's a sort of Unix 
type
Look-alike ish sort of thing that runs under versions of OS from MVS/ESA SP 4.3 
onwards)

> I think the reason for producing an ASCII version first is very simple:

Converting the source from ASCII to EBCDIC isn't a huge problem.  Their are 
many much larger problems ahead :)

> 
> No - sending source code from a PC to a 370 performs an automatic translation 
> to EBCDIC (and vice versa).
> 
It depends on what you use to do the transfer and what options you specify.  
These utilities
are normally configurable.  FTP and IND£FILE are.  They're the two I've used in 
the past.

> IBM 370 doesn't use ASCII, anywhere, but it has a hardware instruction (TRT _ 
> Translate and Test)
> which can convert between character sets in a single instruction using a 
> suitable table. 

Translate and Test wouldn't help.  Despite the name it doesn't actually do any 
translation as such.
The instruction you meant was TR (Translate).  To quote "Sorry, pedantry strong 
this one runs" 

--
Regards
Steve
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: fpc-devel Digest, Vol 93, Issue 57


Sven Barth wrote:


Assuming that the target operating system has any concept of an
executable script. Steve's already told us that you can't generate a
binary externally, and it might turn out that the compiler will have to
generate a JCL (or comparable) deck which is then processed in some way
on the target rather than being executed directly.



The link script does not need to be executable by itself. In the end it 
would be sufficient to just include the commands in it that are needed 
to assemble and link the final application and then execute these by 
hand (in the worst case...).


Yes, I'm just trying to think ahead. In my mainframe days job control 
was either done with 80 column cards or using a KSR-33 :-)


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: fpc-devel Digest, Vol 93, Issue 57

2012-01-30 Thread Sven Barth


On 30.01.2012 19:36, Mark Morgan Lloyd wrote:

Sven Barth wrote:


I would very strongly suggest cross-compile fpc on Linux/Windows
using a version
that emits, not gas assembler but 370 assembler. I will be talking
about gas vs
370 assembler later. The assembler output can be in ASCII or EBCDIC
as rvmartin
said it's just a character encoding. The advantage is that you only
need to
upload a text file(s). Feed it into the OS assembler and link
programs and you
have a 370 load module.


Once a initial port to 370 has been made and the assembler output
generator is implemented (which means that the compiler can basically
generate 370 capable assembler files) this is rather easy as FPC can
generate "link on target" scripts (and AFAIK also "assemble on target").


Assuming that the target operating system has any concept of an
executable script. Steve's already told us that you can't generate a
binary externally, and it might turn out that the compiler will have to
generate a JCL (or comparable) deck which is then processed in some way
on the target rather than being executed directly.



The link script does not need to be executable by itself. In the end it 
would be sufficient to just include the commands in it that are needed 
to assemble and link the final application and then execute these by 
hand (in the worst case...).


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: fpc-devel Digest, Vol 93, Issue 57


Sven Barth wrote:

I would very strongly suggest cross-compile fpc on Linux/Windows using 
a version
that emits, not gas assembler but 370 assembler.  I will be talking 
about gas vs
370 assembler later.  The assembler output can be in ASCII or EBCDIC 
as rvmartin
said it's just a character encoding.  The advantage is that you only 
need to
upload a text file(s).  Feed it into the OS assembler and link 
programs and you

have a 370 load module.


Once a initial port to 370 has been made and the assembler output 
generator is implemented (which means that the compiler can basically 
generate 370 capable assembler files) this is rather easy as FPC can 
generate "link on target" scripts (and AFAIK also "assemble on target").


Assuming that the target operating system has any concept of an 
executable script. Steve's already told us that you can't generate a 
binary externally, and it might turn out that the compiler will have to 
generate a JCL (or comparable) deck which is then processed in some way 
on the target rather than being executed directly.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: fpc-devel Digest, Vol 93, Issue 57


steve smithers wrote:

michael.vancann...@wisa.be wrote the following on 30/01/12 17:35

I had in mind the following scenario:

1) Somehow we build - using cross-compilation - a first version of the
 compiler that actually runs on the 370. This binary is transferred to a
 370 machine.


I haven't got that far in my notes yet but...  Cross-compilation - yes.
Building a 370 binary on Linux or Windows - Well you can if you want but...
Transfer binary to a 370 machine - Whew.  This is problematic.

It's not any problem to move the binary itself, but there is more required
than the binary itself in order to produce an executable load module on any
OS version.  (I can't comment on VM or DOS cause they are a mystery to me).
An OS binary consists of more than the binary and I know of no way to build
that information on Linux or Windows.


That's not the case when the target is Linux: as with all distreaux and 
variants, the program compiles to a single file:


0 1>markMLl@pye-dev-07f:~/hello_world$ pascal-xsc hello.p
 environment file /usr/local/p-xsc/sys/p88.env found.
Compiling hello.p with PASCAL-XSC version T3.62 dated 07.12.05
(C) Copyright University of Karlsruhe 1991-1999
(C) Copyright University of Wuppertal 2000-2005
importing module  /usr/local/p-xsc/sys/stdmod.mod
FILE: hello.o
Analysis complete
Code generation complete
0 1>markMLl@pye-dev-07f:~/hello_world$ ls -lt
total 108
-rwxr-xr-x 1 markMLl markMLl 100118 Jan 30 18:17 hello
-rw-r--r-- 1 markMLl markMLl 68 Jan 30 18:16 hello.p
0 1>markMLl@pye-dev-07f:~/hello_world$ ./hello
Hello, World!

That's on a system which describes itself as

0 1>markMLl@pye-dev-07f:~/hello_world$ cat /proc/cpuinfo
vendor_id   : IBM/S390
# processors: 2
bogomips per cpu: 629.00
features: esan3 stfle msa ldisp eimm dfp
processor 0: version = 00,  identification = 69,  machine = 9672
processor 1: version = 00,  identification = 100069,  machine = 9672

However I am aware that various mainframe OSes- not limited to IBM- 
insist on "blessing" executables before they can be run.



I would very strongly suggest cross-compile fpc on Linux/Windows using a version
that emits, not gas assembler but 370 assembler.  I will be talking about gas vs
370 assembler later.  The assembler output can be in ASCII or EBCDIC as rvmartin
said it's just a character encoding.  The advantage is that you only need to
upload a text file(s).  Feed it into the OS assembler and link programs and you
have a 370 load module.


We look forward to your notes. My understanding is that at least one 
variant of FPC (the one targeting x86) can use multiple assembler 
notations, so the exact format of the assembly source might turn out not 
to be a problem. More of a problem would be is 370 Assembler conventions 
turned out to be incompatible with FPC code generation.



2) The sources of the compiler and RTL are transferred to the 370.
 I assume that after the file transfer, the sources are still in ASCII format ?


It depends on the options you use on your file transfer program, but I would
convert to EBCDIC here.


3) At that point the compiler can try to recompile itself on the 370
 machine.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: fpc-devel Digest, Vol 93, Issue 57

2012-01-30 Thread Sven Barth


On 30.01.2012 18:44, steve smithers wrote:

michael.vancann...@wisa.be wrote the following on 30/01/12 17:35


I had in mind the following scenario:

1) Somehow we build - using cross-compilation - a first version of the
  compiler that actually runs on the 370. This binary is transferred to a
  370 machine.


I haven't got that far in my notes yet but...  Cross-compilation - yes.
Building a 370 binary on Linux or Windows - Well you can if you want but...
Transfer binary to a 370 machine - Whew.  This is problematic.

It's not any problem to move the binary itself, but there is more required
than the binary itself in order to produce an executable load module on any
OS version.  (I can't comment on VM or DOS cause they are a mystery to me).
An OS binary consists of more than the binary and I know of no way to build
that information on Linux or Windows.

I would very strongly suggest cross-compile fpc on Linux/Windows using a version
that emits, not gas assembler but 370 assembler.  I will be talking about gas vs
370 assembler later.  The assembler output can be in ASCII or EBCDIC as rvmartin
said it's just a character encoding.  The advantage is that you only need to
upload a text file(s).  Feed it into the OS assembler and link programs and you
have a 370 load module.


Once a initial port to 370 has been made and the assembler output 
generator is implemented (which means that the compiler can basically 
generate 370 capable assembler files) this is rather easy as FPC can 
generate "link on target" scripts (and AFAIK also "assemble on target").



2) The sources of the compiler and RTL are transferred to the 370.
  I assume that after the file transfer, the sources are still in ASCII format ?


It depends on the options you use on your file transfer program, but I would
convert to EBCDIC here.


Not at the first step. As long as FPC is not able to understand EBCDIC 
there is no sense in converting the source to EBCDIC.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

2012-01-30 Thread Michael Van Canneyt




On Mon, 30 Jan 2012, rvmart...@ntlworld.com wrote:


michael.vancann...@wisa.be wrote the following on 30/01/12 16:35:20:



On Mon, 30 Jan 2012, rvmart...@ntlworld.com wrote:


michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:


I think the reason for producing an ASCII version first is very simple:
All FPC sources - including the compiler - are in ASCII encoding.


I don't understand this statement - ASCII and EBCDIC are just human 
representations of a computer's internal code.
I write my programs in the Latin (or Roman) alphabet and the computer does the 
rest.
When I was writing VS/Pascal programs I used the same source code as input to 
VS/Pascal on the mainframe and to Virtual Pascal on the PC.

Unless the FP source code is to be fed into a mainframe compiler like
IBM's VS/Pascal or the Stanford compiler then the first step is surely to
write a backend for the (eg PC) compiler to produce 370 assembler code.
Producing EBCDIC rather than ASCII sounds a trivial part of the task.


I had in mind the following scenario:

1) Somehow we build - using cross-compilation - a first version of the
   compiler that actually runs on the 370. This binary is transferred to a
   370 machine.

2) The sources of the compiler and RTL are transferred to the 370.
I assume that after the file transfer, the sources are still in ASCII 
format ?



No - sending source code from a PC to a 370 performs an automatic translation 
to EBCDIC (and vice versa).


I think that very much depends on the program you use to send the file.

We have a mainframe here, and sending ASCII files using FTP in binary mode, 
most certainly does not do any translation. I suppose the same goes for SCP, 
although I never tested that protocol myself.


And that is what I meant: unless you do the translation explicitly
(and by this I also understand email, ASCII mode FTP transfer and whatnot)
the compiler will see ASCII sources, even on the IBM.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Inline Constants (was On a port of Free Pascal to the IBM 370)


steve smithers wrote:


Firstly, let me explain that there are two different points regarding what has
been called "literal" values as concerns S/370 architecture and it's Assemblers.
The first of these is called "immediate" values where the literal is included
in the actual code generated for that instruction.  The second are called
"Literals" and describe unnamed constants that are defined on the instruction
that uses them in the source code, but resolve to storage areas that are built
into the object deck later.

The "Porting GCC to System/390" document in section 3.1 referred to and other
posts state "the original S/390 architecture did not provide instructions that
could use literal values as immediate operands".  This is untrue.  Since the
System/360 was introduced there was a class of instructions called SI (Storage
Immediate) that allowed just that.  The values were however, limited to 1 byte.
This has applied to it's descendents (370, 370/XA  390, ESA z/OS and z/OS 64)
The 390 extensions in the mid 1990's defined new instructions and extensions to
increase this limit to 2 bytes and later to 4 bytes, perhaps, beyond.  I've
never worked on the latest 64bit machines so I can't comment.

An example of SI instruction use.

CodeSource  Comments
92C1 C024   MVI   FIELD,C'A'Move character A to field.
A728 0009   LHI   R2,H'9'   Load 9 into register 2 Note H is a
halfword or 16 bit integer value

The code generated is 92C1,C024 where 92 is the opcode, C1 is the character 'A'
and C024 is the address in standard base/displacement form.  Or A7 is the
opcode, 28 specifies a 32bit load into R2 0009 is the value to load into the
register.  LHI is S/390 and later.

An equivalent example of literal instruction use.
D200 C024 C136  MVC   FIELD,=C'A'   Move character A to field.
4820 C134   LHR2,=H'9'  Load 9 into register 2 Note H is a
halfword or 16 bit integer value

The code generated is D200,C024,C136 where D2 is the opcode, C024 is the
address of FIELD and C136 the address of the literal, both in standard
base/displacement form.  The 00 is data regarding the length of data to move
limited from 1 to 256 bytes in this case.  Or 48 is the opcode, 20 specifies
the target register (R2) and the optional index register (unused) C134 is the
address of the 16 bit value to load in base/displacement form.  Where are the
constants?  Well they are generated automatically at the end of the module, or
if you wish to define them elsewhere you can include a "LTORG" statement which
tells the assembler to define them.

What I would like to know is "Why is this a problem?"  So the constants are
defined elsewhere, what issues does this raise?


Are you saying that IN ALL CASES it is completely transparent, and will 
work with functions of any size, even on e.g. S/390 preceding G5?


My reading of that document- and I stress that I will be very happy to 
be corrected- is that the assembly source would have to be interrupted 
every few K for a literal table.


Bear in mind that since FPC generates assembly source code (for whatever 
target CPU), it might be very inconvenient to interrupt the flow of a 
large function. And please note that I am being very careful to 
distinguish here between generic "assembler source" and "IBM Assembler", 
which as I understand it is a large and complex field with its own 
culture and conventions (like referring to an "output deck" :-)


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: fpc-devel Digest, Vol 93, Issue 57

> > michael.vancann...@wisa.be wrote the following on 30/01/12 17:35
>
> I had in mind the following scenario:
> 
> 1) Somehow we build - using cross-compilation - a first version of the
>  compiler that actually runs on the 370. This binary is transferred to a
>  370 machine.
>
I haven't got that far in my notes yet but...  Cross-compilation - yes.
Building a 370 binary on Linux or Windows - Well you can if you want but...
Transfer binary to a 370 machine - Whew.  This is problematic.

It's not any problem to move the binary itself, but there is more required
than the binary itself in order to produce an executable load module on any
OS version.  (I can't comment on VM or DOS cause they are a mystery to me).
An OS binary consists of more than the binary and I know of no way to build
that information on Linux or Windows.

I would very strongly suggest cross-compile fpc on Linux/Windows using a version
that emits, not gas assembler but 370 assembler.  I will be talking about gas vs
370 assembler later.  The assembler output can be in ASCII or EBCDIC as rvmartin
said it's just a character encoding.  The advantage is that you only need to
upload a text file(s).  Feed it into the OS assembler and link programs and you
have a 370 load module.

> 2) The sources of the compiler and RTL are transferred to the 370.
>  I assume that after the file transfer, the sources are still in ASCII format 
> ?
> 
It depends on the options you use on your file transfer program, but I would
convert to EBCDIC here.

> 3) At that point the compiler can try to recompile itself on the 370
>  machine.
Yes.

--
Regards
Steve
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

Daniël Mantione  wrote the following on 
30/01/12 16:29:27:
> 
> 
> Op Mon, 30 Jan 2012, schreef rvmart...@ntlworld.com:
> 
> > michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:
> >
> >> I think the reason for producing an ASCII version first is very simple:
> >> All FPC sources - including the compiler - are in ASCII encoding.
> >
> > I don't understand this statement - ASCII and EBCDIC are just human 
> > representations of a computer's internal code.
> 
> ... which can be ASCII or EBCDIC encoded, right?
> 
> So if the compiler source files are ASCII encoded... then the compiler has 
> to read ASCII to be able to compile itself.
> 
> > I write my programs in the Latin (or Roman) alphabet and the computer 
> > does the rest.
> 
> So the compiler has to care about ASCII/EBCDIC encoding, right?

No!!  If I write my name and address - in the roman alphabet of course - on a 
PC the computer stores it as ASCII, but when I display it on the monitor it is 
displayed as human-readable roman alphabet (at least in my part of the world).
If I then email it from the PC to a 370 the computer stores it as EBCDIC, but 
displaying it on a monitor it is the same human-readable roman alphabet.
Human beings do not read or write ASCII or EBCDIC.
Pascal source code can be encoded as ASCII or EBCDIC depending on what sort of 
computer it is stored on, but we see "human code".
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

Daniël Mantione  wrote the following on 
30/01/12 16:29:27:
> 
> 
> Op Mon, 30 Jan 2012, schreef rvmart...@ntlworld.com:
> 
> > michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:
> >
> >> I think the reason for producing an ASCII version first is very simple:
> >> All FPC sources - including the compiler - are in ASCII encoding.
> >
> > I don't understand this statement - ASCII and EBCDIC are just human 
> > representations of a computer's internal code.
> 
> ... which can be ASCII or EBCDIC encoded, right?
> 
> So if the compiler source files are ASCII encoded... then the compiler has 
> to read ASCII to be able to compile itself.
> 
> > I write my programs in the Latin (or Roman) alphabet and the computer 
> > does the rest.
> 
> So the compiler has to care about ASCII/EBCDIC encoding, right?

No!!  If I write my name and address - in the roman alphabet of course - on a 
PC the computer stores it as ASCII, but when I display it on the monitor it is 
displayed as human-readable roman alphabet (at least in my part of the world).
If I then email it from the PC to a 370 the computer stores it as EBCDIC, but 
displaying it on a monitor it is the same human-readable roman alphabet.
Human beings do not read or write ASCII or EBCDIC.
Pascal source code can be encoded as ASCII or EBCDIC depending on what sort of 
computer it is stored on, but we see "human code".
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] GibbleDiGeek

2012-01-30 Thread Jonas Maebe

On 30 Jan 2012, at 18:25, steve smithers wrote:

> I am a newcomer to this group and I receive the message digest from the
> list-server fine.  I can post messages fine.  But sometimes the messages
> look like the one below.  Why is this?  Are these messages encryted?  Or
> is it Belgian? :) How can I get them in ASCII (or EBCDIC :)) so I can read
> them.  Anyone any ideas.

The encoding you received the message in is base64. The encoding you receive a 
message in depends on the encoding the sender uses and what intermediate mail 
servers do (I received it in plain ASCII, in the mailing list archive it's also 
base64). There's nothing you can do about that that. All modern mail clients 
should be able to handle base64 encoding though. If your webmail client can't, 
I'm afraid you'll have to decode it yourself via e.g. 
http://www.opinionatedgeek.com/dotnet/tools/base64decode/

Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

Daniël Mantione  wrote the following on 
30/01/12 16:29:27:
> 
> 
> Op Mon, 30 Jan 2012, schreef rvmart...@ntlworld.com:
> 
> > michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:
> >
> >> I think the reason for producing an ASCII version first is very simple:
> >> All FPC sources - including the compiler - are in ASCII encoding.
> >
> > I don't understand this statement - ASCII and EBCDIC are just human 
> > representations of a computer's internal code.
> 
> ... which can be ASCII or EBCDIC encoded, right?
> 
> So if the compiler source files are ASCII encoded... then the compiler has 
> to read ASCII to be able to compile itself.
> 
> > I write my programs in the Latin (or Roman) alphabet and the computer 
> > does the rest.
> 
> So the compiler has to care about ASCII/EBCDIC encoding, right?

No!!  If I write my name and address - in the roman alphabet of course - on a 
PC the computer stores it as ASCII, but when I display it on the monitor it is 
displayed as human-readable roman alphabet (at least in my part of the world).
If I then email it from the PC to a 370 the computer stores it as EBCDIC, but 
displaying it on a monitor it is the same human-readable roman alphabet.
Human beings do not read or write ASCII or EBCDIC.
Pascal source code can be encoded as ASCII or EBCDIC depending on what sort of 
computer it is stored on, but we see "human code".
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

michael.vancann...@wisa.be wrote the following on 30/01/12 16:35:20:
> 
> 
> On Mon, 30 Jan 2012, rvmart...@ntlworld.com wrote:
> 
> > michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:
> >
> >> I think the reason for producing an ASCII version first is very simple:
> >> All FPC sources - including the compiler - are in ASCII encoding.
> >
> > I don't understand this statement - ASCII and EBCDIC are just human 
> > representations of a computer's internal code.
> > I write my programs in the Latin (or Roman) alphabet and the computer does 
> > the rest.
> > When I was writing VS/Pascal programs I used the same source code as input 
> > to VS/Pascal on the mainframe and to Virtual Pascal on the PC.
> >
> > Unless the FP source code is to be fed into a mainframe compiler like
> > IBM's VS/Pascal or the Stanford compiler then the first step is surely to
> > write a backend for the (eg PC) compiler to produce 370 assembler code. 
> > Producing EBCDIC rather than ASCII sounds a trivial part of the task.
> 
> I had in mind the following scenario:
> 
> 1) Somehow we build - using cross-compilation - a first version of the
>compiler that actually runs on the 370. This binary is transferred to a
>370 machine.
> 
> 2) The sources of the compiler and RTL are transferred to the 370.
> I assume that after the file transfer, the sources are still in ASCII 
> format ?


No - sending source code from a PC to a 370 performs an automatic translation 
to EBCDIC (and vice versa).


> 
> 3) At that point the compiler can try to recompile itself on the 370
> machine.
> 
> Unless you have performed some tranformation of the compiler/RTL sources, 
> the compiler in step 3 will read and compile from ASCII sources, no ?

IBM 370 doesn't use ASCII, anywhere, but it has a hardware instruction (TRT _ 
Translate and Test) which can convert between character sets in a single 
instruction using a suitable table.  
 





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

michael.vancann...@wisa.be wrote the following on 30/01/12 16:35:20:
> 
> 
> On Mon, 30 Jan 2012, rvmart...@ntlworld.com wrote:
> 
> > michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:
> >
> >> I think the reason for producing an ASCII version first is very simple:
> >> All FPC sources - including the compiler - are in ASCII encoding.
> >
> > I don't understand this statement - ASCII and EBCDIC are just human 
> > representations of a computer's internal code.
> > I write my programs in the Latin (or Roman) alphabet and the computer does 
> > the rest.
> > When I was writing VS/Pascal programs I used the same source code as input 
> > to VS/Pascal on the mainframe and to Virtual Pascal on the PC.
> >
> > Unless the FP source code is to be fed into a mainframe compiler like
> > IBM's VS/Pascal or the Stanford compiler then the first step is surely to
> > write a backend for the (eg PC) compiler to produce 370 assembler code. 
> > Producing EBCDIC rather than ASCII sounds a trivial part of the task.
> 
> I had in mind the following scenario:
> 
> 1) Somehow we build - using cross-compilation - a first version of the
>compiler that actually runs on the 370. This binary is transferred to a
>370 machine.
> 
> 2) The sources of the compiler and RTL are transferred to the 370.
> I assume that after the file transfer, the sources are still in ASCII 
> format ?


No - sending source code from a PC to a 370 performs an automatic translation 
to EBCDIC (and vice versa).


> 
> 3) At that point the compiler can try to recompile itself on the 370
> machine.
> 
> Unless you have performed some tranformation of the compiler/RTL sources, 
> the compiler in step 3 will read and compile from ASCII sources, no ?

IBM 370 doesn't use ASCII, anywhere, but it has a hardware instruction (TRT _ 
Translate and Test) which can convert between character sets in a single 
instruction using a suitable table.  
 





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Inline Constants (was On a port of Free Pascal to the IBM 370)

I have just found the thread discussing a port of FreePascal to the System/370
and I feel I have to correct some misinterpretations, mistakes and other
calumnies that have been thrown into the discussion. First, my qualifications.
I have been a developer of Assembler systems, both applications and systems
software since 1981. I have worked on VS1, MVS (370, XA, ESA), OS/390 and
Z/OS systems. I have worked for many large blue chip companies and for
software house (small) and computer manufacturer's (large).

Episode 2. Inline constants

Firstly, let me explain that there are two different points regarding what has
been called "literal" values as concerns S/370 architecture and it's Assemblers.
The first of these is called "immediate" values where the literal is included
in the actual code generated for that instruction. The second are called
"Literals" and describe unnamed constants that are defined on the instruction
that uses them in the source code, but resolve to storage areas that are built
into the object deck later.

The "Porting GCC to System/390" document in section 3.1 referred to and other
posts state "the original S/390 architecture did not provide instructions that
could use literal values as immediate operands". This is untrue. Since the
System/360 was introduced there was a class of instructions called SI (Storage
Immediate) that allowed just that. The values were however, limited to 1 byte.
This has applied to it's descendents (370, 370/XA 390, ESA z/OS and z/OS 64)
The 390 extensions in the mid 1990's defined new instructions and extensions to
increase this limit to 2 bytes and later to 4 bytes, perhaps, beyond. I've
never worked on the latest 64bit machines so I can't comment.

An example of SI instruction use.

Code Source Comments
92C1 C024 MVI FIELD,C'A' Move character A to field.
A728 0009 LHI R2,H'9' Load 9 into register 2 Note H is a
halfword or 16 bit integer value

The code generated is 92C1,C024 where 92 is the opcode, C1 is the character 'A'
and C024 is the address in standard base/displacement form. Or A7 is the
opcode, 28 specifies a 32bit load into R2 0009 is the value to load into the
register. LHI is S/390 and later.

An equivalent example of literal instruction use.
D200 C024 C136 MVC FIELD,=C'A' Move character A to field.
4820 C134 LH R2,=H'9' Load 9 into register 2 Note H is a
halfword or 16 bit integer value

The code generated is D200,C024,C136 where D2 is the opcode, C024 is the
address of FIELD and C136 the address of the literal, both in standard
base/displacement form. The 00 is data regarding the length of data to move
limited from 1 to 256 bytes in this case. Or 48 is the opcode, 20 specifies
the target register (R2) and the optional index register (unused) C134 is the
address of the 16 bit value to load in base/displacement form. Where are the
constants? Well they are generated automatically at the end of the module, or
if you wish to define them elsewhere you can include a "LTORG" statement which
tells the assembler to define them.

What I would like to know is "Why is this a problem?" So the constants are
defined elsewhere, what issues does this raise?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)


steve smithers wrote:


It should be noted that using Linux/390 doesn't remove the '^' problem.  IBM
display unit (3270) keyboards, being EBCDIC devices, won't have the '^' on
the keyboard so an alternative must be found.  (I'm assuming that Linux uses
3270 devices, maybe I'm wrong)


Linux on S/390 uses SSH, any of the standard X-based desktops, VNC and 
so on. I see no reference to EBCDIC, unless it's buried in options to 
control encoding for (emulations of) classic IBM peripherals.



Finally, the suggestions about developing FreePascal/370 as an ASCII compiler
seem somewhat pointless to me.  Why would anyone want to use an ASCII compiler
on an EBCDIC system?  I accept fully that producing an EBCDIC version will
present problems, but if this compiler is actually going to be used by anyone,
these have to be overcome.


I repeat: IBM is now happily using ASCII on zSeries. That includes the 
CDSL system made available to developers 
http://www-03.ibm.com/systems/z/os/linux/support/community.html


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] GibbleDiGeek

I am a newcomer to this group and I receive the message digest from the
list-server fine.  I can post messages fine.  But sometimes the messages
look like the one below.  Why is this?  Are these messages encryted?  Or
is it Belgian? :) How can I get them in ASCII (or EBCDIC :)) so I can read
them.  Anyone any ideas.
Thanks.
Steve
--

Message: 7
Date: Mon, 30 Jan 2012 15:49:53 +0100 (CET)
From: michael.vancann...@wisa.be
Subject: Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the
 IBM 370)
To: FPC developers' list 
Message-ID: 
Content-Type: text/plain; charset="utf-8"

CgpPbiBNb24sIDMwIEphbiAyMDEyLCBzdGV2ZSBzbWl0aGVycyB3cm90ZToKCj4KPiBGaW5hbGx5
LCB0aGUgc3VnZ2VzdGlvbnMgYWJvdXQgZGV2ZWxvcGluZyBGcmVlUGFzY2FsLzM3MCBhcyBhbiBB
U0NJSSBjb21waWxlcgo+IHNlZW0gc29tZXdoYXQgcG9pbnRsZXNzIHRvIG1lLiDCoFdoeSB3b3Vs
ZCBhbnlvbmUgd2FudCB0byB1c2UgYW4gQVNDSUkgY29tcGlsZXIKPiBvbiBhbiBFQkNESUMgc3lz
dGVtPyDCoEkgYWNjZXB0IGZ1bGx5IHRoYXQgcHJvZHVjaW5nIGFuIEVCQ0RJQyB2ZXJzaW9uIHdp
bGwKPiBwcmVzZW50IHByb2JsZW1zLCBidXQgaWYgdGhpcyBjb21waWxlciBpcyBhY3R1YWxseSBn
b2luZyB0byBiZSB1c2VkIGJ5IGFueW9uZSwKPiB0aGVzZSBoYXZlIHRvIGJlIG92ZXJjb21lLgoK
SSB0aGluayB0aGUgcmVhc29uIGZvciBwcm9kdWNpbmcgYW4gQVNDSUkgdmVyc2lvbiBmaXJzdCBp
cyB2ZXJ5IHNpbXBsZTogCkFsbCBGUEMgc291cmNlcyAtIGluY2x1ZGluZyB0aGUgY29tcGlsZXIg
LSBhcmUgaW4gQVNDSUkgZW5jb2RpbmcuCgpXaGF0ZXZlciBpcyBtYWRlLCB0aGUgaHlwb3RoZXRp
Y2FsIGNvbXBpbGVyIHdpbGwgbmVlZCB0byB1bmRlcnN0YW5kIEFTQ0lJIGluCnRoZSBmaXJzdCBw
bGFjZSwgb3IgaXQgY2Fubm90IHJlY29tcGlsZSBpdHNlbGYgb3IgaXQncyBSVEwuLi4KCk1pY2hh
ZWwuCg==

--
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

Daniël Mantione  wrote the following on 
30/01/12 16:29:27:
> 
> 
> Op Mon, 30 Jan 2012, schreef rvmart...@ntlworld.com:
> 
> > michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:
> >
> >> I think the reason for producing an ASCII version first is very simple:
> >> All FPC sources - including the compiler - are in ASCII encoding.
> >
> > I don't understand this statement - ASCII and EBCDIC are just human 
> > representations of a computer's internal code.
> 
> ... which can be ASCII or EBCDIC encoded, right?
> 
> So if the compiler source files are ASCII encoded... then the compiler has 
> to read ASCII to be able to compile itself.
> 
> > I write my programs in the Latin (or Roman) alphabet and the computer 
> > does the rest.
> 
> So the compiler has to care about ASCII/EBCDIC encoding, right?

No!!  If I write my name and address - in the roman alphabet of course - on a 
PC the computer stores it as ASCII, but when I display it on the monitor it is 
displayed as human-readable roman alphabet (at least in my part of the world).
If I then email it from the PC to a 370 the computer stores it as EBCDIC, but 
displaying it on a monitor it is the same human-readable roman alphabet.
Human beings do not read or write ASCII or EBCDIC.
Pascal source code can be encoded as ASCII or EBCDIC depending on what sort of 
computer it is stored on, but we see "human code".
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS


Felipe Monteiro de Carvalho wrote:

On Mon, Jan 30, 2012 at 2:51 PM, Mark Morgan Lloyd
 wrote:

was tinkering with them, it would be interesting to have input from somebody
who's actually used that technology e.g. to tell us why a high-level
language such as Pascal can contribute.


If you cut features then Pascal can be just as low level as C.

In the specific case of FPGA I don't see why one would want to use
Pascal because the hardware languages have a lot of specificities
geared to hardware development and parallelity and 1 more important
thing: Many hardware languages are very pascal-ish, so they are
already similar to Pascal. VHDL for example is quite pascal-ish.

See: http://en.wikipedia.org/wiki/File:Vhdl_signed_adder.png

So why modify Pascal to try to make it usable in FPGA when the main
language for FPGA development is already pascalish?


Presumably for the same reasons that people are trying to translate C to 
FPGA functionality. NOT that I'm suggesting that as a viable project.


I think a lot of MIPS's viability rests with the Chinese. I'm obviously 
aware of Loongson etc., but it's very unclear just how many are bing 
shipped- they certainly seem to have stepped back from their threat that 
they were going to use it for a super.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

2012-01-30 Thread Hans-Peter Diettrich


steve smithers schrieb:


Finally, the suggestions about developing FreePascal/370 as an ASCII compiler
seem somewhat pointless to me.  Why would anyone want to use an ASCII compiler
on an EBCDIC system?  I accept fully that producing an EBCDIC version will
present problems, but if this compiler is actually going to be used by anyone,
these have to be overcome.


Existing source code frequently assumes ASCII encoding. The obvious are 
upper/lowercase conversions, by and/or or add/sub constant values to the 
characters. It will be hell to find and fix all such code in the 
compiler and RTL, even if only the constants have to be modified for 
EBCDIC. Even code with the assumed order of common characters (' ' < '0' 
< 'A' < 'a') has to be found and fixed manually - how would you even 
*find* code with such implicit assumptions?


Next come character ranges, where letters are assumed contiguous in all 
existing code and examples. Clearly this is true only for ASCII 
('a'..'z'), not for national characters like 'ä' or 'é', but the 
compiler assumes ASCII source encoding all over. Fixing the set 
constructor to make Set Of Char work with EBCDIC will be a challenge.


When a user e.g. picks up such example or library code from somewhere, 
and finds that it doesn't work, he'll blame the compiler for malfunction.


An EBCDIC based compiler will disallow the use of any foreign libraries, 
because a simple (syntactic) conversion from ASCII to EBCDIC encoding 
doesn't cover beforementioned (semantic) issues :-(


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

2012-01-30 Thread Daniël Mantione




Op Mon, 30 Jan 2012, schreef rvmart...@ntlworld.com:


michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:


I think the reason for producing an ASCII version first is very simple:
All FPC sources - including the compiler - are in ASCII encoding.


I don't understand this statement - ASCII and EBCDIC are just human 
representations of a computer's internal code.


... which can be ASCII or EBCDIC encoded, right?

So if the compiler source files are ASCII encoded... then the compiler has 
to read ASCII to be able to compile itself.


I write my programs in the Latin (or Roman) alphabet and the computer 
does the rest.


So the compiler has to care about ASCII/EBCDIC encoding, right?

When I was writing VS/Pascal programs I used the same source code as 
input to VS/Pascal on the mainframe and to Virtual Pascal on the PC.


Unless the FP source code is to be fed into a mainframe compiler like 
IBM's VS/Pascal or the Stanford compiler then the first step is surely 
to write a backend for the (eg PC) compiler to produce 370 assembler 
code.  Producing EBCDIC rather than ASCII sounds a trivial part of the 
task


Yes, but that's a difference topic than the source encoding. The compiler 
doesn't care how the assembler generator communicates with the assembler; 
it could be in any format, even binary. One just has to implement the 
assembler generator correctly.


The compiler does care that the source it processes is ASCII. If it has to 
be able to read EBCDIC, some conversion has to happen before the scanner. 
As such a conversion is not necessary for the compiler to compile itself, 
it may make sense to postpone writing such a conversion and have the 
initial port be ASCII only.


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

2012-01-30 Thread michael . vancanneyt




On Mon, 30 Jan 2012, rvmart...@ntlworld.com wrote:


michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:


I think the reason for producing an ASCII version first is very simple:
All FPC sources - including the compiler - are in ASCII encoding.


I don't understand this statement - ASCII and EBCDIC are just human 
representations of a computer's internal code.
I write my programs in the Latin (or Roman) alphabet and the computer does the 
rest.
When I was writing VS/Pascal programs I used the same source code as input to 
VS/Pascal on the mainframe and to Virtual Pascal on the PC.

Unless the FP source code is to be fed into a mainframe compiler like
IBM's VS/Pascal or the Stanford compiler then the first step is surely to
write a backend for the (eg PC) compiler to produce 370 assembler code. 
Producing EBCDIC rather than ASCII sounds a trivial part of the task.


I had in mind the following scenario:

1) Somehow we build - using cross-compilation - a first version of the
  compiler that actually runs on the 370. This binary is transferred to a
  370 machine.

2) The sources of the compiler and RTL are transferred to the 370.
   I assume that after the file transfer, the sources are still in ASCII format 
?

3) At that point the compiler can try to recompile itself on the 370
   machine.

Unless you have performed some tranformation of the compiler/RTL sources, 
the compiler in step 3 will read and compile from ASCII sources, no ?


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53:

> I think the reason for producing an ASCII version first is very simple: 
> All FPC sources - including the compiler - are in ASCII encoding.

I don't understand this statement - ASCII and EBCDIC are just human 
representations of a computer's internal code.
I write my programs in the Latin (or Roman) alphabet and the computer does the 
rest.
When I was writing VS/Pascal programs I used the same source code as input to 
VS/Pascal on the mainframe and to Virtual Pascal on the PC.

Unless the FP source code is to be fed into a mainframe compiler like IBM's 
VS/Pascal or the Stanford compiler then the first step is surely to write a 
backend for the (eg PC) compiler to produce 370 assembler code.  Producing 
EBCDIC rather than ASCII sounds a trivial part of the task.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

2012-01-30 Thread michael . vancanneyt




On Mon, 30 Jan 2012, steve smithers wrote:



Finally, the suggestions about developing FreePascal/370 as an ASCII compiler
seem somewhat pointless to me.  Why would anyone want to use an ASCII compiler
on an EBCDIC system?  I accept fully that producing an EBCDIC version will
present problems, but if this compiler is actually going to be used by anyone,
these have to be overcome.


I think the reason for producing an ASCII version first is very simple: 
All FPC sources - including the compiler - are in ASCII encoding.


Whatever is made, the hypothetical compiler will need to understand ASCII in
the first place, or it cannot recompile itself or it's RTL...

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)

I have just found the thread discussing a port of FreePascal to the System/370
and I feel I have to correct some misinterpretations, mistakes and other
calumnies that have been thrown into the discussion. First, my
qualifications. I have been a developer of Assembler systems, both
applications and systems software since 1981. I have worked on VS1, MVS (370,
XA, ESA), OS/390 and z/OS systems. I have worked for many large blue chip
companies and for software houses (small) and computer manufacturer's (large).

In this first note, I will deal, mostly, with the character set issues; Other
notes will follow - be warned.

Firstly, the easy one, the System/370 and related processors come with a large
supply of 8 bit bytes. :)

There seems to a common perception on the internet that EBCDIC does not have
codes for things like square or curly brackets. This is untrue. My little
magic EBCDIC reference card (Dated February 1975) lists them as; '}' - 0xD0,
'{' - 0xC0, '[' - 0xAD and ']' - 0xBD. Square brackets seem to be "new" with
System/370 (1970's), but curly brackets are actually built into the naming
requirements of many systems modules for some odd reason. As such, they have
always been in the character set. I think the confusion may have arisen by
their absence on the original card punch keyboards. But that was 50 years
ago, let's try and be a little more up to date than that!

A slightly later version of this reference card is available online at
http://bitsavers.org/pdf/ibm/370/referenceCard/GX20-1850-3_System370_Reference_Summary_Nov76_2up.pdf

'^' doesn't seem to be available, but my eyesight isn't what it was!
(VS/PASCAL, an MVS version of ISO pascal, uses -> as a digraph for this). I
don't think there's anything else.

It should be noted that using Linux/390 doesn't remove the '^' problem. IBM
display unit (3270) keyboards, being EBCDIC devices, won't have the '^' on
the keyboard so an alternative must be found. (I'm assuming that Linux uses
3270 devices, maybe I'm wrong)

Finally, the suggestions about developing FreePascal/370 as an ASCII compiler
seem somewhat pointless to me. Why would anyone want to use an ASCII compiler
on an EBCDIC system? I accept fully that producing an EBCDIC version will
present problems, but if this compiler is actually going to be used by anyone,
these have to be overcome.

--
Regards
Steve Smith
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS

2012-01-30 Thread Michael Schnell

Pascal is not useful for doing FPGA design, but for using the NIOS CPU 
that is programmed into the FPGA (using some HDL tools). Especially when 
this CPU runs Linux, Pascal might come handy for certain projects or 
programmers.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS

2012-01-30 Thread Michael Schnell


On 01/30/2012 02:51 PM, Mark Morgan Lloyd wrote:


I remember mentioning NIOS as a MIPS variant in earlier discussion. 
Did you ever conclude just how close they were, i.e. could one backend 
target both?
Not really. This is what the FAE told me when he did an introduction on 
NIOS. I understand that the register structure is very similar and most 
the instructions can be translated 1:1 regarding some dedicated MIPS 
variant (supposedly the most simple one).  As I never did any work with 
MIPS, I can't be more specific. At the time I got this lesson, there was 
no MMU enable NIOS design yet. But now, IMHO, the way to go with NIOS on 
Linux  is to use the MMU enhanced variant.
it would be interesting to have input from somebody who's actually 
used that technology e.g. to tell us why a high-level language such as 
Pascal can contribute.


I did bring up a Linux system on the NIOS hardware and did some research 
on what we can do with that. Of course it's great to have a combination 
of a Linux enabled CPU and very fast custom-"hardware" in a single chip, 
even though the CPU is not very fast. But at least it can happily do 
TCP/IP on a 100MBit line.


If we would have decided to do a project on NIOS, I might have started 
trying to do an FPC compiler for same, to allow for porting some of the 
currently used Pascal based PC software. But here, all NIOS activity has 
died. The cause that there now is the TI 335x chip that has a ten times 
faster (ARM Cortex A8) CPU for Linux plus two Cortex M3 cores that - 
independently of the main CPU - can do most of what we would require an 
FPGA form. ARM-Linux, of course, is a lot more "Standard" than 
NIOS-Linux, and FPC is no problem either.


-Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS

2012-01-30 Thread Felipe Monteiro de Carvalho

On Mon, Jan 30, 2012 at 2:51 PM, Mark Morgan Lloyd
 wrote:
> was tinkering with them, it would be interesting to have input from somebody
> who's actually used that technology e.g. to tell us why a high-level
> language such as Pascal can contribute.

If you cut features then Pascal can be just as low level as C.

In the specific case of FPGA I don't see why one would want to use
Pascal because the hardware languages have a lot of specificities
geared to hardware development and parallelity and 1 more important
thing: Many hardware languages are very pascal-ish, so they are
already similar to Pascal. VHDL for example is quite pascal-ish.

See: http://en.wikipedia.org/wiki/File:Vhdl_signed_adder.png

So why modify Pascal to try to make it usable in FPGA when the main
language for FPGA development is already pascalish?

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS


Michael Schnell wrote:

On 01/30/2012 01:48 PM, Mark Morgan Lloyd wrote:

Michael Schnell wrote:
IMHO, the MIPS port is interesting, too, as the NIOS CPU that is 
available as soft core for Altera FPGA uses a very similar 
instruction set and supposedly can be handled as a sub-arch.


There is a very active community for NIOS-Linux that now provides a 
quite decent MMU-enabled Linux port (including the necessary 
Distribution generating Make-based tool chain).


For quite some time I played with NIOS  using a "NEEK" Dev-Kit from 
Altera. Nice stuff.


I remember mentioning NIOS as a MIPS variant in earlier discussion. Did 
you ever conclude just how close they were, i.e. could one backend 
target both?



Would you like to fill in a bit more detail on this in fpc-other?


As I'm not on fpc-other:

What would you like to know ?

Is there already an ongoing discussion on that ?

I stopped working on NIOS several  about a year ago and I'm just 
monitoring some groups on same. So I don't think i can be very helpful 
besides providing some pointers.


There were a couple of threads oriented towards hardware which were 
continued there since they were out of place in the more focussed MLs. 
Somebody specifically mentioned FPGAs in the context that he believed 
Wirth was tinkering with them, it would be interesting to have input 
from somebody who's actually used that technology e.g. to tell us why a 
high-level language such as Pascal can contribute.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS


Nikolai Zhubr wrote:

30.01.2012 16:19, Mark Morgan Lloyd:

Bear in mind that there's Debian for both endiannesses of MIPS, I'm
running mipsel via Qemu to reasonable effect. Experience with small ARM
systems suggests that having enough memory is crucial, 128Mb with swap
to 512 should be OK but these days I'd not like to try smaller.


128Mb RAM + 512Mb swap is no problem here.


But I don't know to what extent trying to implement the compiler and
runtimes for mips and mipsel simultaneously would complicate things.


I'd guess so. That's why I'm asking before even trying to install, as it 
might appear rather useless (and I'm not a debian user actually, and 
anyway openwrt seems much more comprehensible on such small devices)


Debian's no big deal, with the benefit that Debian on one architecture 
is almost identical to Debian on a different one: once booted, ARM or 
S/390 is almost indistinguishable from a PC.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS


Michael Schnell wrote:
IMHO, the MIPS port is interesting, too, as the NIOS CPU that is 
available as soft core for Altera FPGA uses a very similar instruction 
set and supposedly can be handled as a sub-arch.


There is a very active community for NIOS-Linux that now provides a 
quite decent MMU-enabled Linux port (including the necessary 
Distribution generating Make-based tool chain).


For quite some time I played with NIOS  using a "NEEK" Dev-Kit from 
Altera. Nice stuff.


Would you like to fill in a bit more detail on this in fpc-other?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS

2012-01-30 Thread Nikolai Zhubr


30.01.2012 16:19, Mark Morgan Lloyd:

Bear in mind that there's Debian for both endiannesses of MIPS, I'm
running mipsel via Qemu to reasonable effect. Experience with small ARM
systems suggests that having enough memory is crucial, 128Mb with swap
to 512 should be OK but these days I'd not like to try smaller.


128Mb RAM + 512Mb swap is no problem here.


But I don't know to what extent trying to implement the compiler and
runtimes for mips and mipsel simultaneously would complicate things.


I'd guess so. That's why I'm asking before even trying to install, as it 
might appear rather useless (and I'm not a debian user actually, and 
anyway openwrt seems much more comprehensible on such small devices)



Nikolai





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] contains

2012-01-30 Thread Jonas Maebe



On 30 Jan 2012, at 13:11, Martin wrote:


Any body an idea, in whic context "contains" may be a keyword?


In the context of Delphi-style packages: 
http://docwiki.embarcadero.com/RADStudio/en/Understanding_the_Structure_of_a_Package#Contains_Clause


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] contains

2012-01-30 Thread Marco van de Voort

In our previous episode, Martin said:
> Any body an idea, in whic context "contains" may be a keyword?

In .dpr's of libraries . Just like "requires"

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS


Nikolai Zhubr wrote:

Hi,
29.01.2012 19:32, Jy V:
[...]

on the WNDR3800 the OpenWRT installed gives
root@OpenWrt:~# uname -a
Linux OpenWrt 2.6.32.27 #5 Wed Dec 21 01:59:33 CET 2011 mips GNU/Linux


I've got wndr3800 too, and moreover I don't use it for the moment. So 
instead of collecting dust it could do something usefull. Installing 
debian on it will probably not be as quick and easy as openwrt but still 
if debian mips userspace is able to run on it, I could give it a try and 
then ssh will be available for FPC developers if installation succeeds. 
It is apparently big endian though. Would it make sense to try?


Bear in mind that there's Debian for both endiannesses of MIPS, I'm 
running mipsel via Qemu to reasonable effect. Experience with small ARM 
systems suggests that having enough memory is crucial, 128Mb with swap 
to 512 should be OK but these days I'd not like to try smaller.


But I don't know to what extent trying to implement the compiler and 
runtimes for mips and mipsel simultaneously would complicate things.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] contains

2012-01-30 Thread Martin

Any body an idea, in whic context "contains" may be a keyword?

 Original Message 
Subject:synedit questiions
Date:   Mon, 30 Jan 2012 12:51:00 +0400
From:   Anton 
Reply-To:   A.S. 
Organisation:   [AST]
To: Martin 

Hello, Martin!
I have some questions about SynEdit.
1. Why SynPasHighlighter thinks that "contains" is a keyword (and
types it in bold)?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS

2012-01-30 Thread Nikolay Nikolov


On 01/29/2012 02:21 PM, Florian Klämpfl wrote:

Main problem with MIPS is to get hands on a reasonable development
system (full fledged unix like Debian Linux, *BSD, CPU in the range of 1
GHz, 128 MB or more RAM, at least 1 GB of HD/SSD). Cross compiling is
possible of course, but it makes testing and bug fixing very tedious. If
ssh to such a system is available, I'll look into fixing the MIPS port
without any bounty.

FYI, the Lemote Yeeloong is a nice MIPS netbook designed for hardcore 
free/opensource geeks:


 http://www.amazon.com/Screen-Lemote-Yeeloong-8089_B-Netbook/dp/B005SYBJYE

It has: "Loongson 2f 64-bit MIPS-compatible processor, 1GB RAM, 160GB 
Hard Drive"


Disclaimer: I don't have it, I just know that it exists and sounds like 
a great option for doing a FPC port.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bounty for MIPS