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

[Mark Morgan Lloyd]

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]