On 01/01/18 13:00, Graeme Geldenhuys wrote:
> I remember back in 2012 (I think) there was a large discussion about
> implementing support for the zSeries IBM mainframes. The wiki had many
> pages on the topic too.
> http://wiki.freepascal.org/ZSeries > Anybody know what actually happened with those efforts? Was there
> something usable in the end?
There was a lot of discussion that boiled down to five things:
* Should the compiler (as distinct from the generated code) use EBCDIC
and what effect did this have on collation order assumptions?
* Older members of the range used a proprietary floating-point format.
* Older members of the range didn't have dedicated stack operations and
were restricted to a 12-bit relative addressing offset.
* Allowing for the unrestricted availability of 1980s operating systems
that were restricted to the above, what should the target of an FPC
* What assembler would be supported, allowing that IBM system software
long described interfaces in terms of assembler macros?
One developer- who put a lot in the wiki- appeared to grind to a halt
when he realised that it wasn't possible to generate a static
cross-reference listing for the FPC compiler, due to the number of
runtime decisions made based on the class of elements in the parse tree etc.
If I may express two personal opinions:
* My preferred target hardware would be the oldest that got stack and
large-offset support, which was also where GCC started taking it fairly
seriously. I believe there is at least one GCC port that targets older
hardware (Paul Edwards?).
* My preferred target operating system would be VM/380, which is VM/370
with what is effectively a DOS extender to allow it to compile programs
that require >16 MegaOctets. My basis for this preference is that its
lineage (Multics etc.) makes it pleasingly familiar to people used to
PC-DOS and unix, I've been criticised by somebody who would prefer MVS
on the basis that the interface macros are different but I consider this
to be a detail since the code generation would probably be common.