[fpc-devel] On a port of Free Pascal to the IBM 370

[Tomas Hajny]

On Wed, January 18, 2012 11:23, michael.vancanneyt at wisa.be wrote:
> On Wed, 18 Jan 2012, Tomas Hajny wrote:
>> On Wed, January 18, 2012 10:15, michael.vancanneyt at wisa.be wrote:
>>> On Wed, 18 Jan 2012, Michael Schnell wrote:
>>>
>>>> AFAI learned:
>>>> I suppose the code generator should be doable, regarding that there
>>>> already
>>>> are several supported CPUs. At least a working compiler might come
>>>> into
>>>> existence in a decent amount of time, adding optimizations is another
>>>> project.
>>>>
>>>> OTOH I suppose that a porting the RTL to a mainframe OS will not be
>>>> easy
>>>> and
>>>> without this the compiler is quite useless.
>>>
>>> I do not think it is more difficult than any other OS.
>>
>> ...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.
>
> ? It just means you must convert ascii to ebcdic in OS calls that require
> strings. All these calls must be re-implemented anyway, so a generic
> routine
> to do this conversion seems like the obvious path. I doubt this will be
> the
> real bottleneck :-)

It should not be a bottleneck, but I'm afraid that you underestimate it a
bit. As an example, searching for #10 and #9 across files (just) in
rtl/inc (there's much more in rtl/objpas) shows quite a few places which
would need to be changed for EBCDIC support and which are not touched
otherwise during a RTL port (control characters have completely different
layout in EBCDIC compared to ASCII). Also case insensitive search for
"'a'" (just as an example - there are more ways how this can appear in the
code) finds several places containing code assuming either certain
position of the standard alphabet ('a'..'z') in the character set - both
assumptions regarding the absolute value of 'a' (or 'A') used e.g. for
translation of hexadecimal numbers, or assumptions about the whole
alphabet being in one consecutive range (which is not the case for
EBCDIC).


> As for using Linux: I have no idea how this works in practice, so I can't
> comment on that. I know that people here use Hercules inside linux to
> develop for zSeries, but then again running a linux inside that seems a
> bit
> like overkill :-)

Sorry, I don't understand this comment (probably because I know nothing
about Hercules). My point was simply that Linux port to S/390 exists so
one could start by creating support for the S/390 platform and testing
this new platform support with the existing Linux RTL first before
continuing with the RTL for zSeries (including necessary adaptations of
the common parts of our standard RTL).

Tomas