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

[Mark Morgan Lloyd]

steve smithers wrote:
>> 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.

I'd only expect the version control system to contain textfiles. Or are 
you saying that some IBM operating systems support files which contain 
both text and data (I'm aware of the Mac's OS and obviously OS/2 doing 
this, both of which FPC supports).

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

It's a convenient common denominator, supported with varying degrees of 
enthusiasm by a range of manufacturers. In addition, the FPC build 
procedure is unix-oriented which in due to ready availability implies Linux.

>> 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! :-)

Constructively so, I hope :-)

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

No, but having an accessible operating system for testing is, and it 
would end up being extremely inconvenient if that operating system 
didn't support standard networking so that- at the very least- test code 
code could be got onto it and copies of error messages got off. I don't 
think the other developers would be happy if told they had to use 
(something equivalent to) Kermit :-)

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

Just trust me then. PC doctrine has it that anybody can write a 
compiler, but we're aware of the fact that other architectures might do 
things differently.

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

In the case of Linux on S/390 (and successor systems), it will generate 
a file for ld. ld will generate ELF, marked as being ready for execution.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]