[Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Clem Cole]

On Fri, Jan 26, 2018 at 4:28 PM, Timothe Litt <litt at ieee.org> wrote:

> I don't think there was any technical reason that the front end, IL
> optimizer, code generators and object generators couldn't have been
> separate sharable libraries - and separately patchable/upgradable.
>
​I was under the impression that the shared libraries were just that and
DEC was pretty tight about if the fix was in the backend, all front end
languages had to be tested (more in a minute).​

But I suspect there was marketing (and qualification) pull toward hiding
> the boundaries when packaging.
>
​Maybe in marketing (undeserved) but qual was in important.​



> After all, some 3rd party might have written a backend for a non-DEC
> architecture.
>
​Unlikely -  the sad truth is that when both the K&A folks and Intel
compiler groups had access to the all the code and the doc (and the people
that designed it), guess what code base was used..  not GEM.​

Grove used to say the DEC (Gem) compiler DNA was being ground up and
reinserted into the Intel compiler.   To this day the Intel IL is not as
rich as the Gem IL and it drives a lot of the old DEC team crazy.   From
what I gather, the closest IL has been what LLVM did, but I gather than is
still pretty weak for some language structures such as FORTRAN (and I
believe PL/1).

Speaking for myself and my own personal experiences in using the both the
DEC and Intel tool chains over the years, the common back-end/runtime is acute
and you see how well Gem did vs an issue Intel has had.   I've spent years
trying to get the testing and installer folks to 'get it'  when it comes to
dependancies (I was once given an Intel div level award for 'fixing' this
issue - although 5 years later I discovered much of the work we had done
had been lost and I had a deal into a new group numbskulls -- sigh - I do
think it is current correct - if you believe/know otherwise sent me email
offline).

Intel Fortran (like DEC Fortran) is dependent on the actually
source language specific runtime (because it's written in C or BLISS)
and both runtimes are dependent on a bunch of common runtime code, not just
language specific stuff.   If you make a change to the last or middle ones:
you have to ensure that you test what is dependent upon; and and when you
install don't create (and release) private versions.  i.e. install common
runtimes, then Fortran specific, then the Fortran compiler etc...   I'm
always amazed that such a simple idea is lost on some of the installation
folks (as much as a I used to b*tch at the DEC setld installer team, they
did tend to get this right).



ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180127/b9ee6e9a/attachment.html>