Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!necntc!cullvax!drw
From: drw@cullvax.UUCP
Newsgroups: comp.lang.c
Subject: short circuit evaluation - some com
Message-ID: <901@cullvax.UUCP>
Date: Wed, 11-Mar-87 14:08:56 EST
Article-I.D.: cullvax.901
Posted: Wed Mar 11 14:08:56 1987
Date-Received: Thu, 12-Mar-87 20:19:41 EST
Organization: Cullinet Software, Inc., Westwood, MA
Lines: 56

preece@ccvaxa.UUCP writes:
>   drw@cullvax.UUCP:
> > As far as run-time, it is not a legitimate result because the standards
> > (implicitly) state that run-time is "implementation defined".

> I guess you've never written code that had to do time-dependent
> things on a system that didn't have a sleep call.

No.  99% of what I have written has been for time-sharing systems,
where delay loops are considered anti-social.

> > The choice of internal representation of a quantity should be entirely
> > up to the compiler.

> I guess you've never written code that had to run fast or do careful
> things with numbers.  Consider, for instance, the arithmetic runtimes
> for a LISP system.  We have to have tight control over the hardware
> results of operations so that we can do appropriate mapping between
> hardware results and LISP-side reresentations of objects.  Many other
> users have similar problems.
> 
> We talk a lot about portability and cleanliness here, but there are
> a tremendous number of computer users who use the machines where
> very tight control of the hardware is the only way they can get their
> jobs done.  That doesn't mean we shouldn't strive to make portability
> problems visible or that code that doesn't have to have machine
> specificity shouldn't avoid it, but it does mean that pious
> generalizations about making the hardware invisible are somewhere
> between naive and insulting.

But conversely, pious generalizations that the compiled code should
resemble the 'obvious' implementation of the written statement are of no
use either.  The problem is that if you allow ordinary C code to
tightly control the hardware, then (1) the number of optimizations
that the compiler can do is reduced dramatically, and (2) cretins will
abuse this ability to write code which contains unnecessary hardware
dependencies.  [The reason that (1) is bad is that a good optimizing
compiler will write better machine code than most programmers.  The
reason that (2) is bad is that many of the original Unix utilities
assume that they can fetch through a NULL pointer.  Some of them even
assume that the result will be 0!  I have actually seen people argue
that all Unix kernels should guarantee that this abomination works!]

A third problem is that very often the exact hardware operation
desired may not be specifiable in C.

It is true that in specific places, the programmer should be able to
hook into the hardware more tightly than the ANSI standard allows.
But this should be activated by some specific mechanism, not by
burdening all programs with the limitations that this implies.

Dale
-- 
Dale Worley		Cullinet Software
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw
ARPA: cullvax!drw@eddie.mit.edu