[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

[Steve]

First, let me apologise for that last email. The subject and the formatting
was awful. I blame my eMail client, not the fact that I am incompetent. The
latter is a calumny that I will defend to the utter limits of the law. :) At
least it wasn't HTML.

(Brain the size of a planet but thunderbird just totally baffles me I'm
afraid)

To business...

Sven wrote

  > If 360 assembly code can be used on modern processor variants as well I
  > see no problem with targeting that at first only.

Modern processors provide new instructions that would certainly make life
much easier, but IBM put a load of effort into keeping forward compatibility
intact. This is true even at object code level. I have worked in
environments that lifted Fortran compilers that were 25 years old and run
them successfully on modern OSes without recompilation. The only fly in the
ointment is Linux (isn't it always the case!). IBM do not supply an
assembler for Linux. They use gas. But there are "proper" Assemblers available.

  > The point with using Linux as a first target is that you would not need
  > to implement a new RTL, but only the code generator and the processor
  > specific RTL code.

Hmmm! I think it will be more complex than that... Certainly, anything
related to I/O will need to be drastically rethought, even before it's
rewritten. The I/O architecture is just too different.

  > The point for gas/ld was simply that we have existing writers for these
  > two, but writing your own writers for IBM specific tools isn't rocket
  > science either... But it's another thing you'd need to implement.

You don't have existing writers! They may be familiar with the basic syntax
that gas/ld use, but IBM assembler, gas, Assembler F or High Level Assembler
has a totally different vocabulary. The semantics are also unique. CALL
exists but is different, RET doesn't exist. JMP and it's variants are called
B (B for Branch) and the variants are different. What is the difference
between L and LA? What are L and LA? MOV doesn't exist, there a whole host
of different instructions for moving data depending upon source, destination
and format. Do they understand what the 16M line and the 2G bar are and
their implications for code? And a whole other list longer than my arm. The
manual that defines the Assembler language is, at last count, 1292 pages of
A4! All of it different from what your pool of gas coders is familiar with,
unless they have previously written IBM Assembler, in which case they
probably used Assembler F or one of it's successors.

And it's not just the assembly language that's different, the target
hardware bears absolutely no relation to what they are used to apart from
the fact that it uses 8-bit bytes; The I/O subsystem is radically different,
even the character set is different.

 > > If we use gas/ld we put ourselves in the same situation Delphi landed
 > > us in with the use of non-standard libraries; Writing individual
 > > wrapper functions for every other function under the sun.

  > Would you elaborate what you mean here?

Sorry, isn't this a universal problem, or is it just me? Anyway.. If I am
writing code in Delphi and I want to use, say, MySQL; I have a problem;
Delphi provides no mechanism to call MySQL. If I am a C programmer, I just
include the .h file and MySQL is available. Instead, I have to troll round
the internet looking for a component or set of components to provide this
support. Often especially in the early years of Delphi, there wasn't one. So
I have to write my own. I sit down with the manual and the MySQL.h header
file and reverse engineer the relevant code from it's C equivalent. I bought
Delphi so I wouldn't have to mess around with C. I hate C. I consign it the
same hell that 380 belongs in... No, I consign it to the lowest levels of
hell. (Deep breath).

But everything is defined in terms of C and, ultimately has to be reverse
engineered into a Pascal equivalent. Wouldn't it be nice if I could say
"Uses MySQL;" and away it goes. If it can't find a Delphi unit it looks for
MySQL.lib or MySQL.h or whatever and generates the code for me.

I'm sure you're aware of the process, and, yes, I am aware of the problems,
but you asked me to elaborate.

The same thing exists in MVS, and the other OSes too but I am an MVS man so
I will stick to that. If I want to link to a system facility or another
product there are a number of different ways it can be achieved.

1) Use a macro. All base OS facilities are defined by Macro interfaces. Some
of the actual binary interfaces are documented. Some are not. Without a
varying amount of reverse engineering, gas won't allow us to use them. You
called them a "shortcut" in another post. Sometimes they are; Sometimes they
are the only sensible way to go because the long way round is far too
complex. To take 1 example; Memory management in MVS has 4 or 5 (I think)
Supervisor Calls to allocate and deallocate a block of memory. Which one is
required depends on the parameters passed to the macro, it's  is not a
trivial task. Gas doesn't allow macros.

2) Use CALL to link to an interface module. In these cases the CALL
interface is documented, but the actual code to link to the product is
complex. It may involve Authorisation changes or Address Space switches or
finding addresses of Object Code only storage areas. The CALLed code is
linked automatically by the linkage editor. Ld can't read MVS load libraries.

3) DB2 and CICS, along with IMS these are the war-horses of MVS application
development. They use a pre-processor. The assembler source code is fed into
a pre-processor, it generates the required assembler and the output is fed
into the assembler. The pre-processors don't understand gas assembler, 
except, possibly, for the latest and greatest versions. These interfaces
are complex command-oriented ones and the assembler equivalents
are not documented.

Elaborate enough? :)

Regards,
Steve