In article <11**********************@b28g2000cwb.googlegroups .com>
Ancient_Hacker <gr**@comcast.netwrote:
>In days of old, for no discernible reason, many CPU's had the ability
to execute one or more instructions out of registers. Not very common
today.
I can only think of two general examples (more on that in a moment).
>Which brings up a semi interesting point.
We know the "register" keyword suggests the compiler keep the
following variable in a register.
We also have the "inline" suggestion in C++ to suggest inlining a
function.
C99 has "inline" as well, with (I believe) somewhat different semantics.
>What if one could suggest: register int max(a,b) { return a>b?a:b }
... meaning "you might want to keep this function in registers"
of course the usual "register" and "inline" restrictions would apply--
you cant take the address of this function ...
In C89, of course, any legitimate use of a function identifier
winds up computing its address.[%] (If a C99 inline function is
actually expanded in line, it makes sense to talk about this as
*not* having "taken the address" of the function, since the code
that implements it has simply been inserted in line, as the keyword
itself suggests. In a sense, the *value* of the call has then been
recorded, instead of the call itself, even if/when that requires
a bunch of expanded-in-line computation.)
On the other hand, if one is writing a Standard, one simply (hah)
goes back and changes the language describing function calls to
make them not "find the pointer" first, at least for inline.
-----
[%] This is not unlike "register T arr[N];" in C89, except that
here, you can do "sizeof arr", making register arrays only *almost*
completely useless. :-)
-----
>Kinda weird for a function being "there" but not having an address.
Back to the two "general examples" ... the first is machines on
which registers have addresses. (PDP-10, TI-9900, possibly others;
I only know of actual "code in registers" instances for the first
though.) In this case, putting code in the registers still leaves
it with an address.
The other example is machines with an "execute indirect" instruction,
where one can, e.g., point a register at a memory location that
contains a single instruction, then use the "exec" instruction to
pull in that single instruction. Sometimes the "exec" instruction
will allow the instruction-to-execute to be in a register itself
(instead of pointed-to *by* a register). In this last case, the
target instruction does not have an address -- but in both cases,
the "function" is only a single instruction. In general, this is
not useful to C compilers, where functions (inline or not) often
need multiple instructions.
In any case, I think if one were designing a C-like language from
scratch, "inline" alone would suffice -- "register inline" is not
so useful after all. Indeed, I think I would rather just define
the language so that functions default to internal-linkage, and
can then easily be inlined during optimization, the same way modern
compilers largely ignore "register" declarations on automatic
variables and just assign registers as appropriate.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it
http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
