[fpc-devel] Re: EBCDIC (was On a port of Free Pascal to, the IBM 370)

steve smithers stevie at collector.org
Thu Feb 2 15:38:08 CET 2012

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


More information about the fpc-devel mailing list