Re: Public disclosure of discovered vulnerabilities

On Wed, 25 May 2005 03:31:15 +0000, Bryan Olson wrote:

> Andrew Reilly wrote:
> > Bryan Olson wrote:
> >> Back in the day, there were other reasons; chief
> >>among them, as we used to say, [C] combines the flexibility of
> >>assembly language with the power of assembly language.
> >
> > Not true: it has the (IMO huge) advantage over assembly language of
> > avoiding all of the tedious and error-prone manual register allocation
> > process.
>
> Don't forget C's "register" storage modifier. The old line was
> mostly supposed to be funny, but that's the kind of thing it was
> talking about.

Hmm. Yes, I'm familiar with the register modifier. It's fallen into
disuse because most of what it did can (and is) inferred by modern
compilers. I.e., which variables to put into registers, and when. I
actually had to do some significant work with a fairly old (pre ANSI) AT&T
C compiler that was probably quite close in spirit to what Kernighan and
Ritchie were thinking about when they designed the first version. It was
interesting because it would *only* assign variables into registers if the
"register" modifier was used. It would also complain (can't remember
whether it refused to produce code, I think that it did) if more
"register" modifiers were specified than there were free registers. Auto
variables that were not "registered" were operated on in-situ in the stack
frame (through some scratch registers that the compiler kept free for the
purpose.) Needless to say, judicious use of "register" was the only way
to get sensible (fast) code generated.

However that's not what I was thinking of when I wrote the sentence above.
For most of the code that I write (probably most code full-stop), which
variables should be in registers isn't that hard to figure out, and
judicious manual application of "register" isn't practically very
difficult. What I was thinking about is a much more pernicious problem,
when writing assembly language routines, and that's which specific
registers hold which values, at any given time. Throw in
non-unit instruction latencies, limited register sets and shuffling
instructions to get the best sequence, and it becomes a hairy,
crossword-like problem. Work that I'm more than happy to leave to the C
compiler.

So, I guess my point is: combining the flexibility of assembly language
with the power of assembly language, while still being usefully portable
across platforms, is actually a pretty useful feature set, if the only
reasonable alternative is actual assembly language.

-- 
Andrew