[comp.lang.c] Order of registers

braner@batcomputer.UUCP (02/17/87)

In article <4141@utcsri.UUCP> flaps@utcsri.UUCP (Alan J Rosenthal) writes:

>	f(nformal)
>	int nformal;
>	{
>		register int i,n = nformal;

>, which is often recommended, wastes an int on all machines.

"Wastes an int"???  - nformal is on the stack anyway, so if you use
"register" before the '{' the compiler copies it to a register.
Therefore the code above is IDENTICAL in effect - but leaves the
ORDER of "register" assignments up to the programmer.

I support the K&R method of the compiler following the programmer's
order until registers are used up.  After all, C is supposed to give
the programmer as much control of the machine as possible.

- Moshe Braner

chris@mimsy.UUCP (02/18/87)

>In article <4141@utcsri.UUCP> flaps@utcsri.UUCP (Alan J Rosenthal) writes:
>>	f(nf) int nformal; { register int n = nformal;
>>, which is often recommended, wastes an int on all machines.

Not all!

In article <195@batcomputer.tn.cornell.edu>
braner@batcomputer.tn.cornell.edu (braner) writes:
>"Wastes an int"???  - nformal is on the stack anyway,

Is it?  (Have a care with that answer!  Try some different compilers
on some different architectures.)

>I support the K&R method of the compiler following the programmer's
>order until registers are used up.  After all, C is supposed to give
>the programmer as much control of the machine as possible.

I would not put it that way.  Say rather that C is not supposed to
obstruct control of the machine.  On conventional (PDP-like)
machines, with conventional (straightforward, unoptimising) compilers,
this does seem to be the best thing to do with `register' declarations.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

m5d@bobkat.UUCP (02/18/87)

In article <5485@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <195@batcomputer.tn.cornell.edu>
>braner@batcomputer.tn.cornell.edu (braner) writes:
>>"Wastes an int"???  - nformal is on the stack anyway,
>
>Is it?  (Have a care with that answer!  Try some different compilers
>on some different architectures.)
>	[ ... ]
>-- 
>In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
>UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

Does this imply that some compilers notice the "register" declaration
and pass the argument in a register?  Seems to me this only could be
done for "static" functions.

Hmmmm....

Well, I've thought about it and I can't think of any reason it woudln't
work.  That could save a lot of time, but the nastiness of
implementation makes my left hemisphere hurt.

If you have something else in mind Chris, I'd like to hear it.  Clever
code generation tricks makes for great party conversation.

-- 
Mike McNally, mercifully employed at Digital Lynx ---
    Where Plano Road the Mighty Flood of Forest Lane doth meet,
    And Garland fair, whose perfumed air flows soft about my feet...
uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474

chris@mimsy.UUCP (02/19/87)

In article <594@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally) writes:
>Does this imply that some compilers notice the "register" declaration
[of a formal argument]
>and pass the argument in a register?  Seems to me this only could be
>done for "static" functions.

That is one possibility.  Another is that arguments are always
passed in registers, as on register window architectures.

>Clever code generation tricks makes for great party conversation.

Actually, that depends on the party. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

guy@gorodish.UUCP (02/19/87)

>Does this imply that some compilers notice the "register" declaration
>and pass the argument in a register?  Seems to me this only could be
>done for "static" functions.

Or for other functions, in ANSI C.  If you use "register" in the
declaration of the parameter, and if the function *definition* used a
function prototype-style declaration using "register, the compiler
could decide to pass it in a register.  (If the function definition
uses the old-style declaration, it wouldn't be able to do this,
because it would break old programs.)  Thus

	extern int foo(register int i);

in an #include file or a module containing code using "foo", and

	int
	foo(register int i)
	{
		...
	}

as the definition of "foo" could cause "i" to be passed in a
register.  However, the old-style

	extern int foo();

in the #include file or module using "foo", and

	int
	foo(i)
		register int i;
	{
		...
	}

as the definition of "foo" would probably not be able to, in most
implementations.

Of course, mixing the two would cause no end of headaches, but then
you *are* including the header file that declares "foo" in the module
that defines "foo", so that type clashes between the declaration and
definition will be caught, aren't you?

Note that some implementations, e.g. those on register-window
machines, may pass some parameters in registers regardless of the
declaration.