[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.”

[Clem Cole]

Post by 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.

​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
<https://github.com/DoctorWkt/pdp7-unix>].

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
<https://www.quora.com/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&R. 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


ᐧ

[Paul Koning]

...
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&R style function declaration syntax in C. That is, this style:

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

looks just like what ALGOL-60 uses.

paul

[Clem Cole]

Post by Paul Koning
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

ᐧ

[Richard Cornwell]

On Mon, 29 Jan 2018 16:35:42 -0500 (EST)

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

[Phil Budne]

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

[Jordi Guillaumes Pons]

Jordi Guillaumes i Pons
***@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
***@jordi.guillaumes.name
HECnet: BITXOW::JGUILLAUMES

[Bob Eager]

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

Post by Clem Cole
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.

[Dave Wade]

-----Original Message-----
Eager
Sent: 29 January 2018 22:08
Subject: Re: [Simh] BLISS and C
On Mon, 29 Jan 2018 12:05:01 -0500

Post by Clem Cole
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
http://mailman.trailing-edge.com/mailman/listinfo/simh

Dave

[Timothe Litt]

Post by Dave Wade

-----Original Message-----
Eager
Sent: 29 January 2018 22:08
Subject: Re: [Simh] BLISS and C
On Mon, 29 Jan 2018 12:05:01 -0500

Post by Clem Cole
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.

[Bob Eager]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, 29 Jan 2018 17:48:22 -0500

Post by Timothe Litt

Post by Dave Wade

-----Original Message-----
Eager
Sent: 29 January 2018 22:08
Subject: Re: [Simh] BLISS and C
On Mon, 29 Jan 2018 12:05:01 -0500

Post by Clem Cole
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 one here - the Pete Gardner compiler. I did my MSc dissertation
on a portable version, and indeed found one or two bugs in the TOPS-10
one!

[Timothe Litt]

Post by Bob Eager
On Mon, 29 Jan 2018 17:48:22 -0500

[snip]

Post by Bob Eager

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

I have one here - the Pete Gardner compiler. I did my MSc dissertation
on a portable version, and indeed found one or two bugs in the TOPS-10
one!

Please get it on Bitsavers, unless it's already there or there's an
intractable IP restriction.  (Contact Al Kossow)

[Bob Eager]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, 29 Jan 2018 18:24:06 -0500

Post by Timothe Litt

Post by Bob Eager
On Mon, 29 Jan 2018 17:48:22 -0500

[snip]

Post by Bob Eager

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

I have one here - the Pete Gardner compiler. I did my MSc
dissertation on a portable version, and indeed found one or two
bugs in the TOPS-10 one!

Please get it on Bitsavers, unless it's already there or there's an
intractable IP restriction.  (Contact Al Kossow)

I'll need to check with the person I got it from, but yes...

[Lars Brinkhoff]

Post by Timothe Litt

Post by Bob Eager
On Mon, 29 Jan 2018 17:48:22 -0500

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

I have one here - the Pete Gardner compiler. I did my MSc dissertation
on a portable version, and indeed found one or two bugs in the TOPS-10
one!

Please get it on Bitsavers, unless it's already there or there's an
intractable IP restriction.  (Contact Al Kossow)

And there's Essex BCPL:
https://github.com/PDP-10/essex-bcpl

[Bob Eager]

On Tue, 30 Jan 2018 06:04:58 +0000

Post by Lars Brinkhoff

Post by Timothe Litt

Post by Bob Eager
On Mon, 29 Jan 2018 17:48:22 -0500

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

I have one here - the Pete Gardner compiler. I did my MSc
dissertation on a portable version, and indeed found one or two
bugs in the TOPS-10 one!

Please get it on Bitsavers, unless it's already there or there's an
intractable IP restriction.  (Contact Al Kossow)

https://github.com/PDP-10/essex-bcpl

That *is* the Pete Gardner compiler.

[Rhialto]

There is also (unless it's the same as one mentioned before) the BCPL
that I saw back in the Amiga days (AmigaDOS was a slightly hacked up
TRIPOS version, which was written in Cambridge (the real one) in BCPL).

I recall a simple BCPL to bytecode compiler, written in BCPL, and a
bytecode interpreter (presumably written in C), which wasn't to
difficult to get running at the time. The byte code versions were
included for bootstrapping. Something like
http://www.nordier.com/software/bcplkit.html , which seems to be based
on what I remember. There was also some TRIPOS stuff which seemed
interesting at the time because it shed some light on hidden AmigaDOS
internals.

Googling for it finds me the pages of Martin Richards, who was
responsible for TRIPOS. http://www.cl.cam.ac.uk/~mr10/index.html
http://www.cl.cam.ac.uk/~mr10/Archive.html

http://projects.exeter.ac.uk/BCPL/WindowsBCPL.htm links to another
archive called BCPLKIT which contains various major versions over time.
http://emma.nfshost.com/index.html in turn points to a "bcpltape.tar.xz"
with even somewhat different stuff.


-Olaf.

[Johnny Billquist]

Post by Timothe Litt

Post by Dave Wade

-----Original Message-----
Eager
Sent: 29 January 2018 22:08
Subject: Re: [Simh] BLISS and C
On Mon, 29 Jan 2018 12:05:01 -0500

Post by Clem Cole
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

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

[Dave Wade]

-----Original Message-----
Budne
Sent: 30 January 2018 00:17
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
https://github.com/DoctorWkt/pdp7-unix/blob/master/tools/b.c
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).
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
http://mailman.trailing-edge.com/mailman/listinfo/simh

Dave

[Phil Budne]

Post by 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.

The quote the above reminded me of was:
https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

Where Ken Thompson wrote (when he got the Turing prize):

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.

The closest I've found Dennis' name to BLISS is:

http://radar.oreilly.com/2011/10/on-dennis-ritchie-a-conversati.html

Kernighan told me that Ritchie was always conscious of the
benefits of using minimal resources. Much of what he did was a
reaction against the systems he was working with when creating
Unix with Ken Thompson (a reaction to the Multics operating
system) and C (a reaction to the PL/1 language that Multics
was based on). EPL, Bliss, and especially BCPL were more
positive influences on C. The things that made C successful
not only inspired languages and systems that followed, but
kept C a serious contender even after they were developed.