Re: [Simh] Bliss versus C

[Johnny Billquist]

On 2018-01-30 16:15, Clem Cole wrote:



On Tue, Jan 30, 2018 at 9:45 AM, Johnny Billquist > wrote:


  if they had been able to get a pdp-10 then Unix would not have
happened.


​That was Ken describing the Tenex development in the introduction to 
his Turning award: /"I suspect Daniel Bobrow would be here instead of me 
if he could not afford a PDP-10 and had to "settle" for a PDP-11."/


https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf 



Ah. Right. That was what my memory was trying to remember.

  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 and C

[Dave Wade]

> -Original Message-
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Phil
> Budne
> Sent: 30 January 2018 00:17
> To: simh@trailing-edge.com
> Subject: Re: [Simh] BLISS and C
> 
> > I also think that Dave was asking for a B compiler, and not a BCPL 
> > compiler...
> 

Yes

> Amongst the PDP-7 UNIX files was a B runtime, which someone on the team
> was able to decipher well enough to write a B compiler in a C
> subset:
> 
> https://github.com/DoctorWkt/pdp7-unix/blob/master/tools/b.c
> 
> And then make self-hosting, in:
> https://github.com/DoctorWkt/pdp7-unix/tree/master/src/other
> 
> ISTR, the compiler generates something like more threaded code, as
> opposed native instructions, but the output is fed to the assembler (along
> with runtime source) to make an executable.
> 

Sounds like an interesting project... 

> A paper I first saw VERY recently describes Thompson bringing up the B
> interpreter on the CPU of a Merganthaller phototypsetter (since the vendor
> supplied S/W was too limited for them to use).
> 
> Ah:
> https://www.cs.princeton.edu/~bwk/202/summer.scanned.pdf
> document p8 (pdf p9)
> 
> ... KLT resurected the B interpreter.  B is a good language for a
> 16-bit word-oriented minicomputer, and most of our subsequent 202
> programs have been written in B.
> ___

I will have a look at that


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

Dave


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

Re: [Simh] Bliss versus C

[Clem Cole]

On Tue, Jan 30, 2018 at 9:45 AM, Johnny Billquist  wrote:

>  if they had been able to get a pdp-10 then Unix would not have happened.
>

​That was Ken describing the Tenex development in the introduction to his
Turning award: *"I suspect Daniel Bobrow would be here instead of me if he
could not afford a PDP-10 and had to "settle" for a PDP-11."*

 https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf


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

Re: [Simh] Bliss versus C

[Johnny Billquist]

I think he said something similar about if they had been able to get a pdp-10 
then Unix would not have happened.

  Johnny 


dave porter  skrev: (30 januari 2018 05:12:10 CET)
>Clem Cole wrote:
>
>>Hmmm.. to be honest this sound nice but I suspect it is more like
>>legend/wishful thinking than something Dennis would have said.
>
>I'm pretty sure I read this in something actually written
>by Ritchie, though since I can't come up with the source,
>it's possible I'm suffering from uncorrectable memory errors.
>
>
>___
>Simh mailing list
>Simh@trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS and C

[Jordi Guillaumes Pons]

Jordi Guillaumes i Pons
j...@jordi.guillaumes.name
HECnet: BITXOW::JGUILLAUMES


> 
> I was also going to point out that neither {} nor [] exist in (System/360 era)
> EBCDIC, so could not have been used in PL/1.
> 
> PL/1 (or PL/I, to use the later naming convention) has both BEGIN/END and
> DO/END, with different effects.  I got a long lecture from an office mate once
> about a program which was using BEGIN/END where DO/END was preferable, because
> BEGIN blocks actually create a new context, with internal/external scope
> details, while DO blocks do not create a new context.

There are no curly braces on any PL/I version that I’m aware of. 

The “normal” way to build statement blocks is DO/END, with are just combined 
statements (so can be used in IF…ELSE… or WHILE blocks; PL/I has no ‘END IF nor 
‘END WHILE’ statements). BEGIN/END create a semantic context where you can 
define local variables or, more usefully, establish local condition handlers.

A way to do a controlled check for overflow is, for instance

…
BEGIN;
DECLARE IS_OVERFLOW BIT(1) INIT(‘0’B);
ON OVERFLOW IS_OVERFLOW = ‘1’B;
NUMBER = BIGNUMBER1 + BIGNUMBER2;
IF IS_OVERFLOW THEN CALL HANDLE_OVERFLOW();
END;
…

That “ON” condition is only valid inside the BEGIN/END block, so if an OFL 
condition occurs elsewhere (and you have used the correct compiler options) the 
program will crash (“ABEND”, in IBM idiom). That is actually what you really 
WANT to happen (better to get a call at 3am than to have to correct a corrupt 
file).




Jordi Guillaumes i Pons
j...@jordi.guillaumes.name
HECnet: BITXOW::JGUILLAUMES
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Bliss versus C

[dave porter]

Clem Cole wrote:


Hmmm.. to be honest this sound nice but I suspect it is more like
legend/wishful thinking than something Dennis would have said.


I'm pretty sure I read this in something actually written
by Ritchie, though since I can't come up with the source,
it's possible I'm suffering from uncorrectable memory errors.


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

Re: [Simh] BLISS and C

[Phil Budne]

> I also think that Dave was asking for a B compiler, and not a BCPL compiler...

Amongst the PDP-7 UNIX files was a B runtime, which someone on the
team was able to decipher well enough to write a B compiler in a C
subset:

https://github.com/DoctorWkt/pdp7-unix/blob/master/tools/b.c

And then make self-hosting, in:
https://github.com/DoctorWkt/pdp7-unix/tree/master/src/other

ISTR, the compiler generates something like more threaded code, as
opposed native instructions, but the output is fed to the assembler
(along with runtime source) to make an executable.

A paper I first saw VERY recently describes Thompson bringing up the B
interpreter on the CPU of a Merganthaller phototypsetter (since the
vendor supplied S/W was too limited for them to use).

Ah:
https://www.cs.princeton.edu/~bwk/202/summer.scanned.pdf
document p8 (pdf p9)

... KLT resurected the B interpreter.  B is a good language for a
16-bit word-oriented minicomputer, and most of our subsequent 202
programs have been written in B.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS and C

[Phil Budne]

Rich Alderson wrote:
> Ken had no tools for the PDP-7, which was part of a Graphics-1 setup (with a
> Type 340 display)

A nit, but I think the display controller was Bell designed, custom
hardware.  PDP-7 UNIX used it as a glass TTY (independent from the
console TTY).  I simulated JUST enough of it (character display,
keyboard and auto-pressing the clear screen key) in SIMH so that you
can have two users active!  I worked from BTL documents to implement
the simulation.

Since the world has changed so much since I did the original XY
display code that's now integrated into SIMH (tho I wrote it to be
simulator agnostic and stand-alone), I thought about making a Web UI
that lit the light that says "display list memory area full", and
forced the user to click on an HTML button to clear the screen!

It seemed like the majority of Graphics-1 systems built were PDP-9's
so it's possible the PDP-7 was a cast-off prototype.

Somewhere I've a description of the Graphics system being as large as
the PDP-7 itself. In addition, ISTR the disk system cost as much as
the CPU (I think the same type of disk was also used as a swap device
on KA10 timesharing systems), and fast enough to swap the high half
(4K) of memory in/out for each process painlessly.  ISTR that one or
both of the above recollections were from Doug McIlroy

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

Re: [Simh] BLISS and C

[Johnny Billquist]

On 2018-01-29 23:48, Timothe Litt wrote:

On 29-Jan-18 17:45, Dave Wade wrote:

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Bob
Eager
Sent: 29 January 2018 22:08
To: simh@trailing-edge.com
Subject: Re: [Simh] BLISS and C

On Mon, 29 Jan 2018 12:05:01 -0500
Clem Cole <cl...@ccc.com> wrote:


One can argue, why did Ken not just build something more like BCPL
instead of B?  I can not say, maybe the brevity of { } from PL/1 was
more attractive than the Algol BEGIN/END style?

BCPL was, in any case, using $( $) and (later) { }. It never used BEGIN/END.


The "B" compiler I used on the Honeywell L6000/L66 used { }.


And the major drawback of BCPL (which I love) was that it was word
oriented. Most machine architectures were not (OK, PDP-10...) One had to
use contortions, and a special % operator, to access bytes efficiently.


"B" is similar, characters were accessed by functions rather than a special 
operator, but you can, I think use a combination of shifts and logical operators
... those familiar with BCPL or C who have not encountered B may find the 
manual here interesting...

https://www.bell-labs.com/usr/dmr/www/bref.html

it would be nice to find a working compiler for a word based machine...


I seem to remember that there was a BCPL for TOPS-10 in the DECUS library.


I have a BCPL compiler for RSX, which also came from DECUS. Now, the 
PDP-11 is probably not a word based machine in the sense Dave meant.
However, I also think that Dave was asking for a B compiler, and not a 
BCPL 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 and C

[Timothe Litt]

On 29-Jan-18 17:45, Dave Wade wrote:
>> -Original Message-
>> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Bob
>> Eager
>> Sent: 29 January 2018 22:08
>> To: simh@trailing-edge.com
>> Subject: Re: [Simh] BLISS and C
>>
>> On Mon, 29 Jan 2018 12:05:01 -0500
>> Clem Cole <cl...@ccc.com> wrote:
>>
>>> One can argue, why did Ken not just build something more like BCPL
>>> instead of B?  I can not say, maybe the brevity of { } from PL/1 was
>>> more attractive than the Algol BEGIN/END style?
>> BCPL was, in any case, using $( $) and (later) { }. It never used BEGIN/END.
>>
> The "B" compiler I used on the Honeywell L6000/L66 used { }.
>
>> And the major drawback of BCPL (which I love) was that it was word
>> oriented. Most machine architectures were not (OK, PDP-10...) One had to
>> use contortions, and a special % operator, to access bytes efficiently.
>>
> "B" is similar, characters were accessed by functions rather than a special 
> operator, but you can, I think use a combination of shifts and logical 
> operators
> ... those familiar with BCPL or C who have not encountered B may find the 
> manual here interesting...
>
> https://www.bell-labs.com/usr/dmr/www/bref.html
>
> it would be nice to find a working compiler for a word based machine...

I seem to remember that there was a BCPL for TOPS-10 in the DECUS library.





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 and C

[Dave Wade]

> -Original Message-
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Bob
> Eager
> Sent: 29 January 2018 22:08
> To: simh@trailing-edge.com
> Subject: Re: [Simh] BLISS and C
> 
> On Mon, 29 Jan 2018 12:05:01 -0500
> Clem Cole <cl...@ccc.com> wrote:
> 
> > One can argue, why did Ken not just build something more like BCPL
> > instead of B?  I can not say, maybe the brevity of { } from PL/1 was
> > more attractive than the Algol BEGIN/END style?
> 
> BCPL was, in any case, using $( $) and (later) { }. It never used BEGIN/END.
> 

The "B" compiler I used on the Honeywell L6000/L66 used { }.

> And the major drawback of BCPL (which I love) was that it was word
> oriented. Most machine architectures were not (OK, PDP-10...) One had to
> use contortions, and a special % operator, to access bytes efficiently.
> 

"B" is similar, characters were accessed by functions rather than a special 
operator, but you can, I think use a combination of shifts and logical 
operators
... those familiar with BCPL or C who have not encountered B may find the 
manual here interesting...

https://www.bell-labs.com/usr/dmr/www/bref.html

it would be nice to find a working compiler for a word based machine...

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

Dave

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

Re: [Simh] BLISS and C

[Bob Eager]

On Mon, 29 Jan 2018 12:05:01 -0500
Clem Cole  wrote:

> One can argue, why did Ken not just build something more like BCPL
> instead of B?  I can not say, maybe the brevity of { } from PL/1 was
> more attractive than the Algol BEGIN/END style?

BCPL was, in any case, using $( $) and (later) { }. It never used
BEGIN/END.

And the major drawback of BCPL (which I love) was that it was word
oriented. Most machine architectures were not (OK, PDP-10...) One had
to use contortions, and a special % operator, to access bytes
efficiently.

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

Re: [Simh] BLISS and C

[Richard Cornwell]

> On Mon, 29 Jan 2018 16:35:42 -0500 (EST)
> Rich Alderson  wrote:
>
> > From: Clem Cole 
> > Date: Mon, 29 Jan 2018 14:21:36 -0500  
> 
> > My point was less on PL/1 and more to the point that Ken had access
> > to BCPL and did not have BLISS.   But he still decided to create
> > what would become B.  
> 
> Ken had no tools for the PDP-7, which was part of a Graphics-1 setup
> (with a Type 340 display), not even an assembler.  The first thing he
> wrote on the GECOS system (not yet shortened to GCOS, since it was a
> GE 635) was an assembler, which shared absolutely nothing in terms of
> syntax with the DEC assembler for the system.
> 
> Remember that BCPL originated on a PDP-7, and had an 18-bit word as
> its only data type.  Since Ken had only a cross assembler to start
> with, B was the simplest interim solution (a BCPL subset in an
> interpreter).

  BCPL originated on the IBM 7090 under CTSS. It only supported 36 bit
  word data types. I am not sure BCPL was ever ported to the PDP-7. 

Rich

-- 
==
Richard Cornwell
sky...@sky-visions.com
http://sky-visions.com
LinkedIn:   https://www.linkedin.com/in/richard-cornwell-991076107
==
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS and C

[Rich Alderson]

> From: Clem Cole 
> Date: Mon, 29 Jan 2018 14:21:36 -0500

> My point was less on PL/1 and more to the point that Ken had access to BCPL
> and did not have BLISS.   But he still decided to create what would become
> B.

Ken had no tools for the PDP-7, which was part of a Graphics-1 setup (with a
Type 340 display), not even an assembler.  The first thing he wrote on the
GECOS system (not yet shortened to GCOS, since it was a GE 635) was an
assembler, which shared absolutely nothing in terms of syntax with the DEC
assembler for the system.

Remember that BCPL originated on a PDP-7, and had an 18-bit word as its only
data type.  Since Ken had only a cross assembler to start with, B was the
simplest interim solution (a BCPL subset in an interpreter).

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

Re: [Simh] BLISS and C

[Rich Alderson]

> From: Paul Koning 
> Date: Mon, 29 Jan 2018 13:33:30 -0500

>> On Jan 29, 2018, at 12:05 PM, Clem Cole  wrote:

>>  ...  One can argue, why did Ken not just build something more like BCPL
>> instead of B?  I can not say, maybe the brevity of { } from PL/1 was more
>> attractive than the Algol BEGIN/END style?

> PL/I has begin/end as ALGOL does.  I don't know where { } came from, but it
> isn't from PL/I.  What perhaps did come from PL/I is ; as terminator rather
> than separator.

I was also going to point out that neither {} nor [] exist in (System/360 era)
EBCDIC, so could not have been used in PL/1.

PL/1 (or PL/I, to use the later naming convention) has both BEGIN/END and
DO/END, with different effects.  I got a long lecture from an office mate once
about a program which was using BEGIN/END where DO/END was preferable, because
BEGIN blocks actually create a new context, with internal/external scope
details, while DO blocks do not create a new context.

(The thing is, I was writing in Pascal, not PL/I, where begin/end works like
 PL/I's DO/END, but the rant was interesting enough that I let him run to
 competion before pointing that out to him.  Was that behavior new to Pascal,
 or inherited from Algol 60?)

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

Re: [Simh] BLISS and C

[Clem Cole]

On Mon, Jan 29, 2018 at 1:33 PM, Paul Koning  wrote:

>
> PL/I has begin/end as ALGOL does.  I don't know where { } came from, but
> it isn't from PL/I.  What perhaps did come from PL/I is ; as terminator
> rather than separator.


Fair enough, although I will say I had a PL/1 style/dialect compiler from
my IBM days that I thought I remember allowing it - which may have been
BCPL, PL/360 or maybe even PL/C -- too many beers ago.  I was never much of
a PL/1 programmer, and I could easily be mushing it all together.  Most of
my 360 hacking in those days was in assembler.

FYI:  Check out:  http://www.bobbemer.com/BRACES.HTM for an interesting
discussion of curly braces.

I do sort of remember the $( and $) digraphs as IIRC the one of the
keypunch (??19?? I think)  could not create them but the ??26?? could.
Thinking
about it... it may have been that the later was allowed for BEGIN/END in
the PL/x dialect and then later Ken switched from the BCPL digraph to curly
braces.

My point was less on PL/1 and more to the point that Ken had access to BCPL
and did not have BLISS.   But he still decided to create what would become
B.

Clem

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

Re: [Simh] BLISS and C

[Paul Koning]

> On Jan 29, 2018, at 12:05 PM, Clem Cole  wrote:
> 
> ...
> One can argue, why did Ken not just build something more like BCPL instead of 
> B?  I can not say, maybe the brevity of { } from PL/1 was more attractive 
> than the Algol BEGIN/END style? 

PL/I has begin/end as ALGOL does.  I don't know where { } came from, but it 
isn't from PL/I.  What perhaps did come from PL/I is ; as terminator rather 
than separator.

I was looking at ALGOL syntax again recently, and noticed something 
interesting: the ALGOL-60 procedure declaration syntax is nearly identical to 
the K style function declaration syntax in C.  That is, this style:

foo (a,b);
int a, b;
{ /* ... */ }

looks just like what ALGOL-60 uses.

paul


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

Re: [Simh] BLISS and C

[Clem Cole]

On Mon, Jan 29, 2018 at 8:20 AM, dave porter 
wrote:

> I recall reading something from Dennis Ritchie to the effect
> that if he'd been able to get hold of a BLISS compiler he
> wouldn't have bothered to invent C.  But DEC held on to
> its compilers tightly.


​Hmmm.. to be honest this sound nice but I suspect it is more like
legend/wishful thinking than something Dennis would have said.
Unfortunately we can not ask him, but I can report a little on how both
languages came into being (actually all three cause you need to include B
here also) as I know/knew the designers of both and was a witness to a
small portion of the stories.  You can then decide for yourself.

Two related things that I did not mention yesterday when I was describing
the differences between the languages are that BLISS has only one data type
(a 'word') and is 'typeless' in the sense of Pascal or other strongly typed
languages.   C was originally 'weakly typed' and only later added strong
typing (and why is important).  Also remember that at the time BLISS was
designed, Wulf specifically targeted the PDP-10(the PDP-11 did not yet exist
and the PDP-8 was explicitly a non-target).  I'm pretty sure if you read
Wulf's original paper, they were not trying to be
architecture independent.  Also it was designed to be an >>implementation<<
language for the PDP-10.  Another point is that Wulf and team had other
tools for the PDP-10 when they wrote it - including an OS.

B (C direct predecessor), like BCPL and BLISS, was untyped and worked with
words only.   In fact, Ken is on record as saying that he was originally
starting to develop a Fortran compiler for the PDP-7 to run on UNIX (both
of which had been written in PDP-7 assembler).   He ended up with a new
semi-interpreted language that was good enough to write utilities; i.e. B
was born and started a life of its own.  He was clearly influenced by BCPL
and had just been using PL/1 with Multics.   Clearly he was trying to
create an implementation language for the PDP-7.  But Ken was not using any
tools other than his own for the PDP-7 - in fact he was originally cross
assembling from a GECOS system.Once UNIX was 'up' on the PDP-7, it
was minimal compared to TOPS-10, that Wulf had used [check out:  pdp7-unix
is a project to resurrect Unix on the PDP-7
].

BTW: another salient point is that Ken, Dennis and team had previously
tried to purchase a PDP-10 for their lab, and had been rejected by their
management.   The whole reason Ken was working on the PDP-7, was that he
borrowed it from another group and he had access to it.   They were using
GCOS as their 'main systems' and the PDP-7 system was being developed as
an independent project.

So by the time of moving Unix to PDP-11, Dennis had switched from an
B interpreter to a B compiler; which then begat NB, ney C [See Clem Cole's
Quora answer What-language-was-the-first-C-compiler-written-in
].
  So the point is that Dennis was building tools to support their project
and C was just continuing the development of Ken's B.

One can argue, why did Ken not just build something more like BCPL instead
of B?  I can not say, maybe the brevity of { } from PL/1 was more
attractive than the Algol BEGIN/END style?   I don't know.   But I suspect
it was because he was originally targeting Fortran that he kept 'blocks' to
be minimal.   He ended up with something like BCPL in semantics and PL/1 in
syntax than Fortran.

Back to C:  With the PDP-11 Dennis added supports for different data types
- in particular bytes and byte addressing.   Originally, he left the C
language mostly typeless (everything defaulted to an int).  C stays that
way for a long time, through K   But as the language starts to get used
for other architectures, the ideas of being 'more strongly typed' starts to
come into play.   In fact, I think the two primary changes to ANSI C that
helped to cement C in the long run, were strong typing and function
prototypes (which used it).

As I think back on Wulf's intention to create a systems programming
language with good support for SW engineering, and I suspect the single
'word' and lack of typing actually would have hurt Bill's claimed intent
for BLISS (I've never asked him - I need too next time I see him).

All this comes back to my point.   Btw the time Dennis develops, C, B had
been in use and had been created incrementally from B.   If Ken had had
access to BLISS compiler, he would have needed it on GCOS, and CMU never
created same and then you are correct, sold the rights to their
implementations to DEC.  But the fact is, Ken and Dennis did have a BCPL
compiler on GCOS?  So why not just retarget it to the PDP-7?   Why did Ken
create B?

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

[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 <jdbr...@acm.org>
To  SIMH List <simh@trailing-edge.com>
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

[Simh] BLISS and C

[dave porter]

I recall reading something from Dennis Ritchie to the effect
that if he'd been able to get hold of a BLISS compiler he
wouldn't have bothered to invent C.  But DEC held on to
its compilers tightly.

-dave

The poet Wordsworth on systems programming:

“Bliss it was in that dawn to be alive
 But to be young was very heaven.”

___
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

[Howard Bussey]

SOAP was the assembler for the IBM 650.

—Howard

Sent from my iPhone

> On Jan 26, 2018, at 16:25, Larry Baker  wrote:
> 
> Was SOAP Knuth's assembler that optimized placement of the machine code on 
> the drum memory to minimize access latency for the next instruction?
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
> 
> 
> 
>> On 26 Jan 2018, at 12:35:20 PM, simh-requ...@trailing-edge.com wrote:
>> 
>> The only other optimizing assembler I can think of is SOAP, way back in the 
>> 1950s.
> 
> ___
> 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))

[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

[Larry Baker]

Was SOAP Knuth's assembler that optimized placement of the machine code on the 
drum memory to minimize access latency for the next instruction?

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



> On 26 Jan 2018, at 12:35:20 PM, simh-requ...@trailing-edge.com wrote:
> 
> The only other optimizing assembler I can think of is SOAP, way back in the 
> 1950s.



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