function without an address?

[Ancient_Hacker]

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.

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.

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 or pass it as a function
parameter. Plus the registers would be unavailable for any other use.

I guess all these hints are kinda obsolescent as the hardware guys are
always trying to find ways of giving us more speed, like adding a cache
so some variables have register-like speed, same for code cache so some
code executes like it was in registers.

Kinda weird for a function being "there" but not having an address.

 

[Ian Collins]

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.

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.

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 or pass it as a function
parameter. Plus the registers would be unavailable for any other use.

I guess all these hints are kinda obsolescent as the hardware guys are
always trying to find ways of giving us more speed, like adding a cache
so some variables have register-like speed, same for code cache so some
code executes like it was in registers.

You never know, these instructions (which CPUs by the way?) may already
be used by some cunning optimiser.

Kinda weird for a function being "there" but not having an address.

Well there are CPUs out there with addressable registers (8051 for
example) so if that set intersects with those with register
instructions, it might be possible

 

[Richard Tobin]

In days of old, for no discernible reason, many CPU's had the ability
to execute one or more instructions out of registers.

Often this didn't speed things up unless you'd paid extra for
semiconductor registers. (I used to have a PDP-10 price list with the
price for these, but I fear it was destroyed when most of our AI
department burnt down.)

-- Richard

 

[Jordan Abel]

Often this didn't speed things up unless you'd paid extra for
semiconductor registers. (I used to have a PDP-10 price list with the
price for these, but I fear it was destroyed when most of our AI
department burnt down.)

What were registers otherwise? surely not core memory?

 

[Richard Tobin]

What were registers otherwise? surely not core memory?

Yes.

Looking back at previous threads on this subject, I see that it may be
that DEC never actually shipped any of these machines without the
theoretically optional fast registers:

http://groups.google.com/group/alt....+fast-registers&rnum=1&hl=en#fa8b87a6590ffa44

-- Richard

 

[CBFalconer]

Often this didn't speed things up unless you'd paid extra for
semiconductor registers. (I used to have a PDP-10 price list
with the price for these, but I fear it was destroyed when most
of our AI department burnt down.)

That was the 'execute' instruction. Some machines could operate on
storage with it. HP3000 for one. It was in a register if on top
of stack.

 

[Richard Bos]

Often this didn't speed things up unless you'd paid extra for
semiconductor registers. (I used to have a PDP-10 price list with the
price for these, but I fear it was destroyed when most of our AI
department burnt down.)

Evidently Eliza acidentally loaded one of her registers with an HCF
instruction.

Richard

 

[Chris Torek]

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.