On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 11:23, [email protected] wrote:
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 10:15, [email protected] 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.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
