Register functions ?
Kevin Martin
> propose "register" functions like these:
>
> static register int func (arg, arg2) {...}
> static register void func ....
>
> The purpose of the "register" (even for void !) is to prevent the
> programmer from taking the address of the function.
> teltone!warren
I have had some thoughts about 'register' too. I see it as being a storage
class modifier which tells the compiler that the value will not be changed in
any 'sneaky' manner.
If you think about it, this is its current meaning.
For extern's, it becomes a promise that the named variable will not be changed
by any functions I call.
For functions it means it returns the same value if called with the
same args, and has no side effects.
One problem with this extension is that the compiler cannot enforce
your promises in the same manner as it prevents sneak access to auto
register variables (by preventing you from &'ing them).
The other problem is due to interpreting 'register' as part of the
storage class... What if I want a pointer to a "register function"?
There is no syntax that fits... The only possible syntax is already used up
by "register pointer" to "regular function"...
Kevin Martin, UofW Software Development Group
jej...@ea.uucp
ea!jejones Sep 5 13:38:00 1984
Well put. I have often wondered why one couldn't declare externals to
be register variables...
James Jones
t...@callan.uucp
register foo() {
should mean that foo is a small function that should move itself
into the registers for speed! ( on the 10, the registers were
mapped into the lower 16 words of your address space. Thus,
it was both reasonable to take the address of a register variable,
and it was reasonable to put code in the registers, because it
would run faster there.)
--
Tim Smith
ihnp4!wlbr!callan!tim or ihnp4!cithep!tim
Tom Haapanen [DCS]
register foo() { ...
makes a lot of sense. The 68020 has a 64-longword on-chip instruction
cache, and this instruction could be used to force a small function
into the cache *and keeping it there*. I am not certain of the exact
cache locking mechanism used (but I know there is one!), since a
friend just borrowed my MC68020 manual...
Naturally you couldn't do that to large functions, but it could make
small ones execute like a bat out of h*ll! (especiall with the 68020
having clock speeds of up to 16.67 MHz...)
Tom Haapanen
{allegra,clyde,decvax,ihnp4,utzoo}!watmath!watdcsu!haapanen
j...@uokvax.uucp
C would benefit from a new storage class, I hereby dub "private".
Private storage items, whether const or variable, would be not
exportable. The "private" declaration is intended to get around
the "aliasing" problem in C, where two expressions (say, "x" and
"*y") cannot be assumed to point at different objects (they could
both point to the same place). If x is declared "private", then
y must point somewhere else.
/* ---------- */
"must point somewhere else"?
The idea of a "PRIVATE/LOCAL" variable is nifty, and gets rid of
many "aliasing" problems, I'm sure. In a language such as "C", in
which a pointer can contain ANY valid address (where "valid" refers
to "hardware address space" and not "external variable") you
won't get what you really want.
I suspect that the way to get that might be to change a pointer to be type-
specific, and for locations to contain "datum" and "type information on that
datum", with checks performed by the hardware. Anyone want to venture to guess
what the overhead would be?
Jeff Bowles
Lisle, IL
John Gilmore
was talking about other-machine emulators. I once wrote the basic structure
of a program that would emulate the IBM 370 on a 68000 -- the slowdown
was about 20:1 (i.e. it took 20 68000 instructions to fetch, decode, and
execute the average 370 instruction). If you could freeze the inner loop
of this into the 68020 cache you might get a much better performance ratio.
Kinda like 1401 emulator mode on 370's, those dinosaurs just won't die.
If anybody wants a copy of the 3-page very rough paper on the 370 emulator,
send me mail.
Guy Harris
>
> register foo() { ...
>
> makes a lot of sense. The 68020 has a 64-longword on-chip instruction
> cache, and this instruction could be used to force a small function
> into the cache *and keeping it there*. I am not certain of the exact
> cache locking mechanism used (but I know there is one!), since a
> friend just borrowed my MC68020 manual...
Acccording to Section 7, "On-Chip Cache Memory", of the 68020 manual,
you can turn on the "freeze cache" bit in the Cache Control Register
with the MOVEC (Move Control) instruction; however, only system code
can do that on a system which has supervisor and user states because
the instruction is privileged. They say that "This bit (the Freeze
Cache bit) can be used by emulators to freeze the cache during
emulation function execution"; I think they are referring to code that
handles the "line F" coprocessor instructions in software.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
Jan Gray
virtual machine bytecode decoder.
Thinking about both,
Jan Gray (jsg...@watmath.UUCP) University of Waterloo (519) 885-1211 x3870
Guy Harris
> many "aliasing" problems, I'm sure. In a language such as "C", in
> which a pointer can contain ANY valid address (where "valid" refers
> to "hardware address space" and not "external variable") you
> won't get what you really want.
"private", in this case, would be a committment by the programmer not to
take the address of that variable. It wouldn't be enforcable, but I
don't see that as a disadvantage, any more than I would see the fact that
just because a variable is not declared "volatile" (in the proposed ANSI
standard, it means "this variable can be asynchronously modified by
something other than this process", thus disabling some optimizations)
doesn't guarantee that it's not going to be changed by another process or
a device.
Yes, you could have a pointer pointing to a "private" variable; however,
if the program does so, either it was not written to do so, in which case
it has a bug, or it was written to do so, in which case if it doesn't have
a bug there'd better be a very good reason why it isn't a bug.
The fact that C is an "unsafe" language shouldn't prevent optimizing
compilers being written for it. It merely means that just because a
program passes the compiler doesn't mean it's a valid program - but that's
been the tradition anyway, considering
foo(s)
char *s;
{
...
}
bar()
{
foo(73);
}
is an invalid program, but lots and lots of compilers out there won't
complain. Just because "lint" can catch this one, but not the case of
a variable mis-declared "private" or a volatile variable not so declared,
doesn't render those language enhancements useless.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy