Bug#608550: closed by Aurelien Jarno <aurelien@aurel32.net> (Re:
On Sat, Jan 01, 2011 at 03:34:02PM +0100, Peter T. Breuer wrote:
> Hi ... (disagree, for flaw in reasoning about bne).
>
> "Also sprach Debian Bug Tracking System:"
> > > With compile options
> > >
> > > -O0 -static -DMIPS -mips1 -mabi=32 -msoft-float -mno-memcpy
> > >
> > > gcc produces incorrect code for division (and I suppose, %) from C.
> > >
> > > Test code can be simply:
> > >
> > >
> > > main() {
> > > int a,b,c;
> > > c = a/b;
> > > }
> > >
> > > compile to assembler with above flags. Read, or compile to object code
> > > and disassemble. The eyes-on read shows:
> > >
> > > bne $3,$0,1f #!!! ergh! Should be beq
> > > div $0,$2,$3
> > > break 7
> > > 1:
> > > mflo $2
> > >
> > > The divide is protected by a "branch around the divide if the denominator
> > > is NOT equal to zero". It should be "IS equal to zero".
> >
> > I strongly disagree, the code is correct:
> >
> > * if v1 is equal to 0, the following sequence is executed:
> > bne $3,$0,1f
> > div $0,$2,$3
> > break 7
>
> Yes. The branch fails, and falls through to the division, which (fails
> and) traps in the break following.
>
> >
> > In short a division by 0 will trap.
>
> Amen.
>
> > * if v1 is different than 0, the following sequence is executed:
> > bne $3,$0,1f
>
> OK.
>
> > div $0,$2,$3
>
> Uh uh.
>
> Why do you think so? The branch IS taken, and jumps forward. OK .. so
> that depends on whatever "1f" means in this dialect. I interpreted it
> as "jump _forward_ to the label '1' which precedes the following mflo).
> I can see no other reasonable interpretation ("1f" as hex would not be
> divisible by 4), and the machine code bears me out. I quoted it
> earlier, and here it is again (obtained via objdump of the .o code):
Because MIPS uses delay slots. It's one of the basic you should know
before looking at MIPS assembly code.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: