[fpc-devel] ABI documentation on wiki

[Mark Morgan Lloyd]

microcode at zoho.com wrote:

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

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

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

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.

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

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.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]