[Info-vax] The (now lost) future of Alpha.

[invalid]

On 2018-08-01, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2018-07-31, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 7/31/2018 4:21 PM, invalid wrote:
>>> The problem is you don't have any knowledge of the environment
>>> you're lecturing about.
>>
>> Compilers are not or at least do not need to be environment
>> specific. They are only source language and target ISA specific.

No, again that is an oversimplification.

Compilers are source language, ISA, and OS specific. And that is where you
keep shooting yourself in the ass arguing with me. I get it that you
understand source languages and the idea of ISAs. What you don't realize is
you don't know anything about the OS or the environment you're arguing
about. 

> I think invalid may have been talking about the cultural environment,
> not the technical environment in this case.

No, I'm talking about both. I have not seen that anybody on this list knows
anything significant about MVS. I don't come here lecturing you guys about
how VMS works, because I have no idea. Please, start returning the favor ;)

I do have a very good idea about what goes on and has been going on with
mainframes for quite a few decades because this is what I work with every
day. Trying to keep up with the misstatements and tangents here is becoming
difficult.

If you don't like the answer, don't ask the question. I see a lot of wild
ass generalizations on here that don't apply in my world. It's good if you
get outside your envelope every so often, that's why I read the posts on
comp.os.vms...

> However, while I agree with you in general when it comes to the technical
> environment, you should also look at all the latest version required
> stuff that keeps getting inserted into LLVM.
>
> A couple of years ago, when I tried building the current LLVM version
> at the time on Scientific Linux 5.x, I couldn't even get parts of the
> LLVM ecosystem to build on SL 5.x because, on Linux, it required Linux
> features not in SL 5.x.

To answer your point elsewhere that you're hearing from other sources
DB/2 is written in C: if you can't build a compiler framework due to
differences in *versions* of Linux, imagine how dumb it is to suggest it
would be easy or even reasonable to port DB/2 written in C on a mainframe
(which it is not, to the best of my knowledge) to other completely
dissimilar platforms. I know you didn't suggest that, but you are arguing
with me based on info from unquoted sources. For all I know you are
listening to IBM marketing dorks.

I don't work with DB/2 so I don't know. But I listened in on a meeting
recently with a guy who does work with DB/2 every day and has for a few
decades. He works in a vendor software DB/2 utilities team. The question of
whether DB/2 is written in C came up. This guy told us, from the dumps he
has seen he has no evidence DB/2 has any significant amount of code in C. He
said he has not seen any evidence at all, but of course he realizes he may
have missed something and does not see everything. So he doesn't rule out
there might be some C, but as far as he has seen there is not any. This
discussion is entirely about DB/2 running on z/OS. I don't know and I don't
care about DB/2 for spintel, DB/2 for Linux on Z etc. I'm talking about the
real, core DB/2 that started on mainframes.

You guys need to understand z/Arch and z/OS are built entirely around
assembler. There is *no* direct system interface except in assembler and
PL/X. And it is only from around z/OS 1.10 (2.3 just came out and 1.13 was
the last of the 1. series) where there was a C compiler capable of running
with no runtime and being able to support inline assembler to call systems
services since C cannot do it directly. And it is only in the very recent
past IBM has started to try to create header files for all the systems
services (nothing has been released yet) and we only know it by
accident. But it's a huge job and far from complete. When it is done, then
it will be physically possible and feasible to write compilers in C. But no
reasonable person would suggest they would be willing to take a chance on
breaking their enterprise clients applications just so they can say their
compilers were written in C.