Bernd Oppolzer wrote:
Am 21.08.2013 22:17, schrieb Steve:
Mark Morgan Lloyd wrote
> Otherwise we also rely on external tools (mostly the GNU linker)
> here. So as a first step you'd choose the approach of using an
> external assembler and linker, because simply calling a third party
> utility is easier than completely implementing an internal assembler
> and linker.
With the caveat here that as I understand it experienced IBM programmers
avoid the GNU assembler like the plague, since it doesn't have anything
like the sort of macro facilities they're used to. By implication, that
would imply that they prefer to avoid the GNU linker and related tools
as well.
There is a problem inherent in this discussion; zArch is not one
environment!
It's one architecture supporting multiple operating systems, much like
the
386/486/586/686 etc supports Linux or DOS or OS/2 or Windows (all 37
versions)
etc. zArch has MVS (in all it's varieties) VM, DOS, LINUX, MFT, MVT,
MUSIC/SP,
and loads of other more niche stuff. In addition to all this, later
versions of
MVS supply a POSIX compliant shell called OMVS. GNU anything is
available in
hardly any of these environments even if we can handle the brain-dead
assembler.
This is correct, but it should be possible to cover most of those
systems with
one RTL - much the same way as LE (language environment) does it in the
"big" IBM world, too.
I suspect that targeting "classic" OSes which use EBCDIC would need a
branch of the RTL, even if the sourcecode in that branch were in ASCII.
I also suspect that- however attractive this is- trying to port the
compiler so that it would self-host on EBCDIC-based OSes would
effectively fork the project, unless somebody could come up with a neat
hack to automatically convert patches back to ASCII when they're sent to
the Subversion repository.
Thought for everybody even remotely interested: if we could standardise
on the first line of every unit being a non-essential comment (and
specifically, not a compiler directive) then it would be possible for
the parser to decide whether it were looking at ASCII or EBCDIC before
hitting anything important.
compilers. I recently learned a bit about the MIPS architecture, and it
seemed to
me to have some similarities to IBM's, so I guess, a kind of
"translation" from MIPS
to IBM could be successful.
A postcompilation translation probably wouldn't work since e.g. there
are different ranges of parameters used for compiler passing, but I was
wondering whether the MIPS directory could be moved en masse. But again,
note Florian's warning about this.
to IBM could be successful. Many people say that the IBM platform is the
only
remaining platform today that reasonably can be programmed using
assembly language,
because of the clear structure of the instruction set.
In fairness, the x86 probably falls into that category as well. However
I think most people abandoned x86 assembler when both Linux and the NT
family of OSes demonstrated that C was adequate for portable device
drivers etc.
I would strongly suggest not to use the "new" hardware stack, but
instead to
rely on the OS linkage conventions (save area chaining, register 13), which
in fact are used by most of the operating systems mentioned above - with
minor differences.
Noted, but I think we have to go along with Linux practice for the
initial port.
--
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 - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
