garys@bunkerb.UUCP (Gary Samuelson) (09/30/83)
The discussion of moving from one OS environment to another
(TOPS-xx -> UNIX) has prompted me to add my two bits worth.
I have recently moved from a VAX/VMS environment to a VAX/UNIX
environment, so I think it safe to say that the difference is
in the software.
So far (approximately 6 months) I prefer VMS.
Several reasons come to mind, without even trying hard:
1. Useful documentation. The VMS manuals are complete, consistent,
and indexed. For those of you who don't know, in this context
'index' means an alphabetized list of topics, with references
to volume(s) and page(s) where each topic is discussed. Yes,
I have seen the permuted index at the beginning of the Unix
Programmer's Manual; I'm not impressed. To use the Unix
Programmer's Manual, I have to have prior knowledge of either
the name of the command which does what I want, or the wording
of the one line description of that command. The problem is
compounded by the fact that the manual I have is a hybrid of
'3rd Berkeley Distribution,' 4th Berkeley Distribution',
'7th Edition,' local stuff, and who knows what else. In general,
if I don't already have the information I need, it's hard to
find it in the manual. Not all the commands are documented
in my manual, anyway.
2. On line help information. And, yes, I know about the 'man'
command. With many of the VMS utilities, there was a 'help'
facility which could be used while running that utility.
Furthermore, you could specify what topic and subtopic and
subsubtopic you needed help on. Of course, if you have
already memorized the manual, you don't need help, and would
not find this a useful feature.
3. Meaningful status messages. VMS features 4 part status messages,
each of which can be individually disabled, if you're fond of
terseness. The four parts are facility, severity, mnemonic, and
text. Facility is the name of the software which discovered the
error, severity is how bad it is (success, information only, warning,
severe, fatal), mnemonic is an abbreviation (such as NOTFOUND), and
text is a descriptive phrase. The other day, using Unix, I spent an
hour trying to find out what 'error code 1' meant. It turned out
to mean a multiply defined symbol. When 'cp' can't open a file,
I need to know why not. Was the name mispelled, is it protected,
is the device offline, is the device protected, is the device
broken, is the device full, etc. etc.
4. Meaningful status codes. This is really the binary equivalent of
the status message. The low 3 bits of the status returned by
VMS functions indicates whether the function was completed
successfully or not (this translates directly into severity,
above). Conveniently, odd numbers always meant success, but
could mean success with additional information.
5. Meaningful file extensions. With VMS, you don't need to have
a program called 'file' to 'guess' what type it is; you know
by looking at the extension. A source file for the BASIC
language ends in '.BAS'; for FORTRAN, '.FOR' etc. An object
file ends in '.OBJ'. A command file (script in Unix) ends
in '.COM'. Unix's 'file' utility has called scripts 'C'
source text on occassion. By the way, what's the difference
between 'English Text' and 'Ascii Text'? As an added benefit,
if you invoked the Fortran compiler, it knew it was supposed
to look for a file whose name ended with '.FOR', if no
other extension was supplied.
6. Consistent command formats. Qualifiers always start with a
slash. Filenames always consist of alphanumerics (yes, I've
seen the arguments about funny characters in file names, and
I know they are occassionally useful). Qualifier names can
be more than one character long, so you don't have to remember
whether '-o' or '-O' is what you want.
7. Automatic version numbers. Each file has a version number
associated with it. When you make a change, the version number
is incremented. When you specify a file without an explicit
version number, the latest version is used, which is usually
what is desired. When you delete a file, you must specify
a version number, so that files don't get deleted accidentally.
If you make a change which turns out to be incorrect, the
previous version is still available.
8. Abbreviations. Both command names and qualifier names could
be abbreviated to the minimum required to be unique. The full
name could be used in a command file, both to aid a future
reader and to prevent ambiguities when a new command is added.
9. User defined commands. Under VMS, I could define a command to
replace any of the system commands, and it didn't require a
dollar sign in front of it, it didn't require a whole file
(minimum size 1 block), and it didn't take up room in my directory.
10. Separate protection bits for write and delete. I could keep from
deleting a file, while retaining the ability to modify it.
Useful in conjunction with version numbers.
11. Consistency. This is probably the biggest, without which some
of the problems above could not be fixed. Only one company
supplies VMS, as far as I know. You can add your own modifications,
but no one else is expected to consider them part of VMS.
Since VMS comes from only one source, there is the possibility
of vendor support.
Those are advantages, in my opinion, of VMS over UNIX. And yes, I
do know that UNIX has advantages over VMS; I know about pipes, and
subshells. But so far I prefer VMS.
Gary Samuelsonguy@rlgvax.UUCP (Guy Harris) (10/01/83)
Some of the points are valid criticisms of UNIX, some are not:
1. Useful documentation.
UNIX documentation is useful for people who already know what is there.
There is no way that a state where the existing UNIX documentation is the
*only* documentation available can be justified, except by saying "we can't
afford the time". Now that UNIX is a Real Live commercial operating system,
this doesn't hold water.
2. On line help information.
On this one, people may argue that VMS-style on-line help is the wrong
solution to the problem. I don't take any stand on this myself, but I
can see the point of the people who want more than "man".
3. Meaningful status messages. VMS features 4 part status messages,
each of which can be individually disabled, if you're fond of
terseness.
I don't know if I'd go as far as having UNIX put out VMS or OS/360-style
error messages (I seem to remember a case where a low-level VMS routine
detected an error; it dutifully printed an error message, and passed the
error code back to the next routine up, which dutifully printed an error
message, ...), but "can't open"-type messages aren't the best that can
be done. If UNIX told you why the file couldn't be opened, it would save
a lot of "ls" commands to figure out if the file doesn't exist, or isn't
readable/writable by you, or.... ("perror" doesn't provide the ideal
interface for producing the sort-of standard UNIX error message
"program: complaint"). N.B. UNIX isn't the only system which does this;
RSX-11M also has "can't open"-style messages.
4. Meaningful status codes. This is really the binary equivalent of
the status message. The low 3 bits of the status returned by
VMS functions indicates whether the function was completed
successfully or not (this translates directly into severity,
above). Conveniently, odd numbers always meant success, but
could mean success with additional information.
The inability of UNIX system calls to indicate success with additional
information (like "the write to the tape succeeded, but it also hit the
foil at the end of the tape") is a nuisance.
5. Meaningful file extensions. With VMS, you don't need to have
a program called 'file' to 'guess' what type it is; you know
by looking at the extension. A source file for the BASIC
language ends in '.BAS'; for FORTRAN, '.FOR' etc. An object
file ends in '.OBJ'. A command file (script in Unix) ends
in '.COM'. Unix's 'file' utility has called scripts 'C'
source text on occassion. By the way, what's the difference
between 'English Text' and 'Ascii Text'? As an added benefit,
if you invoked the Fortran compiler, it knew it was supposed
to look for a file whose name ended with '.FOR', if no
other extension was supplied.
With UNIX, a source file for the C compiler ends in ".c"; for FORTRAN, ".f",
etc. An object file ends in ".o". A command file ends in nothing, because
it can be *either* an executable image (VMS ".EXE") or a shell file
(VMS ".COM"). "File" does the best it can with heuristics, but it can't
get it 100%. Nothing prevents you from creating a file with a null extension,
or worse an *invalid* extension, with VMS. I could create a binary file
called "FOO.BAS" and watch the fun when someone tries to "TYPE" it. (The
difference between "English text" and "Ascii text" is based on character
frequencies, although a file of all nulls is considered "English text"(!).)
As an added benefit, you can type
f77 foo.f bar.f bletch.c mumble.s frotz.o
and compile and link a program consisting of two FORTRAN modules, one C
module, one assembler module, and one already-compiled object module.
6. Consistent command formats. Qualifiers always start with a
slash. Filenames always consist of alphanumerics (yes, I've
seen the arguments about funny characters in file names, and
I know they are occassionally useful). Qualifier names can
be more than one character long, so you don't have to remember
whether '-o' or '-O' is what you want.
The UNIX command format is a bit of a pain, but there is a tradeoff between
terseness (which speeds up work) and clarity. Qualifier names in UNIX
*can* be more than one character long (the "-onetrip" qualifier to "f77"
is a case in point), but they generally aren't.
7. Automatic version numbers. Each file has a version number
associated with it. When you make a change, the version number
is incremented. When you specify a file without an explicit
version number, the latest version is used, which is usually
what is desired. When you delete a file, you must specify
a version number, so that files don't get deleted accidentally.
If you make a change which turns out to be incorrect, the
previous version is still available.
As long as the operating system can be told to keep only the last version,
or last N versions around, this isn't too bad (although there is code
required to implement it, and extra work for users; there is a tradeoff
here). If versions hang around until you explicitly purge them, this is
no good, because versions can pile up (I saw a file on a VMS system with
50 some versions!). Under UNIX, systems like the Source Code Control
System and the Revision Control System provide this and more besides for
source files, and having several versions of object or executable code
is of unclear merit.
8. Abbreviations. Both command names and qualifier names could
be abbreviated to the minimum required to be unique. The full
name could be used in a command file, both to aid a future
reader and to prevent ambiguities when a new command is added.
Abbreviated command names would be tricky under UNIX because of its flexibility
in adding new commands. To disambiguate the command it would have to look
in ALL the directories in your search path. Which brings us to:
9. User defined commands. Under VMS, I could define a command to
replace any of the system commands, and it didn't require a
dollar sign in front of it, it didn't require a whole file
(minimum size 1 block), and it didn't take up room in my directory.
If your command did a lot of work (i.e. it wasn't just a shell variable),
it would be either a program or a shell file and as such would have to
take up a whole file and a directory entry. Some UNIX shells (the C shell
and the Korn shell; the latter is an extended Bourne shell) support the
ability to add commands by creating "aliases" or "functions"; in this case
they do not require an executable or shell file. How convenient is it to
add new commands under VMS? Under UNIX you can have multiple directories
full of commands, and as soon as you drop a file in there it is available
to everyone who has that directory in their search path. Can the same be
said for VMS?
10. Separate protection bits for write and delete. I could keep from
deleting a file, while retaining the ability to modify it.
Useful in conjunction with version numbers.
Nice, but again there is a tradeoff here.
11. Consistency. This is probably the biggest, without which some
of the problems above could not be fixed. Only one company
supplies VMS, as far as I know. You can add your own modifications,
but no one else is expected to consider them part of VMS.
Since VMS comes from only one source, there is the possibility
of vendor support.
Well, since VMS only runs on one machine this is a bit easier to do. Try
a shop with a VAX-11 or two and several 68000-based workstations. Unless you
put VMS up on the 68Ks (a little tricky, considering how much of VMS is still
in MACRO-32) you have a far greater consistency problem than if they both
ran UNIX. UNIX comes from several sources and the vendors generally support
it (Bell supports the PDP-11, VAX-11, and 3B versions, and most people offering
"UNIX boxes" support the version on their machine). Western seems to be trying
to bring all UNIXes under one roof (theirs), with their arrangements with
the major chip vendors.
So yes, there are things that VMS (or any other OS) does better than UNIX,
and there are things UNIX does better than other OSs. One thing UNIX does
better than almost all other operating systems is run on most of the machines
a heterogeneous site has in house; this alone is worth a *lot*. (We can do
development on fast VAXes, and ship the code to our 68000 machines and debug
it.) So it's certainly not an open-and-shut case for VMS; if a lot of the
problems with UNIX that *can* be cleared up are, a lot of the anti-UNIX
arguments will fall by the wayside.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guykar@ritcv.UUCP (Kenneth A Reek) (10/02/83)
I can't resist throwing in my $.02 worth on the subject of switching from one
operating system to another.
In most of the cases I have observed, the first real operating system
that a person knows is the one he/she likes best (where "real" means "sophis-
ticated", i.e. complex, offering lots of services, etc.). The reason for
this is simple, as the person becomes more adept at using the system, he/she
learns more of the personality (i.e. quirks) of it, and experienced users
tend to formulate their problems in terms of the operations they are so fami-
liar with.
When users go from one operating system to another, it is worse than be-
ing a computing novice, as a novice would not know what to expect. Users ex-
perienced on another system know what to expect and will judge the new system
in terms of the one they are familiar with. This is how we learn, by compar-
ing new situations against our past experiences.
The problem with this is that the new system cannot be as good at being
the old system as the old system was. Until the new system is learned in as
much depth as the old one, the new system will be perceived to have shortcom-
ings in the areas it differs from the old. In other words, the new system
cannot be adequately judged until the judge comes out of the "rut" of think-
ing in terms of the old one.
Therefore, it occurs to me that one measure of the "goodness" of an
operating system would be the number of people who love it that previously
thought a different system to be the ultimate in sophistication. I used to
love the CP-V operating system on the Xerox Sigma computers (I'm now ashamed
to admit) because I was familiar enough with it and its utilities to be able
to accomplish whatever I wanted to do quickly and easily. However, because
I was thinking in the CP-V rut there was very little that occured to me to do
that was at all complex. Before I started using Unix, for example, it never
even occured to me to take the output of a system utility (such as the CP-V
equivalent of "ls") and send it to a file to be manipulated with an editor
into a bunch of commands to do something to the selected files, and when I
eventually tried it on the Sigma, I found it easier to just type the commands
themselves.
The point is simple: until I started think of doing things the Unix way,
I thought Unix was a poor substitute for CP-V. I am now a devoted Unix fan,
so devoted that a few years ago I decided against taking a higher paying job
primarily because they didn't use Unix.
I have observed more people "converted" to Unix than to any other sys-
tem. I think this is an important metric when measuring the quality of an
operating system, as it really expresses differences in user satisfaction
between systems.
Ken Reek, Rochester Institute of Technology
seismo!rochester!ritcv!kardave@utcsrgv.UUCP (Dave Sherman) (10/03/83)
"Separate protection bits for write a delete" ?
UNIX already has this, albeit for strange reasons. If the directory is
not writable, you cannot delete the file, although you can modify it
if you have permission to write on the file.
Dave Sherman
Toronto
--
{cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!lsuc!davewls@astrovax.UUCP (10/03/83)
I believe that if the "man" command is given with no arguments it should
print out a list of available topics. It has also been one of my own
complaints about UNIX, that the documentation was useless unless one
already knew what one was looking for anyway. It is hard to browse. This would
help alleviate this a little. I prefer the VMS "HELP" command (which behaves
this way) to the UNIX "man" command. The latter makes prettier copy when run
through a typesetter but the former is more useful when sitting in front of
a terminal.
William L. Sebok {allegra,cbosgd,decvax,ihnp4,kpno}!astrovax!wlsjhh@ihldt.UUCP (10/03/83)
Isn't it a coincidence that version numbers are common amoung companies that sell both disk drives and operating systems? A thought to ponder. A certain microprocessor/memory manufacturer sold a real time operating system that occupied several times the memory of an independently designed RTOS with similar capabilities. John Haller ihldt!jhh
dvk@mi-cec.UUCP (Dan Klein) (10/04/83)
Well, here is my 2 cents worth: I have been working with/in Unix since our center had an 11/34a with 2 RK05's (yeah, that little), and a late V5 distribution (pre V6 and V7!). I have also been working with VMS since it was in Beta release in 1978. I therefore feel qualified to comment on both operating systems without much bias, and certainly without being affected by the "I learned on this one, it's the one I'll stay with" syndrome (since I've also worked with/in TOPS-10, Hydra, RT-11, etc.). 1a) Unix has a great user interface - if you know what you are doing. If you don't, forget it, because the user help interface stinks. There is absolutely no equivocation on this point. 1b) VMS has a verbose, laborious user interface. It is VERY consistant in that all programs talk to the DCL the *same* way (not a random, programmer defined way). The help facility is pretty detailed, so if you don't know what to do, you can probably find out. 2a) Unix documentation is okay (only barely) if you know what you are looking for. There are an *awful* lot of undocumented features. And one big pet peeve: Why the hell is there a BUGS section? If you know about it, then FIX IT, damn it! 2b) VMS documentation tells you *everything*, which is great, but there are cases where you have to *read* everything before you can do *anything*. VMS also has real indices, not this crappy ptx stuff. 3a) The Unix set of primitives is pretty sparse. And also pretty redundant. (i.e. read, fread, getc, getchar, cgetc, fgetc...). Give me *one* primitive to do stream input. You can create macros to get all the syntactic sugar you like, but enough diversity, already. 3b) The VMS set of primitives is very robust, albeit a little complicated at times. You can do most anything, although there are a few bits of bogosity here and there. On the whole, this is VMS's biggest win. 4a) Unix has stream oriented files. They are very nice. What is not so nice is the fact that that is all you get. 4b) VMS has all *sorts* of file types. Unfortunately, they don't really have the easy to use Unix flavor stream oriented files. 5a) C stinks. It is inconsistant, irregular, and generates lousy code. It can also be damn near unreadable. It *is* "portable", though. 5b) Bliss is wonderful. It is consistent, regular, and generates the best code this side of the Pecos. If you don't believe it, try a comparison yourself. I have. It too can be unreadable, but not as badly. Unfortunately, it *isn't* portable. Too bad. 6a) The Unix concept of 14 million little applications programs leaves something to be desired. Why do cat, pr, more, dd, tar, and write all have the ability to dump a file to your terminal? One program to subsume these features might be nice. 6b) The VMS concept of 1 mongo application to do everything leaves something to be desired. Sometimes it is nice to have a few million little programs. But you can get them in VMS by defining aliases that set switches in the mongo program. 7a) Unix is by and large unsupported. 7b) VMS is by and large very supported. 8a) Unix has these *wonderful* things called pipes that can be accessed directly from the shell. It also has a history mechanism and on some systems command completion. Internally, the implementation of the first and last of these is a bit of a crock (a bit?), but they are great. 8b) VMS ain't got no. Pity. 9a) Unix would be *great* if someone wrote real documentation, and tore the whole thing down and started over. The concepts have a *lot* to say for them, but the implementation has been pretty haphazard along the way (translation: crocky). Improving on the primitives and providing a consistant tool set would also be nice. Consider the past 6 years to be an experiment, and now do it right. (Hear that, GNU people?) 9b) VMS would be *great* if someone wrote a real command interpreter for it, like the shell. I would be *very* surprised if this is not in the works now at DEC. Both VMS and Unix have a lot to say for them. Both have negative points. In attempting to remain unbiased (by the way, we run *both* here), I constantly oscillate in choosing a "favorite". Both are bogus, and both are nice. The OS of choice would be a hybrid. -Dan Klein, Mellon Institute, Pittsburgh
philipl@bronze.UUCP (Philip Lantz) (10/07/83)
I just had to respond to Dan Klein's article about VMS and UNIX. While he made some very good points and I agree with most of what he said, there are a couple things I just have to argue with. "The Unix set of primitives is ... pretty redundant. (i.e. read, fread, getc, getchar, cgetc, fgetc...). Give me *one* primitive to do stream input. You can create macros to get all the syntactic sugar you like...." WHAT ARE YOU TALKING ABOUT??? UNIX has *exactly one* primitive to ANY kind of input: read(). All the others you mentioned ARE JUST THE SYNTACTIC SUGAR. They are contained in the library, are user code, and need not be used, if the programmer does not so desire. In contrast, how many OS entry points are there to VMS to do input? (I honestly don't know, but I'll bet there are more than one!) I agree with his points about the user interface and the documentation. I very much like the UNIX interface, because I do know what I'm doing. But what he doesn't mention about it is that it can be changed at will. You're not stuck with the shell. On VMS, if you don't like DCL (or whatever that other one is) you're out of luck. On UNIX, I can modify the shell to suit me, use that one, and not bother anyone else on the system. Philip Lantz textronix!bronze!philipl
guy@rlgvax.UUCP (10/10/83)
uses kernel and user mode
on the PDP-11) the FCS and RMS libraries have no extra privileges - they are
just user mode libraries - and the kernel I/O interface provides the abstraction
of a linear array of blocks (Stonebraker's article in CACM on OS support for
DBMSs to the contrary - the record-handling facilities of RSX are no more
in the kernel that any record-handling facilities in UNIX). Of course, DEC
doesn't tell you how to do an OPEN or CLOSE QIO, and knowing them they may
even require executive-mode privilege to perform those or other operations
that RMS does.
Some of those DEC operating systems also let you install your own CLI
(the ten-dollar DEC word for what UNIX calls a "shell"), but I suspect it's
more complicated than installing a new UNIX shell, and they probably discourage
it in general and only think system programmers and system administrators
should do it...
One of the advantages to UNIX in this regard is that it doesn't try to keep
the keys to the kingdom away from everybody except Authorized users. It gives
you enough rope to hang yourself, true, but it also gives you enough rope to
hitch your horse to your wagon... It's "implementor-friendly" in that you
may have to devote energy to implementing things that the OS doesn't support
at all (like file and record locking), but it doesn't force you to do as much
programming around the OSs restrictions as other OSs do.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guydvk@mi-cec.UUCP (Dan Klein) (10/10/83)
Yes, I guess I stand corrected - the Unix primitive is read(). And all the other calls are just macros on top of them. The problem I have encountered is that they are inconsistantly implemented, and well, we can flame back and forth about this point for weeks. Both Unix and VMS have their shortcomings on all counts. To answer another point, you *can* implement your own command language in VMS. Yes, you *initially* have the choice of either DCL or MCR (and in a little while, VNX), but after that, you can do as you please. Look at HCR's Unity or EUNICE. Someone even did a history/command completion system for DCL. The *nice* thing about VMS (or the bad thing, depending on where you look) is that you start out *on top of* DCL. This gives you the advantage of a bailout point, and also gives you the ability to call on the existing DCL primitives (you don't have to reinvent the wheel). Both sh and csh have to implement their own command scanners (from scratch), while EUNICE simply uses the existing DCL scanner. There are wins and loses to both. -Dan Klein, Mellon Institute, Pittsburgh
dave@rlgvax.UUCP (10/10/83)
I agree with Guy Harris, especially on the last point regarding the OS letting
you do what you want, or having to get around its restrictions to do what you
want. Either way, if the implementors are stubborn enough, they are going to
get done what they want done. They would prefer not to have brick walls in front
of them that they have to tear down or walk around. One of the philosophies
behind Un*x and C is not to be TOO smart. Not to assume too much about what
programmers do and do not want to do. To be flexible. To be as powerful as
possible without holding the programmer's hand. You wonder why there are so
many C programs out there running on Un*x OSs? You wonder why there are so
many modifications to Un*x? It's because someone wanted those things and
they COULD be done. They could be done faster and easier. The idea of adding
restrictions to prevent the user from doing something he really didn't want
to do is found in Pascal, not C. Likewise, that idea is in VMS, not Un*x.
- Dave Maxey (alias tbm)
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!daveron%brl-vgr@sri-unix.UUCP (10/13/83)
From: Ron Natalie <ron@brl-vgr> Now wait a cotton picken minute. How can you say that BLISS produces better code than C. That is an entierely implementation dependant thing contingient on what machine you are running on, which version of the compiler you are using and what level of optimization you are asking it to do. -Ron
dbj.rice%rand-relay@sri-unix.UUCP (10/14/83)
From: Dave Johnson <dbj.rice@rand-relay>
"If the VMS C compiler is as good (code wise) as BLISS ..."
Sadly, the VMS C compiler's code isn't as good as the Bliss compiler's.
While it does an excellent job of optimizing register usage over the whole
procedure and emiminating all kinds of "dead" code, etc., it fails fairly
badly on some very simple local optimizations. For example, it generates
three instructions to check if one of the "wonderful" VMS return codes
(currently being discussed on this list (sigh)) is a success or failure
code. The Unix C compiler (pcc) generates only one instruction for the same
thing...
Dave Johnson
Dept. of Math Science
Rice University
dbj.rice@Rand-Relaycak@Purdue.ARPA (10/14/83)
From: Christopher A Kent <cak@Purdue.ARPA> As I recall, Bliss was designed to produce extremely tight code, but not necessarily fast code. C has been rumoured to have exactly the opposite design goals (I think I've been in this argument before). It is certainly possible to do better than the VAX Pcc code generator; it used to be fairly common knowledge that the optimizer wasn't that great, and often overlooked the obvious. I don't know that Berkeley has done that much hacking on it. chris ----------
gwyn%brl-vld@sri-unix.UUCP (10/19/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> I think DVK is right about BLISS. The only BLISS compilers I know about are "globally optimizing". The only C compiler I have heard about that attempts this level of optimization was done for a single CPU type (I forget which -- was presented two USENIX conferences ago) and still is unlikely to beat BLISS as implemented by DEC. DEC's VAX/VMS C compiler is presumably also highly optimizing. As things now stand, those of us who really care about run-time code efficiency resort to hand-optimizing our C source through careful use of "local block" register variables and pointers, although this would be better done by the compiler in many (not all) cases. The worst culprit is multiply-indexed arrays, speaking of which there should be a reasonable way to write functions with variably-dimensioned matrices as formal parameters! On the other hand, BLISS is not widely available, and I was assured by the developer that it would "never" fit on a PDP-11. (Clearly a BLISS compiler could do so, and I seem to recall a really old BLISS-11 that did, but it was not the modern compiler.) BLISS does have some neat features that C doesn't, such as anchored variables. Otherwise it is functionally equivalent to C, although to my mind not as readable (I hate all those dots). I think I would agree that BLISS has a much better definition than anything I have seen for C, and it does hang together well. I doubt that I'll ever use it, though!
ron%brl-vgr@sri-unix.UUCP (10/19/83)
From: Ron Natalie <ron@brl-vgr> If the VMS C compiler is as good (code wise) as BLISS then it certainly indicates that it isn't C's fault that the code on UNIX isn't as good. -Ron
JTW%mit-xx@sri-unix.UUCP (10/20/83)
From: John T. Wroclawski <JTW@mit-xx> Now wait a cotton picken minute. How can you say that BLISS produces better code than C. That is an entierely implementation dependant thing contingient on what machine you are running on, which version of the compiler you are using and what level of optimization you are asking it to do. -Ron Fundamental characteristics of the language have an effect, too. The presence of unrestricted GOTO's in C makes it *much* harder to implement a really good (read "globally optimizing") C compiler than an equivalent BLISS compiler. That's one of the main reasons BLISS left them out. The only widely available C I've seen in this category is the DEC VMS compiler. Through global optimization and clever use of the VAX's more complex addressing modes it generates code with far fewer instructions than, say, the 4.1BSD version of PCC. It is not, however, as good as BLISS. The original BLISS-11 generates positvely amazing code. It is interesting to note that this is not necessarily relevant. I have seen at least one case where the VMS compiler generated a code sequence almost 70% shorter (instruction count) than the 4.1 compiler for a critical C function, but the code didn't run any faster due to the VAX's slowness with it's more complicated instruction forms. More global optimizations would, of course, likely have a more noticable effect. -------
ron%brl-vgr@sri-unix.UUCP (10/20/83)
From: Ron Natalie <ron@brl-vgr> Goto's are not unrestriced in C. But the case for using them 99% of the time is to save code space. You are therefore specifically overriding any code optimizations time wise that good be made. Mostly, I don't see any proof (and I doubt it can be proven) that there is any reason why C has to produce worse code than bliss. You may also note that in many instances the F4P compiler on the PDP-11's produced "better" code than an equivelent piece of C output from the original version 6 compiler. -Ron
tjt@kobold.UUCP (T.J.Teixeira) (10/22/83)
On BLISS vs. C:
Now wait a cotton picken minute. How can you say that BLISS produces
better code than C. That is an entierely implementation dependant
thing contingient on what machine you are running on, which version of
the compiler you are using and what level of optimization you are
asking it to do.
-Ron
Fundamental characteristics of the language have an effect, too. The
presence of unrestricted GOTO's in C makes it *much* harder to
implement a really good (read "globally optimizing") C compiler than
an equivalent BLISS compiler. That's one of the main reasons BLISS
left them out.
John T. Wroclawski <JTW@mit-xx>:
Once the compiler is written, I don't care if it was easy to implement
or hard to implement. There is nothing in the C language that
*prevents* me from writing a compiler as good as the VAX/VMS Bliss
compiler.
--
Tom Teixeira, Massachusetts Computer Corporation. Littleton MA
...!{harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 486-9581alan@apollo.UUCP (Alan Lehotsky) (10/25/83)
I've decided to step into the BLISS vs. C battle -
as an (obviously) unbiased participant. To pour
some volatile liquid on this fire, I make the following
assertions:
I. BLISS is a better systems-programming language
than C. The built-in features of the language
for dealing with
o bit-fields
o specific registers
o user-defined linkage conventions
o user-written accessing algorithms
(the STRUCTURE declaration)
o character sequence manipulation
o VOLATILE memory
are far superior to what C provides. Further,
the BLISS compile-time and macro-preprocessor
facilities are orders of magnitude more powerful
than what C gives you!
In BLISS, you can write an interrupt handler without
invoking ANY runtime support - the compiler emits the REI,
RTI, RTT or whatever and knows where the PC and PSL or PSW
are on the stack, etc...
II. The implementations of BLISS for the VAX, PDP11 and
PDP-10 are FAR superior to any C compiler which I
am aware of (for the same hardware). On the average,
I would estimate that BLISS produces code which is
about 75% the size of code produced by the VAX/VMS
C compiler - without the BLISS programmer attempting
extensive optimization by doing any register declarations
or special linkages!
III. With regard to the statement
> There is nothing in the C language that
> *prevents* me from writing a compiler as good as the VAX/VMS Bliss
> compiler.
> --
> Tom Teixeira, Massachusetts Computer Corporation. Littleton MA
This is probably almost true. But, it turns out that if you consider the
effort required, you will discover that it is easier to do a BLISS
compiler than the correspondingly high quality C compiler.
IV. C does have a few minor advantages:
o Weak typing is convenient sometimes.
o A lot of programmers know C, very few programmers know
BLISS.
Now to really make your blood boil.....
C would be the TECO of programming languages, if TECO wasn't
already the TECO of programming languages.
BLISS is a language designed for optimizing compilers, while C is
a language designed for optimizing programmers.
Blissfully yours,
Alan Lehotsky (formerly BLISS Project Leader @DEC 1977-1983)
The following limerick may amuse you all...
A languages wizard named Al,
Found BLISS working at DIGIT-al.
Though he coded and taught,
and defends the damned dot;
At Apollo, he's using PASCAL.mat@hou5d.UUCP (10/26/83)
Well, I will allow myself ONE public reply in this arena ... and anything further that I have to say will go to net.flame. THE PROBLEM WITH ANY LANGUAGE THAT TRIES TO BE VERY GOOD ON * O N E * MACHINE IS THAT IT WILL INEVITABLY BE WORSE (OR UNUSABLE) ON OTHERS. C just barely avoided that trap. I believe that Bliss qualifies ... although it is nowhere as bad as some ``systems programming languages'' that I have seen. Most of THOSE were written by Hardware Jocks. What is a hardware jock? Manager: H J has just pointed out that if we replace the model xxxyyy processor made by Mungotronics with the bbmm that Standard Semi makes, we can knock 5% off the cost of That Board. (``That Board'' represents 1/12 of the cost of the product. The Standard Semi processor uses a 9 register general purpose architecture for which approximately 40,000 lines of code have been written and debugged and documented. The Mungotronics machine is a stack machine with one index register that must be loaded a byte at a time, and no multiply or divide instructions. It is also 35% slower than the Standard Semi chip and one of That Board's functions is communications.) Programmer: We can't do that! The processors are totally incompatible! Hardware Jock: What do you mean, incompatible! They're both NMOS!? Hardware Jocks write a lot of ``systems programming languages''. They often call them ``Systems Programming Language'' or some such drivel. Real Hardware Men ask BEFORE they build. Brassboards mean never having to say you're sorry! Mark Terribile DOdN
tjt@kobold.UUCP (T.J.Teixeira) (10/26/83)
apollo!alan makes the following claims in support of BLISS:
I. BLISS is a better systems-programming language
than C. The built-in features of the language
for dealing with
o bit-fields
o specific registers
o user-defined linkage conventions
o user-written accessing algorithms
(the STRUCTURE declaration)
o character sequence manipulation
o VOLATILE memory
are far superior to what C provides. Further,
the BLISS compile-time and macro-preprocessor
facilities are orders of magnitude more powerful
than what C gives you!
In BLISS, you can write an interrupt handler without
invoking ANY runtime support - the compiler emits the REI,
RTI, RTT or whatever and knows where the PC and PSL or PSW
are on the stack, etc...
First, a disclaimer: my knowledge of Bliss is confined to the examples
and definitions in "The Design of an Optimizing Compiler" by W. Wulf et
alia, along with glancing at bits of Bliss code used as part of the NIL
Lisp system at MIT.
Be that as it may, in rebuttal:
o bit-fields
True, bit-fields are more pervasive in Bliss than in C. Also, I
believe that C botched bit fields by not specifying the semantics of
bit fields declarations more precisely. As it is, bit fields are not
useful for specifying the precise layout of external bit fields (i.e.
as interpreted by some external hardware) in a machine independent way.
They are also not usable for defining binary data structures in a
portable and machine independent way, even for communication between
consenting C programs.
However, within reasonable limits (i.e. similar word-sizes) you can
achieve what is required using machine dependent declarations. I don't
believe that Bliss is able to magically solve the problem of converting
binary files from a 36-bit machine (e.g. PDP-10) to an 8-bit byte
machine (e.g. VAX or PDP-11) either.
It might be nice to just declare automatic variables as bit-fields
without having to dummy up a structure to contain it. This deficiency
can be overcome using #define's, but this is not a satisfactory
solution since #define's don't obey the same scope rules as variable
declarations.
o specific registers
o user-defined linkage conventions
I can see no use for these except to accomodate calling conventions of
pre-existing assembly language programs and/or to exploit glitches in
hardware architecture. Granted, Bliss may be a better language for a
VAX (I can specify that the foo routine is invoked with a jsb instead
of a call instruction), or a PDP-10 (lot's of possibilities for
subroutine linkages here).
o user-written accessing algorithms
This is a good thing, but is very easily abused. I will elaborate more
on the nature of this abuse later.
o character sequence manipulation
What can I say? Functions can get the job done, but would require a
very sophisticated compiler indeed in order to produce the same code on
a machine which actually supports character string operations.
o VOLATILE memory
Steve Glaser at Tektronix also pointed this out to me by mail.
You obviously need some sort of declaration like this if you don't want
to hamstring your optimizer. I'm not sure how it's implemented in
Bliss. The problem is that this is really is run-time limitation based
on the actual addresses accessed, but would have to be declared
statically at runtime. e.g. all data accessed through a given pointer
is volatile. Alternatively, one could tag entire structure's,
individual structure elements or variables to be volatile (the latter
two would be necessary to accomodate shared memory communication).
As it is, C can only safely consider parameters and automatic variables
to be non-volatile. There exists compiler options to allow more scope
for an optimizer, but there should be a way of declaring this in the
language.
o Further, the BLISS compile-time and macro-preprocessor
facilities are orders of magnitude more powerful
than what C gives you!
True, but C already gives you a dangerous amount! The problem with
extensive pre-processing is that the lexical appearance of the source
code no longer gives you enough information about the semantics of the
program.
For example, in most contexts in C, a name refers to a variable.
Exceptions to this are names following "." or "->" (structure elements)
or preceeding "(" (function names). This isn't complete information
since the storage class (static, automatic, parameter) is not directly
deducible from the name, nor is the type.
However, using the preprocessor, a name could be *anything*: a
constant, a keyword, punctuation, an entire expression (possibly
including free variables or side-effects). Yes, you can do *amazing*
things with the C preprocessor (look at the source code for the Bourne
shell or adb, or "Modular C", Stowe Boyd, SIGPLAN Vol 18 No 4). It may
look alot like C, but it's different enough to be considered a
different language.
To combat this, most C programmers use the convention of #define'ing
constants using UPPER CASE names, and making sure that #define'd macros
with parameters behave like a function call. If you want to extend the
compile-time facilities, I would prefer an approach similar to PL/1
that makes it explicit what is happening at compile time and what is
happening at run-time. If you want to extend the language, write a
pre-processor: don't kid yourself by hacking around with arcane macros
and call the result C.
o In BLISS, you can write an interrupt handler without
invoking ANY runtime support - the compiler emits the REI,
RTI, RTT or whatever and knows where the PC and PSL or PSW
are on the stack, etc...
So what? My unix system has over 600 functions in the kernel. Maybe
10 of them are interrupt handlers.
o C would be the TECO of programming languages, if TECO wasn't
already the TECO of programming languages.
Well, TECO may suffer from having many primitives that are a bit too
primitive (i.e. nearly useless by themselves), but it does have
powerful ways of combining this primitives to get something done.
However, this leads to the problem of encouraging (practically
requiring) the user to write TECO macros to get interesting things done.
Taken to its extreme (EMACS), you have a very powerful system hiding in
a ball of mud.
Yes, I like EMACS (I'm using now and it has been my editor of choice
for years). However, what I like is *my* EMACS: anyone elses is almost
certainly different, primarily because EMACS makes it so easy to
customize.
All this sounds more like BLISS and C to me: the BLISS programs I have
seen rely heavily on macros and other compile-time facilities
(including user-written accessing algorithms). This is fine for a text
editor, because I never have to use *your* EMACS. However, before
someone else can understand *your* BLISS program, they not only have to
know BLISS, they have to know *your* BLISS macros and coding styles to
a much larger than someone has to know *your* C macros and coding
styles.
Note that the hazards of letting programmers get their hands on too
powerful a macro facility has been observed in other application
domains: consider nroff/troff as opposed to Scribe. An explicit design
goal for Scribe was to not let the hackers have macros so that Scribe
could remain a document description language rather than a programming
language for putting dots on a laser printer.
Constructive Suggestions for Enhancements to C
The C "class" pre-processor ("Classes: An Abstract Data Type Facility
for the C Language", Bjarne Stroustrup, SIGPLAN Vol 17 No 1) is what I
feel to be a better approach than undisciplined (or even disciplined!)
use of macro preprocessors to fix up C. For that matter, I don't have
many objections to ADA, as long as I can use the base language and
don't have to drag along all the "standard" packages being dreamed up
for the ADA programming environment.
More particularly, the "class" processor gives a direct way of
declaring functions that should be expanded inline. This enforces my
expectation that "foo(bar)" in my program will behave *semantically*
like a function call and is *not* going to insert a bunch of closing
brackets or semi-colons.
Classes also provide a mechanism for solving some of C other ills (i.e.
lack of a complex data type), but not all (passing variable size two
dimensional arrays would still be a problem).
I think C would also be helped by integrating an exception handling
mechanism (a la CLU) into the language.
--
Tom Teixeira, Massachusetts Computer Corporation. Littleton MA
...!{harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 486-9581jhf@lanl-a.UUCP (10/27/83)
> Alan Lehotsky (formerly BLISS Project Leader @DEC 1977-1983): > > Now to really make your blood boil..... > > C would be the TECO of programming languages, if TECO wasn't > already the TECO of programming languages. It does make my blood boil, but not for the reason you think. That should be if TECO w e r e n ' t already Joe Fasel Los Alamos National Laboratory jhf@LANL pur-ee!purdue!lanl-a!jhf
alan@apollo.UUCP (Alan Lehotsky) (11/03/83)
BLISS and REGISTERs
First of all, any LOCAL is a candidate to be in a
register - and the compilers pack the declared
variables, based on their life-times. If you want
to force something to memory, declare it as
STACKLOCAL.
Second, you can say
REGISTER foobar; ! Compiler picks one
REGISTER mychoice=5; ! Picks R5 - This isn't portable
BUILTIN R5; ! Equivalent to REGISTER R5=5;
If you compile with portability checking turned on,
the last two are diagnosed as suspicious.andree@uokvax.UUCP (11/09/83)
#R:mi-cec:-16600:uokvax:6200002:000:539 uokvax!andree Oct 30 18:47:00 1983 I don't know enough (if anything) about BLISS to comment on Al's points about BLISS vs. C. I do have one question, though: Doesn't BLISS allow (force?) you to refer to registers by name? If so, what happens to code when you move it from machine to machine? Will it still compile as is? Since C doesn't let you refer to registers by name, the compiler can (and will) ignore register declarations when it doesn't have the registers. Of course, C more than makes up for this in other portability areas. How does BLISS do in those? <mike