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

[michael.vancanneyt at wisa.be]

On Wed, 18 Jan 2012, Tomas Hajny wrote:

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

But then you are assuming the RTL should be using EBCDIC internally as well ?
Obviously, that will be a lot more work.

But I don't think this should be so.

Michael.