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

[Phil Mendelsohn]

Subject 	Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: 
PDP11

  on Simh for public access))
FromJ. David Bryan 
To  SIMH List 
DateSun 15:24
On Sunday, January 28, 2018 at 15:42, Timothe Litt wrote:

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


George Santayana ("Those who cannot remember the past are condemned to
repeat it").


As this is one of those epigrams that has probably had multiple 
independent authors over millenia, I prefer:


"He who forgets the pasta is doomed to reheat it."


Cheers,
Phil M

P.S.:  the subject of this thread is growing enough parenthesis to start 
being confused with Lisp.


--
"Behind the times but ahead of the game"
--Becky M
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[J. David Bryan]

On Sunday, January 28, 2018 at 15:42, Timothe Litt wrote:

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

George Santayana ("Those who cannot remember the past are condemned to 
repeat it").

  -- Dave

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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  > 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 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 

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

[Clem Cole]

On Sat, Jan 27, 2018 at 1:25 PM, Tom Morris  wrote:

> On Fri, Jan 26, 2018 at 4:28 PM, Timothe Litt  wrote:
>
>>  the front end, IL optimizer, code generators and object generators
>>
>
> IL optimizer == GEM "middle end" or was that a local colloquialism?
>
​I've never heard that term.

IL optimizer was just that.   There are also machine specific optimizers
run after code generation.

In the case of the ​Intel, there are parallelism passes now done also,
first on the IL and then later on the during CG.
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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  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 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).



ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Tom Morris]

On Fri, Jan 26, 2018 at 4:28 PM, Timothe Litt  wrote:

>  the front end, IL optimizer, code generators and object generators
>

IL optimizer == GEM "middle end" or was that a local colloquialism?

Tom
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2018-01-27 17:21, John Forecast wrote:



On Jan 26, 2018, at 2:17 PM, Johnny Billquist  wrote:

On 2018-01-26 18:48, Timothe Litt wrote:

BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS - evolved (and 
greatly extended) from BLISS-11, but not (really) source-compatible for non-trivial 
programs.  "common" means that (with carefully defined exceptions that can be 
conditionally compiled), the same language is accepted by all, and it's possible to write 
portable programs.  Including common BLISS itself.  RMS-10/20 is another non-trivial 
example - same sources as VAX/RMS.  There are a number of targets and host environment 
combinations that are supported.
BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object code.  I used 
both.  I didn't encounter an Alpha-hosted version - but it should have compiled 
& run there, so it probably existed.  Or was VESTed.


I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've never seen or 
heard anything about BLISS-16 running on Alpha or beyond. I guess it could be 
possible to do, but I sortof doubt anyone did. If anyone have the bits, I would 
be very interested in hearing about it, as I would like to recompile some bits 
and pieces. (Any BLISS-16 compiler would be a good start.)


Most software written in BLISS-10 & -11 was converted to common  BLISS.
There was an attempt at self-hosting BLISS-16, but it failed - technically, it 
ran, but there really wasn't enough address space to make it usable.  
Cross-compiling wasn't popular (networks were crude), so BLISS-16 was not as 
widely adopted.


Well, parts of the RSX kernel is written in BLISS-16, and all of RMS-11. Also 
some parts of DECnet-11M-PLUS.
That much I know. I don't know what else might been written in BLISS-16.


Do you know which parts ended up in Bliss? I was project lead for the 
first version of DECnet-11M-Plus which was written entirely in Macro-11 (Well 
there may have been Fortran/Basic etc in the run-time libraries).


PHONE is written in BLISS. The rest of BLISS I can find is for 
PRO/DECnet, where it appears the equivalent of NCP was instead written 
in BLISS, along with NICE (they're called NMT and NSO). Both subsystems 
last worked in in 1985.


The only Fortran or Basic I can find are demo programs on how to use the 
NETFOR library.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[John Forecast]

> On Jan 26, 2018, at 2:17 PM, Johnny Billquist  wrote:
> 
> On 2018-01-26 18:48, Timothe Litt wrote:
>> BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS - 
>> evolved (and greatly extended) from BLISS-11, but not (really) 
>> source-compatible for non-trivial programs.  "common" means that (with 
>> carefully defined exceptions that can be conditionally compiled), the same 
>> language is accepted by all, and it's possible to write portable programs.  
>> Including common BLISS itself.  RMS-10/20 is another non-trivial example - 
>> same sources as VAX/RMS.  There are a number of targets and host environment 
>> combinations that are supported.
>> BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object code.  I 
>> used both.  I didn't encounter an Alpha-hosted version - but it should have 
>> compiled & run there, so it probably existed.  Or was VESTed.
> 
> I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've never seen 
> or heard anything about BLISS-16 running on Alpha or beyond. I guess it could 
> be possible to do, but I sortof doubt anyone did. If anyone have the bits, I 
> would be very interested in hearing about it, as I would like to recompile 
> some bits and pieces. (Any BLISS-16 compiler would be a good start.)
> 
>> Most software written in BLISS-10 & -11 was converted to common  BLISS.
>> There was an attempt at self-hosting BLISS-16, but it failed - technically, 
>> it ran, but there really wasn't enough address space to make it usable.  
>> Cross-compiling wasn't popular (networks were crude), so BLISS-16 was not as 
>> widely adopted.
> 
> Well, parts of the RSX kernel is written in BLISS-16, and all of RMS-11. Also 
> some parts of DECnet-11M-PLUS.
> That much I know. I don't know what else might been written in BLISS-16.
> 
Do you know which parts ended up in Bliss? I was project lead for the 
first version of DECnet-11M-Plus which was written entirely in Macro-11 (Well 
there may have been Fortran/Basic etc in the run-time libraries).

  John.

>   Johnny
> 
> -- 
> Johnny Billquist  || "I'm on a bus
>  ||  on a psychedelic trip
> email: b...@softjar.se ||  Reading murder books
> pdp is alive! ||  tryin' to stay hip" - B. Idol
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Phil Budne]

Bob Eager wrote:
> How many people have read this book? (I have it)
I own it, but have never studied it.

> It's about the design of an early BLISS compiler.
BLISS-11

>  http://amzn.eu/irCsXhi 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Bob Eager]

On Fri, 26 Jan 2018 22:55:48 +0100
Johnny Billquist  wrote:

> Heh. I've had similar experiences with BLISS-16. I've learned a trick
> or two looking at the code generated, and it can do some rather neat 
> tricks. Definitely impressive code generated. Not seen that level
> from any other PDP-11 compiler.

How many people have read this book? (I have it)

It's about the design of an early BLISS compiler.

 http://amzn.eu/irCsXhi 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Paul Koning]

> On Jan 26, 2018, at 4:59 PM, Johnny Billquist  wrote:
> 
> On 2018-01-26 22:49, Timothe Litt wrote:
>> ...
>> There also was the argument that you really couldn't (well, shouldn't) write 
>> pure assembler for Alpha because the best scheduling depends on the 
>> implementation (how many execution units, of what sorts & latencies; 
>> predictions, speculations, prefetch; etc.)
>> PALcode has some unique constraints that do require manual scheduling, as do 
>> some diagnostics.  But it does turn out to be true that Alpha assembler is 
>> best understood (and used) as a low-level compiled language, not an 
>> assembler.
> 
> Are we talking about MACRO-32 or Alpha assembler now? They are two different 
> things. PALcode, I would assume, you actually wanted an Alpha assembler for. 
> Porting lots of VMS stuff needed the MACRO-32 compiler. Exactly what Paul was 
> doing, and in which language, was a bit unclear to me. I was assuming he was 
> talking about Alpha assembler, and not MACRO-32, but I could be wrong.

Yes, native Alpha assembler.  Obviously that is machine dependent if you're 
optimizing very seriously.  The purpose of the exercise was to see if you could 
do TCP checksum in software while moving network data between the Ethernet NIC 
buffers and other places, at the same speed as a simple memcpy.  The answer is 
yes: if you're at all careful, you can do the necessary arithmetic at times 
when the CPU would otherwise have been waiting for memory accesses.  The same 
tends to be true for simple data processing actions on buffers in many other 
machines, for that matter.  Many years later I did RAID-5 and RAID-6 (XOR 
based) in software in a similar way, the cost was simply that of passing over 
the memory buffers and the arithmetic involved had an effective cost of zero.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2018-01-26 22:49, Timothe Litt wrote:


On 26-Jan-18 14:45, Paul Koning wrote:

ent.​  I also do not know what they are doing with the front-ends.
One of the more curious front ends of GEM is the Alpha assembler.  I found out about that 
when doing some Alpha hand-optimizing early on (a handcoded "memcpy with TCP 
checksum calculation while doing it" if I remember right).  It turned out I could 
write drafts of that code and give it to the assembler with a /OPTIMIZE switch to let the 
back end take what I wrote and do stuff to it.  It wasn't always right, but it was a neat 
source of ideas.
Well, not exactly an optimizing assembler.  It sort of looks like one.  
But the real story is that the Alpha port needed to deal with the large 
amount of MACRO-32 in VMS.  The solution was to treat MACRO-32 as a 
compiled language, and generate a GEM front end for it.  There was a lot 
of optimization that was absolutely required if you wanted tolerable 
code - e.g. most VAX instructions set condition codes, but they are 
rarely tested - and when tested, usually only a subset of those set are 
involved in the test.  So tracking condition code generation and 
consumption is a big win.  And when you look at address generation, 
there's a lot of opportunity for CSE elimination, and other 
optimizations.  Then you wanted to schedule the generated code for Alpha 
- which is a lot of re-ordering, packing & the like.


Then it was extended for the Alpha instruction set (psect attributes, 
instructions, etc).


At this point, you have a compiler for low level language, that happens 
to look like assembler.  Externally, perhaps a distinction without a 
difference; internally, quite different.  And if you're unlucky enough 
to have to do instruction level debug, very different from traditional 
assembler.


There also was the argument that you really couldn't (well, shouldn't) 
write pure assembler for Alpha because the best scheduling depends on 
the implementation (how many execution units, of what sorts & latencies; 
predictions, speculations, prefetch; etc.)


PALcode has some unique constraints that do require manual scheduling, 
as do some diagnostics.  But it does turn out to be true that Alpha 
assembler is best understood (and used) as a low-level compiled 
language, not an assembler.


Are we talking about MACRO-32 or Alpha assembler now? They are two 
different things. PALcode, I would assume, you actually wanted an Alpha 
assembler for. Porting lots of VMS stuff needed the MACRO-32 compiler. 
Exactly what Paul was doing, and in which language, was a bit unclear to 
me. I was assuming he was talking about Alpha assembler, and not 
MACRO-32, but I could be wrong.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2018-01-26 22:49, Hunter Goatley wrote:

On 1/26/2018 3:28 PM, Timothe Litt wrote:

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.


I believe that's correct.


So, no GEM for BLISS-16, and most likely no chance of it being ported to 
Alpha then. Thanks for confirming that.


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.


I vaguely remember hearing about that.

BLISS-32 on VAX generated some amazing optimizations. Before I got into 
BLISS, I programmed almost exclusively in MACRO-32, and it was fun to 
compare code I wrote to the assembly code generated by the BLISS 
compiler. Several times, I encountered generated code that was a lot 
more efficient than the code I wrote, which I thought was very 
efficient. I learned a few MACRO tricks looking at the code generated. 
It was less fun trying to understand the GEM output for Alpha. ;-)


Heh. I've had similar experiences with BLISS-16. I've learned a trick or 
two looking at the code generated, and it can do some rather neat 
tricks. Definitely impressive code generated. Not seen that level from 
any other PDP-11 compiler.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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:45, Paul Koning wrote:
> ent.​  I also do not know what they are doing with the front-ends.  
> One of the more curious front ends of GEM is the Alpha assembler.  I found 
> out about that when doing some Alpha hand-optimizing early on (a handcoded 
> "memcpy with TCP checksum calculation while doing it" if I remember right).  
> It turned out I could write drafts of that code and give it to the assembler 
> with a /OPTIMIZE switch to let the back end take what I wrote and do stuff to 
> it.  It wasn't always right, but it was a neat source of ideas.
Well, not exactly an optimizing assembler.  It sort of looks like one. 
But the real story is that the Alpha port needed to deal with the large
amount of MACRO-32 in VMS.  The solution was to treat MACRO-32 as a
compiled language, and generate a GEM front end for it.  There was a lot
of optimization that was absolutely required if you wanted tolerable
code - e.g. most VAX instructions set condition codes, but they are
rarely tested - and when tested, usually only a subset of those set are
involved in the test.  So tracking condition code generation and
consumption is a big win.  And when you look at address generation,
there's a lot of opportunity for CSE elimination, and other
optimizations.  Then you wanted to schedule the generated code for Alpha
- which is a lot of re-ordering, packing & the like.

Then it was extended for the Alpha instruction set (psect attributes,
instructions, etc).

At this point, you have a compiler for low level language, that happens
to look like assembler.  Externally, perhaps a distinction without a
difference; internally, quite different.  And if you're unlucky enough
to have to do instruction level debug, very different from traditional
assembler.

There also was the argument that you really couldn't (well, shouldn't)
write pure assembler for Alpha because the best scheduling depends on
the implementation (how many execution units, of what sorts & latencies;
predictions, speculations, prefetch; etc.)

PALcode has some unique constraints that do require manual scheduling,
as do some diagnostics.  But it does turn out to be true that Alpha
assembler is best understood (and used) as a low-level compiled
language, not an assembler.

> The only other optimizing assembler I can think of is SOAP, way back in the 
> 1950s.
>
>   paul
>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Hunter Goatley]

On 1/26/2018 3:28 PM, Timothe Litt wrote:

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.


I believe that's correct.

Alpha pretty much repeated the VAX route (plus the stupid mistake of 
splitting the VMS sources).  It cross-compiled from VAX to simulation,


I was porting a lot of freeware from VAX to Alpha when all that was 
available were the cross-compilers. The BLISS cross-compiler was great, 
but the early C cross-compilers were more problematic.


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.


I vaguely remember hearing about that.

BLISS-32 on VAX generated some amazing optimizations. Before I got into 
BLISS, I programmed almost exclusively in MACRO-32, and it was fun to 
compare code I wrote to the assembly code generated by the BLISS 
compiler. Several times, I encountered generated code that was a lot 
more efficient than the code I wrote, which I thought was very 
efficient. I learned a few MACRO tricks looking at the code generated. 
It was less fun trying to understand the GEM output for Alpha. ;-)


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


Yes, the BLISS macros and lexicals are awesome, and it also kills me 
that C never had them.


Hunter

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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
>
> ᐧ



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2018-01-26 20:38, Clem Cole wrote:



On Fri, Jan 26, 2018 at 2:17 PM, Johnny Billquist > wrote:



I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've
never seen or heard anything about BLISS-16 running on Alpha or beyond. 


​Gem did exactly that conceptually.​


Wasn't/isn't GEM the compiler core used for most languages later on? I 
didn't think BLISS itself was using GEM, but I don't know at all. 
However, I believe/assume/think I heard that GEM itself is written in BLISS.



I guess it could be possible to do, but I sortof doubt anyone did.

​It's a testing problem.   DEC was not only doing emergency fixes ​for 
the PDP-11 by the time of Alpha, so I agree.   I don't think TLG did 
anything with the EOL systems by then, they had their hands full with 
Vax, Alpha and 386; plus all the front ends.


When the Alpha came out, the PDP-11 was not dead. But I would not expect 
that much work was done anymore. They had tools and products, which they 
continued to use and improve. But moving to a new platform for any of it 
would have been very doubtful.



If anyone have the bits, I would be very interested in hearing about
it, as I would like to recompile some bits and pieces. (Any BLISS-16
compiler would be a good start.)

​VMSinc had the Gem compiler as part of their license.   As I say, they 
have Neil hacking on it again.   But I believe that he is only worried 
about Itanium and INTEL*64 at the moment.​  I also do not know what they 
are doing with the front-ends.   Clearly, they are working with the 
BLISS front-end, but I have not idea what HP has them doing for the 
other languages.  I would expect to see C/C++/Fortran brought forward at 
least through the dialect that DEC/Compaq/HP had at EOL, so customer 
code will recompile, since I know of OVMS code in those three languages.


Yes, BLISS is being worked on, as is GEM. I saw some comment by on the 
progress and issues around this from some VSI person not long ago.

But all that is far removed from anything PDP-11 related.

  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Paul Koning]

> On Jan 26, 2018, at 2:38 PM, Clem Cole  wrote:
> 
> ...
> ​VMSinc had the Gem compiler as part of their license.   As I say, they have 
> Neil hacking on it again.   But I believe that he is only worried about 
> Itanium and INTEL*64 at the moment.​  I also do not know what they are doing 
> with the front-ends.  

One of the more curious front ends of GEM is the Alpha assembler.  I found out 
about that when doing some Alpha hand-optimizing early on (a handcoded "memcpy 
with TCP checksum calculation while doing it" if I remember right).  It turned 
out I could write drafts of that code and give it to the assembler with a 
/OPTIMIZE switch to let the back end take what I wrote and do stuff to it.  It 
wasn't always right, but it was a neat source of ideas.

The only other optimizing assembler I can think of is SOAP, way back in the 
1950s.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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 2:17 PM, Johnny Billquist  wrote:
>
>
> I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've never
> seen or heard anything about BLISS-16 running on Alpha or beyond.

​Gem did exactly that conceptually.​



> I guess it could be possible to do, but I sortof doubt anyone did.

​It's a testing problem.   DEC was not only doing emergency fixes ​for the
PDP-11 by the time of Alpha, so I agree.   I don't think TLG did anything
with the EOL systems by then, they had their hands full with Vax, Alpha and
386; plus all the front ends.




> If anyone have the bits, I would be very interested in hearing about it,
> as I would like to recompile some bits and pieces. (Any BLISS-16 compiler
> would be a good start.)

​VMSinc had the Gem compiler as part of their license.   As I say, they
have Neil hacking on it again.   But I believe that he is only worried
about Itanium and INTEL*64 at the moment.​  I also do not know what they
are doing with the front-ends.   Clearly, they are working with the BLISS
front-end, but I have not idea what HP has them doing for the other
languages.  I would expect to see C/C++/Fortran brought forward at least
through the dialect that DEC/Compaq/HP had at EOL, so customer code will
recompile, since I know of OVMS code in those three languages.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2018-01-26 18:48, Timothe Litt wrote:
BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS - 
evolved (and greatly extended) from BLISS-11, but not (really) 
source-compatible for non-trivial programs.  "common" means that (with 
carefully defined exceptions that can be conditionally compiled), the 
same language is accepted by all, and it's possible to write portable 
programs.  Including common BLISS itself.  RMS-10/20 is another 
non-trivial example - same sources as VAX/RMS.  There are a number of 
targets and host environment combinations that are supported.


BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object 
code.  I used both.  I didn't encounter an Alpha-hosted version - but it 
should have compiled & run there, so it probably existed.  Or was VESTed.


I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've never 
seen or heard anything about BLISS-16 running on Alpha or beyond. I 
guess it could be possible to do, but I sortof doubt anyone did. If 
anyone have the bits, I would be very interested in hearing about it, as 
I would like to recompile some bits and pieces. (Any BLISS-16 compiler 
would be a good start.)



Most software written in BLISS-10 & -11 was converted to common  BLISS.

There was an attempt at self-hosting BLISS-16, but it failed - 
technically, it ran, but there really wasn't enough address space to 
make it usable.  Cross-compiling wasn't popular (networks were crude), 
so BLISS-16 was not as widely adopted.


Well, parts of the RSX kernel is written in BLISS-16, and all of RMS-11. 
Also some parts of DECnet-11M-PLUS.

That much I know. I don't know what else might been written in BLISS-16.

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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 12:48 PM, Timothe Litt  wrote:

> I wrote a fair bit of BLISS at various stages of its evolution.  My
> recollection is:
>
> BLISS-10 & BLISS-11 came from Wulf & Co at CMU.  BLISS-10 is self-hosted
>
​Right - Wulf, Steve Hobbs et al,  FWIW: I just had lunch with Steve a few
minutes ago.​

> .
>
> BLISS-11 is an evolution of BLISS-10.  There was a PDP10-hosted version of
> BLISS-11.  I don't think it was ported to VAX.
>
> BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS -
> evolved (and greatly extended) from BLISS-11, but not (really)
> source-compatible for non-trivial programs.  "common" means that (with
> carefully defined exceptions that can be conditionally compiled), the same
> language is accepted by all, and it's possible to write portable programs.
> Including common BLISS itself.  RMS-10/20 is another non-trivial example -
> same sources as VAX/RMS.  There are a number of targets and host
> environment combinations that are supported.
>
> BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object code.
> I used both.  I didn't encounter an Alpha-hosted version - but it should
> have compiled & run there, so it probably existed.  Or was VESTed.
>
> Most software written in BLISS-10 & -11 was converted to common  BLISS.
>
> There was an attempt at self-hosting BLISS-16, but it failed -
> technically, it ran, but there really wasn't enough address space to make
> it usable.  Cross-compiling wasn't popular (networks were crude), so
> BLISS-16 was not as widely adopted.
>

​This follows my recollection/understanding with the minor tweak of
addition being BLISS-INTEL64 (not to be confused with IA64), which is what
the VMS, Inc for using now for the new OVMS port to Intel*64 systems.   I
believe that is currently running on an Alpha and cross-compiling, but Neil
Faiman (one of the authors) was not at the usual 'compiler group Friday
lunch' today to ask.  Last I knew it was not 100% self hosting, although I
think Neil has also said he had the development running on his Mac.   So he
may be cross compiling from a Mac not OVMS/Alpha - which would all testing
on his laptop.   (I've sent him email to make sure and if I'm miss-informed
I'll update).

The other thing to add is there were at least two generations of the
compilers within DEC that I knew about.  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.   AFAIK, the
original Compatible BLISS compiler was developed on the PDP-10 and
eventually replaced the CMU code.  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.

Clem

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Timothe Litt]

On 26-Jan-18 11:37, Paul Koning wrote:
>
>> On Jan 25, 2018, at 8:15 PM, Clem Cole  wrote:
>>
>> ...
>> RSTS Basic is a late entry, the language support for it, originally came 
>> from the compiler group which again was originally PDP-10 based (also 
>> remember the PDP-11 BLISS compiler needed a 10 to run it).
> Are you talking about BASIC-PLUS-2?  RSTS BASIC-PLUS dates from 1970, and was 
> written under contract for DEC by Evans, Griffiths & Hart ("EGH").  It is 
> essentially a P-code compiler, to use terminology that didn't appear until 
> later; it doesn't generate any machine code.  And as far as I know, it is not 
> based on any BASIC implementation for any other system.
>
> As for BLISS, there's BLISS-16 and BLISS-11.  One came from Carnegie-Mellon; 
> the other was built at DEC.  Both are cross-compilers, but I don't remember 
> which platform.  PDP-10 for both?  10 for one and VAX for the other? 

I wrote a fair bit of BLISS at various stages of its evolution.  My
recollection is:

BLISS-10 & BLISS-11 came from Wulf & Co at CMU.  BLISS-10 is self-hosted.

BLISS-11 is an evolution of BLISS-10.  There was a PDP10-hosted version
of BLISS-11.  I don't think it was ported to VAX.

BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS -
evolved (and greatly extended) from BLISS-11, but not (really)
source-compatible for non-trivial programs.  "common" means that (with
carefully defined exceptions that can be conditionally compiled), the
same language is accepted by all, and it's possible to write portable
programs.  Including common BLISS itself.  RMS-10/20 is another
non-trivial example - same sources as VAX/RMS.  There are a number of
targets and host environment combinations that are supported.

BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object
code.  I used both.  I didn't encounter an Alpha-hosted version - but it
should have compiled & run there, so it probably existed.  Or was VESTed. 

Most software written in BLISS-10 & -11 was converted to common  BLISS.

There was an attempt at self-hosting BLISS-16, but it failed -
technically, it ran, but there really wasn't enough address space to
make it usable.  Cross-compiling wasn't popular (networks were crude),
so BLISS-16 was not as widely adopted.

For a more complete history, see
https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf



>   paul
>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh