tanner@ki4pv.uucp (Dr. T. Andrews) (06/22/88)
In article <8130@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
) ... There was so much public objection to [unary plus], and so much
) clamor for parentheses forcing order of evaluation, ....
) parentheses order forcing was adopted instead.
While the unary plus was something of a stomach-turner, it seems that
the C group got confused into thinking it was the fortran group. Would
it not have been better to codify the existing practice of stuffing
results into a variable named "tmp" if evaluation order was incredibly
important?
That's how users of "existing technology" compilers do it. A clever
"-O" option might come by and eliminate the actual store to "tmp" if
it wasn't used later, but (considering the "as if actually done"
rule) couldn't re-arrange the expression further if it would be
unsafe.
It is probably a good idea for code which really cares to continue to
stuff the intermediate results into "tmp" for some years, until X3J11
compilers become moderately universal.
--
rutgers!bpa!cdin-1!cdis-1!ki4pv!tanner (better than it looks!)
or... {allegra codas killer decvax!ucf-cs}!ki4pv!tannereric@nova.laic.uucp (Eric A. Raymond) (06/24/88)
In article <6958@ki4pv.uucp>, tanner@ki4pv.uucp (Dr. T. Andrews) writes: > While the unary plus was something of a stomach-turner .... Come on people. Haven't we learned anything yet about semantics of programming languages. If you want to enforce the sequential nature of a set of constructs, use an explicit operator (i.e. sequential-eval) to denote that. Don't rely upon some side-effect of another operator with different semantics. (I always thought '+' meant plus.) Maybe a leeson can be learned from Lisp world, where we have sequential and parallel forms of binding (i.e. let* .vs. let). (And by the way, Lisp enforces left to right eval of function arguments. So flame on something else, if you please.) Eric A. Raymond - ...ucbvax!sun!sunncal!leadsv!laic!eric
smryan@garth.UUCP (Steven Ryan) (06/25/88)
>That's how users of "existing technology" compilers do it. A clever >"-O" option might come by and eliminate the actual store to "tmp" if >it wasn't used later, but (considering the "as if actually done" >rule) couldn't re-arrange the expression further if it would be >unsafe. This issue is messier than it appears on the surface. In doing common subexpression a compiler may skip over the store and replace tmp with the right hand side. Parenthesised are used to override precedence as well to indicate associating. Some compilers will ignore the parenthesis and reassociate the expression as the see best (keep those pipes busy). In some case the users expect the compiler to recognise tmp is just a shorthand for a longer expression and expect the compiler to use the right hand side. (In some (fortran) loops, the subscript expression is computed in a separate assignment with the same loop, and then used as a subscript. A vectoriser which can't patch this up is a walking wounded.) It would preferable to use some kind special bracket or special operator form in order to tell the compiler don't-you-dare-touch-this.
anw@nott-cs.UUCP (06/29/88)
In article <796@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes: >> [ stuff about re-arranging expressions ] > This issue is messier than it appears on the surface. [ more ideas etc ] It's even messier than this, and getting messier as time goes on. Over in "comp.arch", they're talking about optimising assemblers. We now have *at least* four places where expressions may be optimised -- in the compiler, in the intermediate code (in systems such as the Amsterdam Compiler Kit), in intelligent linkers, and in the assembler (presumably before *and/or* after linking, depending on how compiled modules are stored). I suppose that even optimising loaders are not a totally stupid idea [I don't mean intelligent pre-paging, more a loader that says, "Hey, the cache has just been expanded, so that load should be moved to *here*, and yesterday's benchmark shows that the FP multiply is faster than we thought, so *that* NOP can be deleted", etc.]. *Each* of these stages (some of which "cc" *ought* not to know anything about in most Unix-like systems) *may* now need special directives to say "Don't mess with this, or it may overflow/alias/volatilate [:-)] in ways you can't be expected to understand". This is not easy when the compiler may (well) have no idea what the target system is. Bring back the good old days, when C was defined by what happened using DMR's compiler on DMR's computer! :-) -- Andy Walker, Maths Dept., Nott'm Univ., UK anw@maths.nott.ac.uk