>> Every occurrence of r7 here is wrong (and some of the r6). Is there
>> any reason to do this in assembler code at all?
>
> The fact that the obvious C code generates ... a call to __ucmpdi2? :)
Hrm? Here's the "obvious" C code, portable to all architectures
(modulo the specific types used, th
Paul Mackerras wrote:
> Segher Boessenkool writes:
>
>> Every occurrence of r7 here is wrong (and some of the r6). Is there
>> any reason to do this in assembler code at all?
>
> The fact that the obvious C code generates ... a call to __ucmpdi2? :)
So use the correct C code, not the obvious C
Segher Boessenkool writes:
> Every occurrence of r7 here is wrong (and some of the r6). Is there
> any reason to do this in assembler code at all?
The fact that the obvious C code generates ... a call to __ucmpdi2? :)
Paul.
___
Linuxppc-dev mailing li
>> Every occurrence of r7 here is wrong (and some of the r6).
>
> Can you elucidate?
Sure! It should read either "7" or "cr7".
>> Is there any reason to do this in assembler code at all?
>
> Is there any particular reason not to?
1) If written in assembler, it needs to be written for every
a
On Tue, Mar 04, 2008 at 04:37:28PM +, David Woodhouse wrote:
>
> On Sun, 2008-03-02 at 22:53 +0100, Segher Boessenkool wrote:
> > Every occurrence of r7 here is wrong (and some of the r6).
>
> Can you elucidate?
They were being used as condition registers rather than GPRs.
> > Is there an
On Sun, 2008-03-02 at 22:53 +0100, Segher Boessenkool wrote:
> Every occurrence of r7 here is wrong (and some of the r6).
Can you elucidate?
> Is there any reason to do this in assembler code at all?
Is there any particular reason not to?
--
dwmw2
__
>> +/*
>> + * __ucmpdi2: 64-bit comparison
>> + *
>> + * R3/R4 has 64 bit value A
>> + * R5/R6 has 64 bit value B
>> + * result in R3: 0 for A < B
>> + * 1 for A == B
>> + * 2 for A > B
>> + */
>> +_GLOBAL(__ucmpdi2)
>> + cmplw r7,r3,r5# compare high words
On 2/6/08, Stephane Marchesin <[EMAIL PROTECTED]> wrote:
>
> We're hitting this i nouveau as well (http://nouveau.freedesktop.org),
> since we make extensive use ot 64 bit ints. Over time, we've had a
> number of reports on this issue, and at one point I read that it
> should be fixed in gcc. B
On 12/17/06, David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> You still get to 'accidentally' do 64-bit arithmetic in-kernel that way
> though. Might be better just to provide __ucmpdi2, just as we have for
> the other functions which are required from libgcc
>
> It'd be better just to fix the compil
