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.

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?

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.

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.

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

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.

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.

The issue is that a couple of people had already posted messages in this mailing list proposing a port of the compiler, and specifically suggesting that IBM's assembler was used as a backend. The limited work I've put into exploring the architecture was intended as a rebuttal to the latter part of that.

Historically, I've had zLinux running on Hercules for a couple of years, and I wrote some notes as the "Overview" section of http://wiki.lazarus.freepascal.org/ZSeries [checks history] in around December 2010. Subsequently, I added the "Architectural details" section as a transcript of Steve Smithers's attempt at telling us how to handle a port: note that that specifically refers to EBCDIC encoding and 12-bit offsets, I am not the original author of that and do not espouse its position.

I am responsible for "Digression: example FPC output", which I added so that Steve (and anybody else not familiar with the innards of the compiler) could see what nodes were being emitted and the assembler they contributed. I'm also approximately responsible for the following sections.

Note also Paul Robinson's
http://wiki.lazarus.freepascal.org/ZSeries/Part_1 etc., and note that his proposed target is s/370 running MUSIC/SP.

Hence

That's not entirely true: there's a port of GCC that generates IBM-format assembler, and as I've shown above there are people suggesting use of that format.

Noted. As a general point if I could go back to your

platforms FPC doesn't support now and likely won't support in the future.

It can be difficult to get a full picture of what backends are complete, in use, and maintained. For example, there are backend directories in the trunk sources that don't exist in the stable release, and there are directories in both that are basically just placeholders- ia64 is one of these. Then there are branches, some sanctioned by the core developers and either in the main repository or in Lazarus CCR, plus possibly private projects which is how David Zhang's MIPS port came about... for all we know Paul could be making good on his promise to do the port but keeping his head down.