Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2012-02

Re: EBCDIC (was On a port of Free Pascal to, the IBM 370)

3 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

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

Show quoted text 5 lines
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.

Show quoted text 7 lines
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! :-)

Show quoted text 5 lines
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?)

Show quoted text 10 lines
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

Reply by email

Mark Morgan Lloyd
to steve smithers
steve smithers wrote 15 lines
> 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).

Show quoted text 10 lines
> 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.

Show quoted text 5 lines
> 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 :-)

Show quoted text 7 lines
> 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 :-)

Show quoted text 12 lines
> 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.

Show quoted text 9 lines
> 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]

Reply by email

Tomas Hajny
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 25 lines
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).

.
.

I guess that Steve meant something different. Regardless from the underlying platform, a general binary file may still contain strings; they are just not delimited by line end characters but possibly part of a fixed structure or using something like ASN.1, etc. The difference is that you cannot use something like GNU recode (or some equivalent available on S/390) on such a file to convert it from EBCDIC to ASCII before accessing such a file with a FPC program because this would break the real binary parts inevitably. You can't leave the translation on the RTL either (at least not fully - you can possibly still use some helper, of course, but you need to take care of that explicitly in your program), because the typical solution involving BlockRead would not perform any translation. If you store the read data in a string, they're still EBCDIC. If you start using RTL string manipulation functions on them (e.g. Val), they will fail. You can still "convert between ASCII & EBCDIC on input" as suggested in your previous comment, but you need to do it explicitly in your program rather than automatically in the RTL.

BTW, this is the part where the Sven's suggestion of translation to Unicode together with only using Unicode strings within the program (except for the read buffer) would help; the question is how easy or difficult is Unicode manager implementation on that "OS".

Tomas

Reply by email