[fpc-devel] Re: fpc-devel Digest, Vol 112, Issue 32
stevie at collector.org
Fri Aug 23 01:59:54 CEST 2013
On 22/08/13 11:00, fpc-devel-request at lists.freepascal.org wrote:
> Mark Morgan Lloyd wrote
> GCC plus the basic utilities are definitely ported to VM/370 and
> MUSIC/SP (i.e. I've run them), and as far as I know to the others. In
> all cases possibly subject to memory restrictions, i.e. might need more
> than the standard 16Mb supplied by older operating systems for large
> jobs (that's where the /380 patch to Hercules comes into it).
You really have to make up your mind whether you are targeting brand
new kit or ancient kit with non-standard hacks to partially support 31-bit
addressing modes. Personally, I think 380 is an abomination that should
have been drowned at birth, but, it exists, so I have no problem if other
people wish to use it. I don't shove my views down their throats and I
expect them to be as considerate.
> Don't guess, seehttp://wiki.lazarus.freepascal.org/ZSeries which apart
> from anything else has links to the original GCC implementation notes
> which in part determine what architecture variants Linux supports.
> However there also appear to be later ports which support older CPU
> variants, see link below.
The notes for the original GCC implementation are a mixture of errors and
propaganda produced by a company with an agenda of selling the modern kit
at which their implementation is aimed and no interest, in fact an outright
hostility to, products like Hercules. Now. I have no issue with their
implementation, it has a very good reputation, but their original premise
is flawed. The later ports, GCCMVS, use 380 (see above). They also don't
use as but a "proper" assembler (HLASM I believe) and a "proper" linker.
As for the wiki you refer, I am familiar with it as I wrote the vast
majority of the post.
>>> >>My own feeling is that it would be best to start targeting a late-model
>>> >>390, which does have a stack etc., and to use the standard GNU assembler
>>> >>and linker (as and ld)/initially/ targeting Linux. Any other
>>> >>combination (i.e. a proprietary assembler etc. with an antique MVS as
>>> >>target) is going to cause nothing but grief, since it makes it very
>>> >>difficult for developers skilled with FPC but not with IBM mainframes to
>>> >>give any practical help.
>> >Late-model 390's have a stack, but not as you know it. It's not something
>> >you can go around lobbing arbitrary data at. It is reserved for data saved
>> >during subroutine linkage using the appropriate hardware instruction
>> >(Branchand Stack). This includes various register sets, PSW status info etc)
>> >and anadditional two 32-bit signed or unsigned integers (64-bit in later models).
> The examples at
> show a significant simplification of the code when a newer architecture
> is specified.
Of course they do, just as 686 implementations are simpler than 386 ones.
Most of this is just pussy footing around the issue. Forgive me if I
your position here but it seems that you maintain that the implmentation
use a modern instruction set because 1) it generates simpler assembler 2) it
supports Linux and hence has lots of FP developers and 3) because GCC
I would maintain that we restrict ourselves to System/360 assembler;
overwhelming reason for this is audience. Let's face it, Pascal,
dialect or the target is not the most popular language on the planet.
a decent Pascal Compiler on as many targets, both hardware and OS, as
is a laudable goal. Free Pascal could easily fulfil that. Limiting the
audience to Linux/390 is, well... limited. (Sorry). Linux/390 users must
represent a pretty small gene pool. Many hercules users do not have access
to environments that support the rinky-dink new instruction set. They run
old operating systems. Using Assembler F compatible code supports ALL 390
environments. The same compiler, with a different RTL should work on all
OS versions. This means finding a common denominator, 360 assemblers are
available for all IBM environments. In any case, you seem to assume that
existing FP developers are familiar with Linux; I would imagine many of
are Windows users and as familiar with Linux as they are with MVS.
Secondly, the question has to be raised about what people may do with
port when it's available; Link to a relational database like DB2 or a
transaction processing system like CICS, or a TSO facility like ISPF or...
a hundred and one other uses. Most of these environments require access to
one or more of an IBM compatible Assembler, an IBM compatible Linkage
or an Assembler pre-processor that understands 360/370 assembler. If we use
gas/ld we put ourselves in the same situation Delphi landed us in with the
use of non-standard libraries; Writing individual wrapper functions for
every other function under the sun.
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'.
More information about the fpc-devel