Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!security!genrad!decvax!tektronix!ogcvax!omsvax!hplabs!sri-unix!gwyn@brl-vld From: gwyn%brl-vld@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: From VMS to UNIX Message-ID: <12550@sri-arpa.UUCP> Date: Wed, 19-Oct-83 01:04:29 EDT Article-I.D.: sri-arpa.12550 Posted: Wed Oct 19 01:04:29 1983 Date-Received: Tue, 18-Oct-83 00:43:05 EDT Lines: 28 From: Doug Gwyn (VLD/VMB) 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!