[fpc-devel] ABI documentation on wiki

[microcode at zoho.com]

On Tue, 12 Jun 2012 20:26:14 +0000
Mark Morgan Lloyd <markMLl.fpc-devel at telemetry.co.uk> wrote:

> 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 :-)

Not at all, I just didn't take the time to review the whole page. My fault,
and happy to change it to your liking.

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

I have moved the material to the end section. I also added a link to the
Linux MIPS page that has the MIPS ABI linked from it. Until now I think
we're safe with so many levels of indirection ;-)

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

Right, I said "most of them don't apply" and even that was somewhat of an
understatement since the entire platform is completely unsupported in FPC,
as you know. I would have added comments in the wiki but I didn't know how
to create a small discussion section where the comments would be understood
to be linked to particular topic.

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

I don't think this is relevant since gcc doesn't target IBM's assembler.
Given z/Linux support is just a dream right now and MVS support is not on
the horizon, I think it's just confusing to have the material there, just
as it would be to add ABI or assembly examples for other platforms FPC
doesn't support now and likely won't support in the future.

Is the page to be about FPC, or a generic assembler page? That's really
where I'm coming from. I think too much information can sometimes not be
helpful.

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

I don't think you can conclude that, because there are too many variables.
gcc targets only gas as a back end, the IBM assembler isn't an option. On
z/Linux there is no IBM assembler, there's only gas. So really the
discussion ought to be focused on that reality since people understand
Linux and gas.

The later code examples aren't more clear to IBM programmers since the
relative and immediate facility, although not exactly new, hasn't been
widely adopted in hand written assembler. The z900 code generated by gcc is
especially unfamiliar since gcc isn't used on IBM products except for the
public domain versions from the 1970s. z/OS customers get IBM's C/C++
compiler which of course is far better than gcc and has no licensing or
runtime issues, and does have a much better runtime than gcc. 

Anyway, gcc's z900 mode uses not only the relative and immediate facility,
but also the 64 bit versions. Any this is not representative of what IBM's
C/C++ compiler will generate, since IBM's C/C++ targets object code
directly, and not any assembler back end. Although you can get the IBM
compiler to produce an "assembly listing" that is not what the compiler
uses to do code generation, it generates object code directly.