preece@ccvaxa.UUCP (02/26/87)
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". (Flame > on:) How can it possibly be a legitimate result??? It changes if you go > to a faster processor!!! (Otherwise why would you get a faster > processor???) Which one of us is crazy??? (Flame off.) ---------- I guess you've never written code that had to do time-dependent things on a system that didn't have a sleep call. There are environments in which code is written that is processor specific: change to a faster processor and you have to change the timing constants (lengthen buzz loops). For such code "portability" means exposing the constants so that they can be easily changed to match new hardware. ---------- > The choice of internal representation of a quantity should be entirely > up to the compiler. Thus, whether a number is normalized or > unnormalized (or represented as strings of ASCII characters) is > something that the programmer should (a) have no control over, and (b) > have no concern with. (Other than I/O to/from other subsystems.) ---------- 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. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms
drw@cullvax.UUCP (03/11/87)
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