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

[Timothe Litt]

On 26-Jan-18 14:09, Clem Cole wrote:
>
>
> The other thing to add is there were at least two generations of the
> compilers within DEC that I knew about. 
Yes. 
> Tim you may have know of a third when I was off doing other things.  
> The last (current) is the 'Gem' compilers which was a rewrite to allow
> N font-ends, with Y back-ends.   I thought 'Compatible BLISS' was done
> to create BLISS-36/16/32 (PDP-10, 11, Vax) from the original CMU base;
> but was only targeting BLISS. 
Yes - "Common BLISS", not "compatible".  But Common BLISS also included
a lot of language changes.

> AFAIK, the original Compatible BLISS compiler was developed on the
> PDP-10 and eventually replaced the CMU code. 
Yes - VMS was initially developed under TOPS-20 with the cross tools. 
The developers were happy when it became self-hosted on the VAX, though
they lost a lot in moving from a mature environment.  But pride of self
covers a lot of pain.

The LCG products moved to Common BLISS - FORTRAN, RMS, APL perhaps the
most notable.  One or two might have been left behind because they were
so stable.  But none come immediately to mind.

> Prism forced the rewrite of the back-ends and with it the later
> generation and TLG wanted to clean up its act with a single
> back-end/optimizer that was common for all the languages [hence the
> Gem project - I'd have to ask Rich Grove for the details].  IIRC, Vax
> was used as the base for that system, although it moved to Alpha by
> the mid/late 1990s.
>
Sounds right.  The -16 and -36 versions stayed with the native backend
and didn't get much attention once GEM took off.  At least, I don't
recall GEM support for them.  However, there was minimal change to the
language, so Common BLISS remained common.  (I think the changes were
stuff like architecture-specific PSECT attributes, alignments &
builtins.)  GEM was very successful in consolidating optimization
efforts across all the languages.  It also made it feasible to add
object code generation for various runtime environments for multiple
languages.  Turned an n * m problem into essentially n + m.

Alpha pretty much repeated the VAX route (plus the stupid mistake of
splitting the VMS sources).  It cross-compiled from VAX to simulation,
then the internal early development alpha subset hardware, then alpha. 
But it was a lot easier, since we had real networks and
cross-architecture clusters; you could compile on a VAX, dismount the
disk, and boot on an Alpha ADU in about 30 seconds; later, compile on a
VAX and run user mode on Alpha without dismounting.  OSF/1 was another
story; I wasn't involved in that.

Because of GEM, compiler "generation" gets a bit fuzzy - updates give
BLISS new optimizations and targets (some radically different), but
(almost) all the work is in GEM, not the front end.  But GEM would race
along for a while, but not be incorporated into the released languages
until there was some forcing function.  That could be a long time for
BLISS, but not so long for FORTRAN and C.  So it depends on where you
draw the line - is GEM part of the compiler, or not?  No doubt the
compiler guys can point to examples where GEM changes affected the
language front ends, but from afar it seemed a pretty stable interface. 
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.  But
I suspect there was marketing (and qualification) pull toward hiding the
boundaries when packaging.  After all, some 3rd party might have written
a backend for a non-DEC architecture.

All three (CMU ,BLISS, GEM) back ends used considerable creativity in
interpreting the instruction sets, and as time went on gave hand-coded
assembler a run for its money.  They especially liked to do computations
with bizarre-looking address calculations.  (Not all of which ran fast
on all processors.)  In one case, a particularly "clever" encoding of a
test on a link-time constant broke RMS on an unreleased VAX CPU. 
Interestingly, this one instruction was the ONLY time this construct was
encountered in all of VMS (including the top dozen layered products), so
waiting for the hardware spin wasn't as bad as it might have been.

Every time I do handstands with C #if/#define I still wish for BLISS %if
and %macro.  (I once had to port a few 100K lines of my BLISS code to C
on a 68000, and even with automation, converting macros and keyword
initialized data structures to C was a painful exercise in devolution by
obfuscation...)


> Clem
>
> ᐧ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180126/c9ae2d6d/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/20180126/c9ae2d6d/attachment-0001.bin>