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

[Timothe Litt]

On 28-Jan-18 18:32, Clem Cole wrote:
>
>
> On Sun, Jan 28, 2018 at 4:43 PM, khandy21yo <khandy21yo at gmail.com
> <mailto:khandy21yo at gmail.com>> wrote:
>
>
>     Never had BLISS on anything until long after it would have been
>     useful. So how does BLISS compare to C as a systems programming
>     language? Is it worth learning at this late date?
>
>
> ​I'll try to answer your questions in verse order - probably not worth
> learning; except for some education value and the ability to read and
> really understand any BLISS code you might come upon (if the later is
> something you really need/want to do).
>
> Armando Stetner, of the TIG (Telephone Industries Group in MKO) once
> made a set of 'BLISS is Ignorance' buttons which he gave to a lot of
> people (I still have mine).   While I loved the language, I loathed it
> too.  ​I'm in a interesting position here, because I learned BLISS
> before I learned C, since I was CMU type at the time and a student of
> Wulf and his wife.
>
> 40 years later, I've written way more C then BLISS.  But as Tim
> was saying there were some things about BLISS which I still miss -
> primarily the macro system and the way conditional compilation was
> handled.   It was much more sane that C's preprocessor; and the PDP-11
> optimizer (discussed in the Green Book) made the Ritchie C compiler
> see almost like a toy.
>
> Remember, part of there design of the language was with software
> engineering in mind.  Parnas et al was publishing and there was a lot
> of thought about what made for good programs.  Hence, no goto. 
> Similarly, it included a macro and conditional compilation system -
> which I think was something that really made BLISS and C much more
> useful than say PASCAL.    In fact, people wrote macro systems like m4
> and RATFOR so that PL/1 and FORTRAN could be conditionally compiled in
> a manner than was reasonable.  I've always said, for really SW
> engineering you need to have it (the problem with C/C++ is that it
> gets abused and some resulting code is worse because of it).
>
> The CMU BLISS compiler had one of my favorite errors of all time BTW.
>   You could use single letter like i, j, and k for loop variables, but
> if your real variable were less than 6 chars, you could get an
> 'unimaginative variable name' warning.  So for real system programs,
> expressions tended to actually have meaning and code was readable and
> easy to understand.
>
> BTW, like C, everything in BLISS is an expression and I think that
> worked well.  Also for the PDP-10 at least, it is had no language
> runtime (by the time of Alpha I think that was not wholly true).  
> There were a ton of associated libraries, but the compiler did
> everything.   C never really quite got to that because the Ritchie
> compiler was much smaller, so Dennis put a lot into the runtime under
> the covers.  Frankly, as a user since you are always using libraries,
> I never saw much of a difference.
>
> BLISS suffered one major design error (which was self inflicted and is
> an example of theory vs. practice) and a number of smaller ones that
> became sort of a death of thousand cuts.
>
> The big issue is the Wulf's choice of a 'store into' and 'contents of'
> operators vs. the traditional 'assignment' and C style pointer
> indirection.  His theory is 100% correct and it made the language much
> cleaner and >>once you understood it<<; much more regular.  C ended up
> with *, &, -> and a dot operator to handle different linguistic items.
>   BLISS is much more compact and from a >>compiler's writers
> standpoint<< mathematically explicit (which is what Bill was of
> course).  The idea was that if the language was consistent it make for
> better programs. The problem is that in practice, humans do not read
> code the same way as a compiler and the BLISS conventions take a lot
> of getting used to.   Plus if you are 'multi-lingual' your brain has
> to switch between the two schemes.   [Bill would later admit privately
> at least, it was great concept that in practice, just did not pan out].
>
> And finally, in the days of the old drum printers, if you ever look at
> printouts you will see a certain amount of 'bouncing' of text in a
> line, caused by the head solenoids firing a little early or late.  
> This means tops and bottoms of characters were often cut off and small
> symbols (like the period) might not be seen at all on the paper
> (although if you looked carefully you might see a small indentation
> from where is was supposed to have been -- I have examples of this
> effect in some old listings BTW).  We used to say, if your program did
> not work, get a pepper shaker and a sponge  then pour a few dots and
> remove a few others, and it would start to work ;-)
>
> On the smaller side, there were things like the N different exits.  
> IIRC Wulf used to say that was a bad idea and he should have supported
> labels and then allowed and 'exit' to got to a label.   The language
> took the Algol BEGIN/END and Algol68 idea of spelling word backwards
> to note the end of a something (SET TES, NSET TESN ...).    And of
> course because the implementation of the language was done originally
> on the PDP-10 and then later moved to create a PDP-11 target but as a
> cross compiler, the language needed a PDP-10 to use it.   In both
> cases, there was a lot of memory available and style of the was
> used to develop the compiler, showed.
>
> The self hosting of the B and C compilers by Ken and Dennis on a small
> memory system ensured them to be able to be used.   It forced the
> compiler passes to be in separate processes and the passes used disk
> files (as opposed to memory) to share information.   It also meant
> things like needing to use a separate assembler to create the output
> objects, which BLISS could do directly.
>
> But these things could have been solved if it had been worth it.  I
> think Tim's observation about the pricing was what killed the
> language.   I've often wondered if a the sources had been available
> and the compiler was free, would people have used it to create
> back-ends for other processors, such as the 8-bit or 16
> microprocessors that show up in the mid to late 70s?
>
> We used C because we a head start with the Ritchie and later Johnson
> compilers.    Part of the deal with DEC when Gordon brought BLISS in,
> was that DEC got exclusive rights to the CMU compiler (which CMU
> was perfectly happy to sell to them -- that's another sad story of my
> alma mater).    Plus you needed a PDP-10, which when it was designed
> was not an issue; because most CS depts did have one.   But few places
> really got to see the sources and if you look at were the first
> microprocessor compilers show up, they were not from place like MIT,
> Stanford or CMU.   It was at smaller schools running PDP-11s (although
> later the MIT C compilers would become the standard basis for the 8086
> and 68000 from Steve Ward's RTS team).
>
> Clem
>
>
C as an expression language is a bit of a stretch.  Most C statements
don't return a value; all bliss statements (except ';') do.

Read the Belanger paper that I referenced earlier for his (BLISS's) side
of the comparison, including remarks on the dot operator.  There are
lots of stories about dot bugs, since languages that avoid implicit
dereferencing of addresses are not what people first experience. In
reality, there were fewer dot bugs that survive first contact; they tend
to have obvious effects.  Period, however, was an unfortunate choice for
the lexeme.  It could look like comma on an LPT, as well as perforate. 
In defense of BLISS, I would point out that the C rules for implicit
dereferencing and the 5 operators (Clem left out []) are also confusing
to novices.  Especially when combined with precedence.  Dot is no worse
than remembering to apply gender in French/Spanish (and neuter in
Russian) if you're a native English speaker.  Or Sigil's in Perl.

Belanger points out, and I agree, that the biggest design error was that
values don't have a size; all BLISS values are the native wordsize. 
This causes some unnecessary awkwardness, and math using %BPUNIT,
%BPVAL, %BPADDR and %UPVAL when defining values in structures.  This
usually gets hidden with macros (or SDL) - but is unnecessarily awkward
compared to C.

C requires an RTL, even if you don't do I/O.  The real RTL issue is not
so much whether one is required, but whether it's segmented so that it
can be used in kernel mode.  E.g. the usermode malloc() does not work in
a device driver.  But other RTL routines assume malloc() is available. 
This is quite doable if planned for; in the case of VAX C, the goal was
user mode compatibility, not kernel mode use.  This was a reasonable
goal (allowed POSIX compliance), but inhibited adoption for system
programming.

Fred Kleinsorge managed to find a subset of VAXC constructs that avoided
the worst of the RTL, and was able to put VWS (and DECWindows) terminal
emulation into inner modes.  I used this for some specialized drivers
(rather than BLISS because I reused and modified Fred's code).

The Alpha port of VMS emphasized writing new stuff in C, and a real
subset kernel mode RTL was developed for DECC.  (DECC is more dependent
on an RTL than VAXC).

I, too, have ended up writing much more C than BLISS.  (And still more
if you count the C cousins like javascript & Perl.)

It's like VHS and Beta.  Partly religious, but the best technology
doesn't win when when "good enough" is cheaper.

BLISS is like the PDP-10.  I miss both, but the world has (mostly) moved on.

I'm mostly agnostic; "pick the tool that fits the job".  But constrained
by the era :-(


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