On Fri, 1 Sep 2000, Matti Aarnio wrote:
> On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> > > ( Not 'unsigned long long' )
> > The shift on pbm_offset operates on long long.
> Uh, somehow I thought the reference was about bh->b_blocknr;
> Ok, never mind.
> > The previous analysis was not quite right though (%cl is actually loaded,
> > just %eax gets bogus input from the long long shift)
> Register pressure burst at i386 ?
> ... [div64] ...
> > So what do you propose to use when a long long division is needed (after
> > much thought and considering all alternatives etc.etc.) ?
> Huh ? No nice power-of-two and shifting ?
> (In filesystem side there is - AFFS or HFS - some which
> have non-power-of-two block sizes, but luckily those
> variants are also limited under 2G in file size...)
> Perhaps redoing div64() in inlined function instead of
> side-effectfull macro with explite variable passing via
> Perhaps sacrificing a bit more, and using explicite
> div64() function which is exported in symbols (and
> explicite variable passing via reference)
> After all, if one really must use it, do it explicite,
> but first of all: reliable.
At the cost of stack operations in, and out, of the function, you
can guarantee reliable results regardless of what a particular
gcc version does. Just push/pop the registers you destroy within
the function. These operations only occur once going in and once
coming out of the function. Just tell gcc that you don't destroy
any registers, then don't destroy any.
Long long division is not going to be efficient anyway. Long-long
compares are also not very efficient because of the necessary
jumps on condition. It may be better to just do the subtraction
(a compare is a subtraction). Addition and subtraction are straight-
forward because the carries are in the flags so you don't have to jump.
Lib-gcc has the code. It could be "lifted" and massaged into inline
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:11 EST