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

[steve smithers]

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