sasaki@harvard.ARPA (Marty Sasaki) (01/13/85)
Warning! This posting contains a major digression from the discussion of
Pascal as a system implementation language. I thought it would be
interesting enough in general for a posting.
All of this talk about optimization of C code vs. Pascal code, and
Pascal as a system implementation language reminds me of the time I
asked someone in the VMS development group why they didn't choose C for
their system implementation language (they chose Bliss). He answered
that C required an optimizing programmer in order to produce code that
was good enough for an operating system kernel.
The VMS folks also looked at Pascal, but felt that they didn't have
enough control of the machine in Pascal without seriously changing the
language.
In the discussion that followed the VMS guy basically said (please note
that these are my interpretations of the conversation):
1. They had to assume that the programmers that they used would
be good, but not necessarily great.
2. The language/compiler had to be very good to sell management
on using a high level language for system implementation.
Point 2 is important all by itself, but point 1 implies that the programmer
would probably not be able to consistantly produce code that was efficient
and that worked in a timely fashion. An optimizing compiler was doubly
important.
To those that argue that Bliss is no better than assembly language let
me say that tests done by DEC indicate that the Bliss-32 compiler
produces code better than that written by experienced assembly language
programmers.
--
Marty Sasaki
Havard University Science Center
sasaki@harvard.{arpa,uucp}
617-495-1270laura@utzoo.UUCP (Laura Creighton) (01/14/85)
In the end, VMS got written mostly in assembler anyway (unless they have gone and re-coded later version, which I doubt, but stranger things have happened). I have it from several sources that the reason this happened was because a certain prominent DEC individual decided that no compiler could write code as good as his assembler (ie it wouldn't be fast enough). So much for consistency... Laura Creighton utzoo!laura
sasaki@harvard.ARPA (Marty Sasaki) (01/17/85)
> In the end, VMS got written mostly in assembler anyway (unless they have > gone and re-coded later version, which I doubt, but stranger things > have happened). I have it from several sources that the reason this > happened was because a certain prominent DEC individual decided that > no compiler could write code as good as his assembler (ie it wouldn't > be fast enough). So much for consistency... > > Laura Creighton > utzoo!laura VMS version 1 was written mostly in assembler. Parts of version 2 got rewritten in Bliss. The most notable of the rewrites was the file system ACP (the thing that converts file names into physical disk block numbers). Andy Goldstein rewrote it in Bliss and carefully wrote some of the routines in assembler to compare against the Bliss. The Bliss generated code was smaller. -- Marty Sasaki Havard University Science Center sasaki@harvard.{arpa,uucp} 617-495-1270
rcb@rti-sel.UUCP (Randy Buckland) (01/17/85)
> To those that argue that Bliss is no better than assembly language let > me say that tests done by DEC indicate that the Bliss-32 compiler > produces code better than that written by experienced assembly language > programmers. HAH!!!!!!!! For the bare language, I might agree. However, any macro programmer worth the name after a year or so will have developed a set of macros that enable high level constructs but still allow precise control of the machine. I personally have a set of macros that give me more high level capabilities that C does. My assembler programs are more readable and easier to modify than any bliss program that I have ever seen. Maybe the compiler uses an odd instruction that takes 3 nanoseconds less than the one I used. Mine is usually more logical and easier to understand. Randy Buckland Research Triangle Institute ...!mcnc!rti-sel!rcb
rpw3@redwood.UUCP (Rob Warnock) (01/17/85)
+--------------- | In the end, VMS got written mostly in assembler anyway (unless they have | gone and re-coded later version, which I doubt, but stranger things | have happened). I have it from several sources that the reason this | happened was because a certain prominent DEC individual decided that | no compiler could write code as good as his assembler (ie it wouldn't | be fast enough). So much for consistency... | Laura Creighton | utzoo!laura +--------------- My understanding is that there was a single kernel guru who stood in the way, even after several code-offs had shown that BLISS-32 was as fast (AND as small) as assembler. So the kernel is in assembler, but the system utilities and some of the driver ACPs are in BLISS. (The VAX really is a "BLISS machine".) Ironically, BLISS-32 ran native on the VAX long before the assembler did -- the assembler was written in PDP-11 assembler, and was used for a long time from PDP-11 compatibilty mode. I believe the current assembler is written in BLISS (no?). Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
henry@utzoo.UUCP (Henry Spencer) (01/30/85)
> Ironically, BLISS-32 ran native on the VAX long before the assembler did -- > the assembler was written in PDP-11 assembler, and was used for a long time > from PDP-11 compatibilty mode. I believe the current assembler is written > in BLISS (no?). Some of us suspected all along that PDP-11 compatibility mode existed mostly so that DEC could be lazy about moving its support software. This explains why compatibility mode does not support floating-point or split-space: the DEC software never used either. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry