1 Jun
2023
1 Jun
'23
2:42 a.m.
On May 31, 2023, at 8:21 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
A VMS listing on Bitsavers? That will be worth a look, for sure. I guess it would also
include the NICE of the era?
Yes, it seems to.
http://www.bitsavers.org/pdf/dec/vax/microfiche/vms-source-listings/AH-BT13…
-- so it's V4.0 as well as the V4.1 deltas.
Yes, I know Bliss. Or knew it... Bliss was a huge
deal in Marlboro in the late 70's when I was around or at least corporate was trying
to make it so. Any new hire was signed up for a Bliss Common class where the all the
virtues of cross platform compilation were extolled. Bliss wasn't adopted as a
replacement for any existing major 36 bit software system that I recall, with a few
exceptions. So, I don't recall that any Tops-20 monitor modules were replaced.
Nothing in the EXEC was, but the EXEC's PCL interpreter was written in Bliss.
As I recall, Bliss was used in the implementation of certain languages. Not for Algol,
which has one of the more interesting macro sources I've seen. FORTRAN is.
Although somewhat cross platform (I.E. Tops-10 and Tops-20), Galaxy remained in assembler
with the exception of the NICE process (NMLT20). This was originally written in
assembler, as can be seen from the PHASE II Tops-20 DECnet sources but was eventually
implemented in Bliss and not released. This caused a fair amount of ill will as early
Bliss versions had stability issues and crashed regularly. I typed up a number of
SPR's about that.
It would be an interesting question to see how much code was actually shared for NICE;
one assumes it could have been a fair amount. The Tops-20 RMS-20 product appears to have
a DAP implementation in BLISS, so that will be worth looking at.
I think Bliss probably had greater platform penetration for VMS. The Kermit-10 is
actually written in Bliss and will compile for both Tops-10 and VMS. In fact, because it
uses Galaxy, it has compilation hooks for Tops-20, a number of which are implemented. I
think it might be interesting to play around with that at some point as it appears to be
an orphan now.
As I understand it, BLISS was the primary implementation language for VMS; while selected
bits of the kernel were MACRO-32, it seems BLISS is found in most other places.
I wonder what happened in the ports. Is there a BLISS-64 (for ALPHA)? It would be
possible, with the GEM framework which (like GCC) allows for several language front-ends
and several machine code generator back-ends. For that matter, what does the x86 port of
VMS use?
I remember that the ALPHA assembler was a GEM based tool, with some tricks to feed more or
less directly into the far end of the code generator. But, curiously enough, you could
tell it to assemble with optimization: that would take your assembly code and perform some
of the normal compiler-type optimizations. I used that once, when I was experimenting
with assembly language code for high speed combined memory copy and checksum calculation.
It's a shame about the lost specs, particularly if
they were adhered to, which appears to largely be the case with DECnet. For certain
Internet protocols, you just have to see what is going over the wire and reverse engineer
from that. Not the end of the world, but not particularly pleasant, either.
In the architecture group there was a clearly recognized principle -- I think it was
actually stated -- that "conformance implies interoperability". In other words,
if you do what the spec requires, "it will just work". One of the reasons
Ethernet was so successful is that this principle holds there, as it does for DECnet. I
remember writing the RSTS software DDCMP driver simply by doing what the DDCMP spec calls
for, and it worked exactly as specified. Sure, I had some bugs where I slipped up, but
the spec told me what the right answers were.
The IETF does NOT operate that way. I once, during the development of the iSCSI spec (RFC
3720) tried to argue that some part of the spec needed repair because it wasn't
precise enough to ensure that conformance implied interoperability. At that point the
spec editor (Julian Satran of IBM Research) told me point-blank "that is not a goal
of the spec". And sure enough, just like many of its friends, you can conform to the
iSCSI spec and yet fail to talk to other implementations. The notion of "interop
labs" and cross-company test run get-togethers is the price you pay for such sloppy
specsmanship.
paul