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
