Re: signature like constructions

[Simon Wright <simon@pushface.org>]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> My favorite example involved the LALR parser generator on Multics.
> Pat Prange was about to go through the gory effort to allow an array
> of Boolean data to span multiple segments.  I asked why he didn't
> use a packed representation, and he answered at length.  But once we
> got all the requirements written down, it turned out that the major
> operation on the array was a search in a particular row for the
> first set bit.  After another half hour of discussion Pat ran off to
> implement the new version.  To make a long story short, it used the
> translate and test instruction in the character string processing
> unit.  The single instruction generated used a 512-element table to
> look up the first non-zero (9-bit) byte detected, and of course the
> values in the table were the index of the first set bit.  Six lines
> of PL/I carefully written so the code generator would emit a single
> instruction!
> 
> The net result was to decrease the running time for the tool by over
> 90%, from just over 20 minutes to generate an optimized LALR1 parser
> for Ada, to just under two minutes.  But the point to take away is
> not that PL/I was great for this purpose, or Multics.  I could write
> the same code in COBOL for an IBM mainframe, or C for an x86 or
> 680x0 chip. (Or in Ada, or just about any language that let you get
> close to the metal when necessary.) The expertise required is in
> first figuring out the actual machine code you want generated, then
> knowing the compiler internals well enough to make it happen.

At some point you need (a) a machine-independent solution to the
problem, (b) a machine-dependent optimisation. Clearly it's good if
the machine-independent solution is also efficient, but it seems to me
like overkill to write 6 very clever lines in the hope that the
compiler (and future revisions) will always emit one machine code
instruction. Why not use an assembler insert?