[MLton-devel] cvs commit: removed __asm__ for Int_quot and Int_rem

Stephen Weeks MLton@mlton.org
Thu, 7 Nov 2002 14:32:00 -0800


> Note, the right-shift of signed objects in C is NOT guaranteed to sign-extend.
> That was the reason for the asm before. 

We weren't using the asm and it was causing problems for Brad, so I
removed it.  We were (and are) using a macro in ccodegen.h, which has
the following comment.

/* The macro for Word32_arshift isn't ANSI C, because ANSI doesn't guarantee 
 * sign extension.  We use it anyway cause it always seems to work.
 * We do it because using a procedure call slows down IntInf by a factor of 2.
 */
#define Word32_arshift(w, s) ((int)(w) >> (s))

So, the difference between quot/rem and arshift is that gcc's
optimizer occasionally screws us with quot/rem but never has with
arshift.  Definitely scary, but arshift is an essential part of
IntInf, since it is used to strip the tag off of small integers.
 
I see the following options for implementing Word32.~>> for the C
codegen.

1. Use a procedure call.
2. Use a macro.
3. A hybrid of 1 and 2 where we use a macro only for IntInf.stripTag,
	but use the procedure everywhere else. 
4. Use static inline + asm.
5. Implement sign extension partially in the basis library, using an
	if-test that expands to the macro if the high bit is unset and 
	to the procedure call if the high bit is set.

1 is bad because of a big performance hit
2 and 3 suffer from the problem of hard-to-find bugs in the future
4 suffers from the complexity and lack-of-portability of __asm__, the
	fact that it is a moving target, and that I generally don't
	trust it (from a correctness perspective).
5 may suffer from a performance hit

Opinions as to the lesser of five evils?

Now that I mention them all, 5 doesn't sound so bad.




-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel