[email protected] 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]
_______________________________________________
fpc-devel maillist  -  [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to