[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