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

[Timothe Litt]

On 27-Jan-18 13:59, Clem Cole wrote:
>
>
> On Fri, Jan 26, 2018 at 4:28 PM, Timothe Litt <litt at ieee.org
> <mailto: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).​
>
I could be wrong - I followed GEM development off and on as a matter of
curiosity, but didn't get into the internals - however, I was under the
impression that GEM was built into the compilers from object libraries,
not linked as sharable images.  In any case, GEM was not exposed or
documented externally.  And I don't recall any language-independent
patch being issued for GEM - common issues resulted in a patch for each
language - however things were packaged.

What was regression tested internally was quite different from what was
released.  BLISS was regression tested daily, but rarely released (even
internally).  IIRC, there were a lot of GEM changes to support C
optimization and FORTRAN parallelization.  (And language changes.)  And
those languages were released fairly frequently to satisfy customers &
benchmarks.  But I tracked progress through the GEM and language
notesfiles, so I may have a skewed view. 

>     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.​
>
That's reality - in a different space-time continuum. 

In the original (DEC-centric) STC, those decisions were made from the
point of view of DEC being the center of the universe, and not wanting
DEC's IP to leak onto other architectures.  Either BLISS itself, or
products coded in it.  The same view that didn't license XMI; greatly
restricted BI licenses; and was too little too late with expanding the
Alpha ecosystem.  (Contrast with PDP-11, where every Unibus system came
with a license grant to build a peripheral...)

Similarly, the DECision on BLISS pricing made sense if you looked at
what DEC invested (I think Brender's paper said a team of 16 people
(pre-GEM) and a couple of $M) and what having it was worth to DEC
engineering.  It didn't recognize how customers would value BLISS, or
what adoption by a wider crowd would be worth to DEC in the long run.

In the current STC, well, I saw a lot of NIH in Intel.  I suspect that
what you report amounts to "Why tear up a "perfectly good compiler" to
incorporate technology from a "failed company", when the result isn't
directly marketable?" 

Of course, both share the same defect - a shortsighted world view. 
Which is easy to see a few decades later.

> 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).
>
I wouldn't know; it's been a long time since I dabbled in compilers. 
Mostly pre-GEM timeframe.  But I'm not surprised.  GEM was built &
evolved by engineers from the ground up to support multiple languages at
equivalent optimization levels.  Most other ILs start as an internal
tool for one language; when extended, the rule is to make minimal
changes to support each additional language.  This keeps short term
costs down (regressions against and changes to the first language - and
tools), but you lose expressiveness (and optimizations).  And it ends up
being warty and hackish.  But the incremental cost of the next wart/hack
is always less than the cost of rototilling.  There's probably a formal
proof to derive NIH from this observation :-)

Old New England axiom: Never time to do it right; always time to do it over.

Knuth's version: When writing software, do it once to understand the
problem.  Then plan on throwing out what you built, and write it
correctly from scratch.

Neither is put to use in the technology world...at least not often.

> 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).
>
No clue.  I had little contact with the Intel (including ex-DEC)
compiler folks when @INTC; I was trying to overcome NIH in other arenas.
> 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).
>
>
>  
> ᐧ
DEC had a long history (going back to the 36-bit world) of managing &
qualifying complex software dependencies.  And the discipline to pass
the lessons along.  .EXEs from VMS 1.0 run today - sharable libraries
included (no private versions necessary.)

M$ did not have the history.  The resulting "DLL HELL" and "installation
nightmares" are well known, and not resolved to this day.  (And don't
get me started on the challenges of uninstalling...)

Linux is somewhat in the middle - the current container craze tries to
prevent interactions by - having private copies of sharable libraries. 
So they're sharable, but not shared (outside each container).  And I'm
tracking a project where some components require Python 2 and others
require Python 3 - in the same container.  So even the languages aren't
upward compatible.  But RPMs and DEBs seem to have learned from setld
(and VMSINSTAL/PCSI).  Unix sharable library versioning is capable of
being sane - but to the extent that there are standards, compliance is
spotty.  So people give up and static link...

INTC studied software development with M$, adopting its practices.  (Not
necessarily its best ones.)

Q.E.D.

Was it admiral Nelson who observed that those who don't learn from
history are doomed to repeat it?

SimH does a great job of preserving the ability to use the artifacts. 
However, preserving the knowledge that created them is a different
problem, as yet unsolved.

Grump.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180128/2c4e47dc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180128/2c4e47dc/attachment-0001.bin>