You really have to make up your mind whether you are targeting brand spanking
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.

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.

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 misrepresent
your position here but it seems that you maintain that the implmentation should
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 does so.

I would maintain that we restrict ourselves to System/360 assembler; Why? The
overwhelming reason for this is audience. Let's face it, Pascal, whatever the
dialect or the target is not the most popular language on the planet. Having
a decent Pascal Compiler on as many targets, both hardware and OS, as possible
is a laudable goal. Free Pascal could easily fulfil that. Limiting the target
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 them
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 the FP
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 editor
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'.

Steve.

"Steve" wrote

I would maintain that we restrict ourselves to System/360 assembler; Why?

The

overwhelming reason for this is audience. Let's face it, Pascal, whatever

the

dialect or the target is not the most popular language on the planet.

Having

a decent Pascal Compiler on as many targets, both hardware and OS, as

possible

is a laudable goal. Free Pascal could easily fulfil that. Limiting the

target

If 360 assembly code can be used on modern processor variants as well I see no problem with targeting that at first only. The point with using Linux as a first target is that you would not need to implement a new RTL, but only the code generator and the processor specific RTL code. The point for gas/ld was simply that we have existing writers for these two, but writing your own writers for IBM specific tools isn't rocket science either... But it's another thing you'd need to implement.

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.

Would you elaborate what you mean here?

Regards,
Sven

Yes.

2) it supports Linux and hence has lots of FP developers

Partly.

and 3) because GCC does so.

No.

In slightly more detail:

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).

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.

3) GCC is only relevant if external libraries are to be linked, at which point it defines the ABI.

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.

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.

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.

Picking up one of Sven's points:

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.

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.

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.

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.

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!"

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

Mark is talking about compiler developers here. And most of us are either using Linux as the main platform or at least as a platform where we develop for nevertheless. So yes, basically all FPC compiler developers are Linux users more or less.

I don't see what would be perverted about that... it might at first restrict the potential user base, but it would only be a first step to allow implementing a more or less working code generator and that other OSes can be tackled.

Writing assembler by hand is not necessarily the same as letting a compiler write assembler code. At least in FPC the assembly language of each processor is abstracted in operations which are hold in lists and using an assembler writer (of which there can be multiple to target different assemblers) this list is turned into the final file.

"Here's some code, assemble it, and be quick about it johnny!"

Was that a Short Circuit reference? O.o

Regards,
Sven

You misunderstand me. Most if not all of the other FPC targets use gas as the principal assembler, although in some cases alternatives are also supported. In other words, there are issues of character set, invocation, option format, opcode format, behaviour of pipes and files, and so on.

Quite frankly, from what I've seen most Windows users would find Linux simpler than one of the *freely* *available* IBM OSes (i.e. MVS, VM/360 "sixpack" and so on).

The alternative, is to leave them to C, a fate I wouldn't wish on anyone.

We can agree on that at least, although I must say that C has improved a lot since K&R days.

OK, that's fair comment. But can you suggest a free (as in both beer and speech) assembler that is available for the various platforms that FPC developers use (Linux on x86, x86-64, PPC, SPARC, ARM; BSD; Windows)?

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.

I prefer to keep things friendly, but if you are going to issue vicarious threats of legal action then I'd much prefer it if you didn't try to put words into my mouth or distort my meaning. I very clearly referred to "freely-available versions of MVS, VM/CMS and so on", I really don't see how you manage to mangle that into a derogatory statement about z/OS or any current product.

Mark Morgan Lloyd wrote

Quite frankly, from what I've seen most Windows users would find Linux simpler than one of the *freely* *available* IBM OSes (i.e. MVS, VM/360 "sixpack" and so on).

To avoid ambiguity: that was a typo, and I meant "VM/370 'sixpack'".

As background: it appears that IBM didn't embed copyright notices in the source or binary of their early operating systems, with the result that older versions of the DOS, OS, and VM lines are now described as being in the public domain. There's a hobbyist community that runs these under the Hercules emulator, IBM is aware of this but generally keeps its distance.

All of these date back to the era when addresses (certainly per-process, and usually system-wide) were 24 bit, i.e. there was a process or system restriction of 16Mbyte of "core". Unfortunately, GCC can't compile itself in 16Mb, so somebody's created a patch for the Hercules emulator and for the operating systems which allows one program at a time to allocate storage from "above the line", this is referred to as the /380 hack http://mvs380.sourceforge.net/ and hardly anybody's happy about it.

It was intended as a joke, hence the smiley. A little, no tiny, joke... maybe. I'm afraid I have a dim view of Linux even though, or perhaps because, I am a long-time Linux user. Another joke... sort of!

I'm aware of that, but I don't see how that makes a difference to how the compiler generated assembler is treated differently to the stuff inside a TP ASM block, inline assembler, or am I misunderstanding Mark's point.

> "Here's some code, assemble it, and be quick about it johnny!" Was that a Short Circuit reference? O.o

Once again in English please. I just don't understand that last sentence at all. Sorry.

Regards,
Steve

What relevance does GCC have? The fact that there is an environment in which it may not work isn't regarded, by me at least, as unfortunate.

Yes, but the difference isn't that wide. You keep saying that Linux is the answer and I keep agreeing with you. It's not the issue.

The thought of VM having a "six-pack" has my mind wandering into some very unpleasant areas :-) (JOKE ALERT)

> The alternative, is to leave them to C, a fate I wouldn't wish on anyone. > We can agree on that at least, although I must say that C has improved a > lot since K&R days.

I'm afraid I can't agree on that one.

Tachyon produce a free HLA compatible assembler. z390 is a sort of emulator that runs on Windows and Linux, it's written in Java (!), IBM produce one that may be, but probably isn't, free. There may be others too.

Whoa there, calm down. I threatened no-one. I apologise if that's how it came across.. I have no links with, or knowledge of, the thoughts and practices of the IBM legal department. However they be perceived. It was a way of observing, humorously I thought, that IBM wouldn't be happy to see their flagship OS or it's hardware, used, still, by huge mega-corporations throughout the known universe to run economy critical applications referred to as:
1) "antique" (Tue Aug 20 16:54:44 CEST 2013)
2) a dinosaur (Tue Feb 7 09:12:53 CET 2012)
3) broken (Fri Jan 20 11:00:38 CET 2012)
4) contemporaneous "micro mainframes" are woefully underpowered (same date) OK no 2 wasn't by you, but the others were. And they are not isolated cases. Don't misinterpret me again, I am not saying you cannot have these views or that they are necessarily invalid, I just reserve the right to point out that I consider them invalid :-)

By the way referring to 1). MVS was first released in 1974, what year do you think Unix was first licensed to someone outside Bell Labs? No cheating now, don't go slipping off to WikiPedia (like I did). Yes... Pound of bananas to the man in the back, 1974. And yes, I am aware of the fact that Linux is very different from Unix from 1974. Just as z/OS is very different from MVS from 1974.

Regards in a very friendly non-threatening way
Steve

Oh for crying out loud! First, when I've used epithets like "antique" I've specifically been referring to the versions of (loose terminology) OS, DOS and VM that are described as being in the public domain and are run (with or without the /380 hack) by a significant part of the Hercules crowd. These date back to around 1980: if they aren't antique (in computer terms) then what is?

As far as (4) goes, I remember that: I was specifically referring to the "mainframes" that IBM integrated onto MCA cards and sold with OS/2 drivers. These might have had marginally acceptable performance in the late 80s (or whenever) but by today's standards and in particular when compared with Hercules (or IBM's equivalent) on a well-specified system I don't think that my description is uncharitable.

I thought that MVS was basically OS, in which case I'd have thought that the significant date was around 1965. And I'd not knock it for that, since I'm older...

Regards in a very friendly non-threatening way Steve

And I got through that without being rude about EBCDIC even once :-)

Short Circuit movie - Johnny5 is the AI robotic main character escaped from a military facility...

compiler

> write assembler code. At least in FPC the assembly language of each > processor is abstracted in operations which are hold in lists and using

an

compiler generated assembler is treated differently to the stuff inside a TP ASM block, inline assembler, or am I misunderstanding Mark's point.

Assembler blocks in FPC are handled by a assembler reader which needs to be implemented for each assembler language variant that needs to be supported (e.g. on x86 systems we support Intel and AT&T syntaxes whereby each has its own reader implementation). These readers convert a parsed assembler operation to an abstract assembler operation which is independent of the assembler syntax, but CPU dependant. At the end an assembler writer converts the linear lists of assembler operations to a assembly language file for the chosen assembler which may contain additional information not present in the assembler block and which also does not need to be the same assembler syntax that was parsed originally.

So for a new CPU platform you need to implement at least an assembler writer, an assembler reader (which could be at first so primitive that it can only handle the necessary RTL assembler blocks) and a linkscript writer which is passed to the external linker to link together all generated object files.

at all. Sorry.

As waldo already wrote "Johnny" is the name the robot of the movie "Short Circuit" gave itself at the end of the first movie and is used extensively in the second one. Also he his told by his friend to assemble toy robots that resemble Johnny which is why I thought it was a reference.

Regards,
Sven

Steve wrote

>> We can agree on that at least, although I must say that C has >> improved a lot since K&R days. I'm afraid I can't agree on that one.

I think it's fair to say that nobody here /likes/ C, otherwise he'd not be working on Pascal. But a few weeks ago I had to knock together a Linux kernel module, and I will state as a fact that if C still had the same level of syntax checking etc. that it had in the late '80s I'd probably have failed dismally.

Of course, if I weren't bone idle I'd have investigated whether FPC has the ability to target the kernel module format, although I'm fairly sure that nobody's tried it on SPARC before now.

Am 26.08.2013 19:45 schrieb "Mark Morgan Lloyd" <

: Of course, if I weren't bone idle I'd have investigated whether FPC has

the ability to target the kernel module format, although I'm fairly sure that nobody's tried it on SPARC before now.

It's a bit dusted, but here:
http://wiki.lazarus.freepascal.org/linux/kernel/module_development

Regards,
Sven