On Tue, Jun 12, 2001 at 12:45:02PM -0400, Todd Vierling wrote:
	> On Tue, 12 Jun 2001, Manuel Bouyer wrote:
	> 
	> : > 	callout_reset(&scb->xs->xs_callout,
	> : > 	    (newtimeout > 3*1000*1000 ?
	> : > 		((newtimeout / 1000 + 1) * hz) : (newtimeout * hz) / 1000),
	> : > 	    ahc_timeout, scb);
	> 
	> : The question is whenever the test is really less expansive than the
	> : 64bit computation. I think on some platforms it may be more expensive.
	> 
	> Only on LP64 platforms, really (sparc64, alpha) -- and those could be
	> conditionally compiled to use solely 64-bit arithmetic.
	> 
	> The flip side is that a 64-bit "/ 1000" is a *lot* slower than its 32-bit
	> equivalent on ILP32 platforms, particularly those for which even integer
	> divide is a library function (sparc v7).

	Hum, yes I was only thinking about multiplication, no divide.

Since multiply and divide are often implemented to render 2-4 bits/cycle,
64-bit multiply/divide is often more expensive on 64-bit platforms too.

	Do we have a macro that could be tested to know whenever we're on a 32 or
	64bit platform ?

There has been a lot of argument aboout this but as yet no specific
macro has been decide upon.

Having said that, the comparison of an integer to a constant is fast,
predictable and can be done early.  And since timeouts that overflow
32-bits are rare, it would be a good idea to have two code paths, one
that does 32-bit arithmetic and one that uses explicit 64-bit math.

Eduardo