[fpc-devel] ABI documentation on wiki

[Mark Morgan Lloyd]

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 
for x86-64.

> 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]