[fpc-devel] ABI documentation on wiki
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Tue Jun 12 22:26:14 CEST 2012
microcode at zoho.com wrote:
> Mark, Guys,
> I just added the SPARC information in the SPARC section. Looking further, I
> see Mark intended to group the ABI information together, separate from the
> architecture sections above.
> Mark: do you want to keep the ABI information separate or would it be more
> useful to group it with the coding examples? If you don't like the way it
> is I will move it. I should have read the whole page but I missed it until
> I saved my updates.
Well, the whole point of a Wiki is that the chap doing the work decides
on the layout, so I'm really in no position to dictate :-)
However, what I was hoping to do was have one collection of material
directly relevant to the lowest levels of the compiler (code generator
and assembler reader), and another relevant to the calling conventions
and RTL. And as you've said yourself, there's a decided shortage of
collected reference material for the various ABIs.
I think another argument for keeping the assembler and ABI stuff
separate is that you can have several assembler formats for a processor
(e.g. Intel and AT&T format for x86) and you can also have several ABIs
applicable to a particular processor, e.g. Linux, Windows and Solaris
> Just a note on the IBM examples, most of them don't apply to Linux since
> Linux uses a completely different ABI than MVS. Since FPC will probably
> never run on MVS (although it may well someday on z/Linux) do those
> sections really belong on the wiki?
The first example is obviously relevant, since it's part of the same
series (a fragment of kernel source) as the examples for the other
processors. I agree that the others are fairly awkward, but what I was
trying to do was demonstrate (a) the "IBM format" assembler source, i.e.
as distinct from what the GNU assembler (gas) expects, and (b) what GCC
did when told to compile for various targets. My intent with the latter
was to show how much simpler code generation was if you restricted
yourself to late-era S/390 targets (for which you apparently have to
tell GCC to target a z900), there's previously been somebody trying to
convince us that the most desirable target is MUSIC/SP running on an
S/370 and that the 12-bit offset limitation was never an issue.
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