🚀 go-pugleaf

: From: mbk@lyapunov.ucsd.edu (Matt Kennel)
: Message-ID: <1efh6vINNm6c@network.ucsd.edu>
: The point, is, he [..Herman Rubin..]
: wants a high-level real language, with real optimizers,
: that nonetheless, does not consider hardware dependence to be anathema.

Except that when such capabilities are pointed out, he sneers at
them, and then asks for something else.  For example, gcc can generate
inline procedures with assembly instructions interspersed.  For pointing
this out, people get sneered at, and told that the notation isn't
simple enough.

When solutions to notation problems are presented, such as introducing
operators into gcc by the usual lex and yacc notations, or by
preprocessing with the TXL system mentioned by Matt a bit later, people
get sneered at, and told that specifying syntax in these ways is
too difficult.

So as near as I can see, solutions to the problems Herman Rubin
complains about are out there, and available for use now.  Herman Rubin
simply refuses to use them until they are customized for his needs to
an uneconomical extent.

The bottom line: Herman Rubin is attributing to malice and stupidity 
what is adequately explained by simple economics.

: So if C doesn't know how to do a fp divide with integer quotient and a
: remainder in one instruction, or how to do a "add in parallel, but
: only on those processors in this mask" (a CM),
: then no amount of higher-level rewriting will help.

Yes, this is the most central problem, which Jim Giles mentioned also.
Some method is needed which will specify the generated code, and yet
will fit in with the optimizations and register allocations and so on
which are already in place.  Jim says this "isn't too difficult", but 
I think it is the single most difficult part.  I've seen several
solutions, each with some advantages over the others.

But ultimately, when you are going after that last 1% or .1% of speed,
you will simply have to spell out the istream, operation by operation.
No amounts of hints to the optimizer will ever be enough, because
ultimately the optimizer can only deal with hints it is prepared to
accept, and if a programmer comes up with something unforseen by the
optimizer, there's no simple way to give a hint about it.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw