Register functions ?

[warren]

	As the recent originator of the topic of "Register Functions",
	I would like to mention that executing code in registers was not
	what I meant.  I am not opposed to it, I just meant something else.

	Let me cast the idea in clearer form:

	C would benefit from a new storage class, I hereby dub "private".
	Private storage items, whether const or variable, would be not
	exportable.  It would be impermissable to take the address, declare
	as external, or otherwise export a private item.  One clear win
	is the "private function", which in this case means VERY STATIC.

	The privacy of an item means the optimizer in the compiler can take
	further liberties, for example, generating whatever form of function
	call it deems useful, short calls, inline functions (lets say an
	ordinary (outline ?) function is called exactly once -- which happens),
	and so forth.   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.

	Note that the compiler is free to treat the "private" declaration as
	a comment, merely declining to optimize.

	Private variables could not be modified by a call to an external function,
	because its address could not be passed, even passing a pointer to a
	pointer to it (the private variable) would not happen, because its 
	address is "secret".  This means that if its value was in a register
	that is protected by function calls then its also valid there afterwards.
	Whereas today, a called function could have received the address of a
	static variable on a previous call, kept it, and then, as a "side
	effect",  modified it on the latest call.  The value in the register
	is then corrupted.

	------------------------------------------------------------------------

	Related but different topic -- varargs.

	A major advantage of making a varargs scheme part of the LANGUAGE
	is that the compiler could KNOW that other functions were not
	varargs, and could generate tighter code.  If you declare it
	wrong (e.g. "extern printf" instead of "extern varargs printf" then
	its your funeral, which is true already.  Note also that the compiler
	is free to treat the "varargs" declaration as yet another comment,
	perhaps by building into the preprocesor "#define varargs <newline>",
	and so forth.

	On architectures where no such scheme is possible, most systems 
	written in C would simply fail anyway.  On any architecture, the
	implementation of varargs must be taken into account by the
	compiler writers, in order generate function calls.  It seems
	only fair to the compiler writers to give them full control of
	varargs, relieving them of the burden of writing a compiler that
	has to be compatible with a varargs package written by somebody else,
	someplace else, in the future !  If varargs can't be implemented by
	the compiler writer, chances are nobody else can either...

	On systems where only a half-hearted varargs can be built, and where
	the coder of printf, say, has to explicitly hack in argument counting
	or something, the compiler writers can still sneak in an extra
	argument (argc) to help the coder (but only if users declare it
	as varargs - which they can suppress with a #define - even if
	its a reserved word).  Making varargs part of the language costs
	us little, and offers clear benefits.  

				teltone!warren