[fpc-devel] Re: fpc-devel Digest, Vol 112, Issue 32
stevie at collector.org
Fri Aug 23 19:44:39 CEST 2013
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
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.
More information about the fpc-devel