Tomas Hajny wrote:
...except for the EBCDIC stuff, because the common parts of our RTL assume ASCII in many places (most of them probably not that difficult to fix by adding some platform specific constants changing the behaviour from ASCII only to consider EBCDIC too, but scattered around many places and thus difficult to find). That doesn't mean it shouldn't be doable, of course, it will just require debugging even parts which didn't have to be touched during ports to other operating systems.
I used a macro processor called Stage2 for years which was completely character-set agnostic, assuming only that 1..9 were contiguous and in sequence and putting them (plus a small number of other special characters) on the first line of any file; I was looking at an APL implementation a few weeks ago which did something similar. Thirty years ago it might have been worth writing an RTL like that, but these days ASCII and UTF-8 are so utterly dominant that I see little point.
Still, starting with the Linux for S/390 (or are S/390 and S/370 completely different animals?) as suggested by Mark would be probably a
The S/390 is an incremental change from the S/370, in the same way that zSeries is an incremental change from S/390. However in any one of those architectures there is a significant number of models, and- crucially- there is a change at one model of the 390 which allows it to accept inline literals rather than insisting that these be in a table which is within 4K of the current PC. As I understand it, GCC doesn't support models that predate that change, and frankly I don't see why FPC should either; however I don't know the model's formal designation or how to check for it in RTL code.
very good idea to avoid having to tackle both a different HW platform and a different OS at the same time (the Linux port to S/390 apparently uses ASCII according to what I found on Internet). Obviously, the OS may follow once the new HW platform is in working state.
In my experience, Linux running on an (emulated) S/390 looks almost exactly like Linux running on any other CPU. There are no character set issues, and no obvious issues relating to endianness or floating-point format (I've had no need to examine FP binary representation, but I think that these days the machines support IEEE).
I'd also point out that IBM have a developer relations program, which makes a (Red Hat?) VM available to anybody who needs it. I'm sure this project would qualify for that.
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
