> If you try to achieve a port by modifying all code that deals with > characters you will fail. The amount of work becomes then far too big for > a single person, and the modifications become too huge and wide-spread > that you will raise objections for merging it with the SVN trunk.
That's a good point, but I'm not really suggesting doing it all in one hit. > In other words, do yourself a favour and keep ALL processing in ASCII. You > can convert between ASCII & EBCDIC on input/output. That way the > modifications in order to support EBCDIC are well concentrated in a single > piece of code, which can be easily merged without risk of destabilizing > the code base. You can't convert that way, at least not all the time. There are always going to be mixed string and binary files. > You can then use your manpower, and you still need *a* *lot* of it, to > write a code generator & RTL. > I'd suggest that the thing to do is to first target the compiler at > Linux, i.e. ASCII, hosted on a PC. Once that is adequately working > branch the RTL for EBCDIC, with the intention that this is basically a > set of conversion patches and that the master remains ASCII. I would tend, reluctantly, to agree. Even though I am a Linux user, I have to admit to some reservations about it. > Or of this isn't acceptable because the IBM developers feel we're trying > to force them into our image, let's meet half way and use Solaris which > nobody really enjoys. Now you're being silly! :-) > With the major limitation here that MUSIC/SP- and possibly other > operating systems- don't have TCP/IP unless the underlying platform > supports IUCV; Hercules (freely available to everyone) doesn't implement > IUCV unless VM (not freely available) is running on top of it. Linux > appears to get around this restriction by using a simulated SLIP connection. TCP/IP is not a compiler issue. (Is it?) > Sorry, you've missed my point. I've come across systems where compilers > have to be "blessed" by the local security administrator before they can > mark code as executable, and there's a progressively stronger chain up > to the point where nobody except that manufacturer can bless a compiler > such that it can generate the operating system kernel. The objective is > to try to avoid the situation described by Ken Thompson in his 1984 > "Trusting Trust" paper http://cm.bell-labs.com/who/ken/trust.html > > Unix does not have this mechanism: anybody can build a compiler which > can then build a new kernel. Sorry, Whoosh... Way over my head. I still don't understand, sorry! > Please note that I'm not being critical, simply attempting to summarise > the situation for somebody who might not appreciate the nuances, > particularly in view of an earlier comment that it might not be possible > to do the final build on a PC. You can do a build on a PC up to a point. Certainly the assembler output could be generated, in whatever format. It may be possible to lob this through the assembler and generate object files, I don't know what format(s) gas will write. -- Regards, Steve _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel