[fpc-devel] Re: EBCDIC (was On a port of Free Pascal to the IBM 370)
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Mon Jan 30 22:46:28 CET 2012
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]
More information about the fpc-devel