[HECnet] SCSISE adapter -> listings

[Brian Schenkenberger, VAXman-]

Clem Cole <clemc at ccc.com> writes: 

--e89a8ff2534a88b73804d345c72d Content-Type: text/plain;
charset=ISO-8859-1 

On Mon, Jan 14, 2013 at 10:13 AM, Brian Schenkenberger, VAXman- <
system at tmesis.com> wrote: 

It was a question of why go out of ones > way to recode in C. > 

No idea, but the numbers did not lie.   The customers wanted C not BLISS
and if you look at the number of customer projects that switched to it
outside<< of DEC, it was not even close. 

I learned BLISS/10 and BLISS/11 (and eventually BLISS/32) at CMU on the
10s before I learned C.   When I first saw C (the white book had not yet
been written) and I was not not assumed, particularly since the BLISS
macro processor and code generator were so far advanced from dmr's
compiler. But I quickly learned that I >>preferred<< C for a number of
reasons.   Originally, because it was self-hosting which BLISS was not
for the PDP-11 and my edit/compile/test cycle was just so much easier. 

That said for early VMS editions, when there was not C, all we had was
BLISS, so I used it; but I also used to grumble as I had been
enlightened from the dark side.   I can definitely state that Stan and I
had had Culter's VAX11-C when wrote the TCP stack we would have use it
not BLISS - but it was all we had and his compiler was a good 3-4 years
into the future. 

Late on Larry and I used to talk about this at lunch.     I think most of
the system folks in the VMS group that really learned C, eventually came
to the same spot as I did.     It was just an easier echo system to use;
but they key was that were not trying to use BLISS I/O, we used C calls
once we switch over - which may have been what make you think that it's
support was not as good. 

BLISS has no I/O, and if you want to be pedantic, nor does C.   I/O is
all via support libraries which provide I/O.   Neither language has any
inherent I/O syntax.   A BLISS coder would call some VMS RTL or delve 
into $QIO to do I/O.

I don't understand your comment: what make you think that it's support
was not as good.   The CRTL functions are wrappers calling RMS, RTL or
system services.   Their "support" is as good as the implementation of
the underlying services they evoke.



That said, the compiler guys (Grove at al), doggedly stayed with BLISS
to the end.     Rich and I have also talked about the issue, including the
"what if GEM has been in C not BLISS" - would Intel have been able to
accept it as the base?     An interesting thought [instead the DEC DNA is
ground up and reinjected]. 

There are a lot of other details/issues.   I'll ask Mr. Compiler if he'd
care to comment WRT to this. ;)

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker       VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.