? 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.
IMO the only bottleneck could be the availability of 8 bit bytes
(dunno). At least I remember mainframes with byte sizes of 6..16 bits.
When at least 8 bits are available, then a program can use
ASCII/ANSI/UTF-8 internally, and strings have to be converted into
EBCDIC in system calls, like they have to be converted for every OS with
specific character sets or encodings.
It would be a real challenge to adopt FPC and all ordinal type handling
(and pointers!) to a different byte size. E.g. DG machines only can
address 16 bit words, so that access to 8 bit entities requires explicit
machine code, and PByte or PChar is very tricky to implement. On such
machines UTF-16 would be a good choice for the native string type.
DoDi
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
