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]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
