Report from a novice VM h4x0r.

Richard A. O'Keefe ok at cs.otago.ac.nz
Thu Apr 1 02:51:52 UTC 2004


Alan Grimes <alangrimes at starpower.net> wrote:
	Also, the C compiler does not 
	follow the C idiom of making all constants ALLCAPS.
	
Since the C code is the moral equivalent of assembly code,
and since said idiom is more honoured in the breach than the
observance (and was a bad idea in the first place), why care?

	4. A great many computations involve extracting bit-fields. In many 
	cases these bit fields include important scalar information such as 
	"sizeBits". A useful improvment would be to make these either bytes or 
	short-ints and then let the C compiler figure out how best to extract 
	them from the words...
	
Years ago I had my fingers burned with C bitfields to the point where
I *never* use them.  If the compiler optimises, code that does explicit
shifts and masks will be quite as efficient as bitfields.  if it doesn't,
you have worse things to worry about.  Bitfields are a portability
minefield, even between compilers on the same machine, even sometimes
between different options for the *same* compiler on the same machine.

	16. C99 adds block contexts.

Eh?  C99 has exactly the same "blocks" as C89; the only change is that
array sizes can be dynamic expressions, not just constant expressions.

	The current cCompiler will take all inlined methods as well as
	loop variables and put them at the beginning of the generated
	function.  Since any current C and even older C++ compilers will
	support for (int i; i < x ; i ++ ), it would be much better form
	to use this instead of heaping all variables at the beginning of
	the block.
	
Oh, you mean NON-block declarations.  There is absolutely no point in
worrying about this one.  I've seen a Scheme compiler which generated
a separate variable for each subexpression in a function, so that some
of the generated C had hundreds of variables.  Any C compiler worth
having these days will do lifetime analysis.  Declarations in loop
headers are nice for programmers, but
	for (int i; i < x; i++) ---stmt---
doesn't do anything that
	{int i; for (i = 0; i < x; i++) ---stmt---}
doesn't do (except, of course, for using an uninitialised variable. (:-))
With an optimising compiler, putting the variable at the function-level
block doesn't make any difference; what matters is where it is mentioned.




More information about the Squeak-dev mailing list