On 23/08/13 09:57, Mark Morgan Lloyd wrote:
1) The slightly newer opcodes make the 390 look more like the canonical CPUs
that most people are used to these days. Since any attempt to implement a
port without the help (or at least tolerant supervision) of the core
developers is doomed, I think that using recently-introduced facilities is
justified. Note that I'm /not/ suggesting going over to a full 64-bit
implementation, since this would really complicate a subsequent port back to
strict 390 or 370 compatibility (i.e. 32-bit data and 31- or 24-bit addresses).
If you really think that using gas is going to allow existing 386 family
developers to write assembler for a 390 processor then I'm afraid you are in
for a sever disappointment. Understanding the assembler is a minuscule part
of the skill-set you will require. The newer opcodes do indeed make life
simpler, but the environment is still radically different.
2) If an existing FPC developer wants to get involved, it's not reasonable
to expect him to have to work up the learning curve of MVS before he can
actually run the target environment. Linux on Hercules is a no-brainer.
Linux on Hercules is a no-brainer for Linux users; Not all fpc developers
will be Linux users.
3) GCC is only relevant if external libraries are to be linked, at which
point it defines the ABI.
It defines the ABI for Linux.
I'm /not/ banging the drum unreservedly for GCC and Linux, but IBM (and many
other companies) promote it as a "universal API" and I like to think that
they're not total idiots.
Firstly, I am not necessarily proposing that we don't concentrate on Linux
initially, in fact it makes a certain amount of sense (In a perverted way
:)) My EXAMPLES concentrate on MVS because that's my background.
I have never, ever accused IBM of being idiots; Total or any other kind.
The universal API that they bang on about is based around C and was, in
large part, written by IBM (at least the Linux/390 implementation was). If
there is any intention of providing FP on anything other than Linux/390, IBM
(and many other companies) will not be involved, it will be people who do
this sort of work for a hobby. The alternative, is to leave them to C, a
fate I wouldn't wish on anyone.
Similarly, I'm not banging the drum unreservedly for GNU's as assembler
etc., since I recognise that a great deal of useful work has been done using
IBM's assemblers. But the GNU tools are freely available, while as I
understand it IBM (and clone) assemblers aren't: it's not realistic to
expect developers to sign a "no commercial use" agreement etc. since this
would infect the entire project in a way that the (L)GPL doesn't.
I can't speak for all the clone assemblers, some of them, I know are freely
available with no restrictions or licenses involved. All of IBM's assemblers
are 'licensed' programs with no restrictions AT ALL on the works developed
by them. The Assemblers I am suggesting for older OSes have freely
available, no charge, no contract licenses. Download and go!
So I think that it's worth considering 32-bit Linux using GNU tools as the
initial target. But it's not my choice, I'm only the guy with a foot in both
the FPC and mainframe camps who's doing his best to prevent them drifting
off in uncomfortable directions.
As am I.
There's also the issue of the assembler reader (used, if I understand things
correctly, to parse inline assembler mostly in the lower-level bits of the
RTL). This seems to cause almost as much problem during development as the
assembler writer, and having to support (or at least pass through) complex
assembler macros isn't going to make things any easier.
I don't really see why passing macro calls through to an external assembler
is any different than passing 'raw' code. It's just text isn't it? "Here's
some code, assemble it, and be quick about it johnny!"
Your choice is really nothing to do with me. I don't plan on getting
involved. I just don't like to see half-truths and misunderstandings
being passed off as the 'one true way'.
If I were promoting a "one true way" I wouldn't be doing my best to keep
open the secondary option of getting FPC running on (or at least generating
code for) older OSes such as freely-available versions of MVS, VM/CMS and so
on using IBM-format assembler. But I don't think these are viable primary
targets.
It seems to me that the people who are volunteering to do the work run these
non-viable environments. I wonder what they think? And, if you keep implying
that z/OS is antique and non-viable, IBM's lawyers may be on your rear-end
because it is neither.
Steve
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
