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]

Ancient_Hacker wrote:

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 :)

--
Ian Collins.

[Richard Tobin]

In article <11************ **********@b28g 2000cwb.googleg roups.com>,
Ancient_Hacker <gr**@comcast.n etwrote:

>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
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Jordan Abel]

2006-11-02 <ei***********@ pc-news.cogsci.ed. ac.uk>,
Richard Tobin wrote:

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]

In article <sl************ *******@rlaptop .random.yi.org> ,
Jordan Abel <ra*******@gmai l.comwrote:

>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.s...8b87a6590ffa44

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[CBFalconer]

Richard Tobin wrote:

Ancient_Hacker <gr**@comcast.n etwrote:

>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.)

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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Richard Bos]

ri*****@cogsci. ed.ac.uk (Richard Tobin) wrote:

In article <11************ **********@b28g 2000cwb.googleg roups.com>,
Ancient_Hacker <gr**@comcast.n etwrote:

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.)

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

Richard

[Chris Torek]

In article <11************ **********@b28g 2000cwb.googleg roups.com>
Ancient_Hacker <gr**@comcast.n etwrote:

>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) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.