[fpc-devel] Re: fpc-devel Digest, Vol 112, Issue 32

[Steve]

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