Hello Dmitry,
I'm getting some mixed results.
Looks like that case has been fixed if I use "less" sign instead of "less
or equal". It generates correct code:
; if(pThread->m_dwWakeupTime < dwCurrentTime) {
mov &0x0246,r15 ;src addr 0x0246, Cycles: 2
mov @r15+, r13 ;Cycles: 2
mov @r15+, r14 ;Cycles: 2
sub #4, r15 ;subst r2 with As==10, Cycles: 1
sub &0x0238,r13 ;src addr 0x0238, Cycles: 2
subc &0x023a,r14 ;src addr 0x023a, Cycles: 2
jc $-88 ;abs dst addr 0xa1a2, Cycles: 2
However I change it to "less or equal" I'm getting the following:
; if(pThread->m_dwWakeupTime <= dwCurrentTime) {
mov &0x0246,r15 ;src addr 0x0246, Cycles: 2
mov &0x0238,r13 ;src addr 0x0238, Cycles: 2
mov &0x023a,r14 ;src addr 0x023a, Cycles: 2
sub @r15, r13 ;Cycles: 2
sub 2(r15), r14 ;Cycles: 3
jnc $-88 ;abs dst addr 0xa1a2, Cycles: 2
That does not look right to me. Two "sub" instructions in which only the
last one affects the flags....
Best regards,
Alexey
> Message: 1
> From: "Alexey Zaparovanny" <[email protected]>
> To: <[email protected]>
> Date: Thu, 26 Sep 2002 20:35:13 -0400
> Subject: [Mspgcc-users] Re: Looks like compiler bug
> Reply-To: [email protected]
>
> Thanks for fixing it Dmitry!
>
> Why is that case so special that you called it "exotic case" ?:)
>
> Best regards!
>
> > From: "Alexey Zaparovanny" <[email protected]>
> > To: <[email protected]>
> > Date: Thu, 26 Sep 2002 01:20:07 -0400
> > Subject: [Mspgcc-users] Looks like compiler bug
> > Reply-To: [email protected]
> >
> > Hello,
> >
> > Looks like compiler generated buggy code when it handles "unsigned long
> int"
> > types:
> >
> > Following simplified c code produces incorrect comparison code on line
> > marked with "**--->"
> >
> > while(1) {
> > if(cThreadIndex == cLastThreadIndex) {
> > cThreadIndex = 0;
> > } else {
> > cThreadIndex++;
> > }
> > if((threads[cThreadIndex].m_cThreadFlags & THREAD_FLAG_SLEEPING) == 0)
{
> > break;
> > **---> } else if(threads[cThreadIndex].m_dwWakeupTime <= dwCurrentTime)
{
> > break;
> > }
> > }
> > ------
> > Here is the assembly output: (this "restore r15 at the third line from
the
> > bottom upsets the flag register")
> >
> > .L6:
> > cmp.b &cLastThreadIndex, &cThreadIndex
> > jne .L9
> > mov.b #llo(0), &cThreadIndex
> > jmp .L10
> > .L9:
> > add.b #llo(1), &cThreadIndex
> > .L10:
> > mov.b &cThreadIndex, r14
> > mov r14, r15
> > rla r15
> > rla r15
> > add r14, r15
> > rla r15
> > add #threads+8, r15
> > mov.b @r15, r15
> > and.b #llo(1), r15
> > tst.b r15
> > jne .L11
> > jmp .L7
> > .L11:
> > mov.b &cThreadIndex, r14
> > mov r14, r15
> > rla r15
> > rla r15
> > add r14, r15
> > rla r15
> > add #threads, r15
> > mov &dwCurrentTime, r13
> > mov &dwCurrentTime+2, r14
> > sub @r15+, r13
> > subc @r15+, r14
> > sub #4, r15 ; restore r15
> > jlo .L6
> > .L7:
> >
> >
> >
> > -- __--__--
> >
> > Message: 2
> > From: Dmitry <[email protected]>
> > Organization: EIS
> > To: [email protected]
> > Subject: Re: [Mspgcc-users] Looks like compiler bug
> > Date: Thu, 26 Sep 2002 11:16:51 +0400
> > Reply-To: [email protected]
> >
> > Thanks for reporting this.
> > Fixed.
> > Please update sources and recompile gcc.
> >
> > Actually, very exotic case :)
> >
> > And yesterday, I commited a binutils update. New section ".noinit"
added.=
> > =2E.
> > Vars in this section will not be inited during system start-up.
> >
> >
> > ~d
>
>
>
>
> --__--__--
>
> Message: 2
> From: Dmitry <[email protected]>
> Organization: EIS
> To: [email protected]
> Subject: Re: [Mspgcc-users] Re: Looks like compiler bug
> Date: Fri, 27 Sep 2002 10:30:31 +0400
> Reply-To: [email protected]
>
> "exotic case" here can be reffered to gcc internal code generation.
>
> Almost all arithmetic insns use 'indexed with postincrement' for an array=
> =20
> element if possible with later index restore if necessary. For example:
> =09mov @r15+, r10
> =09mov @r15+, r11
> If r15 being used and not set afterwards, gcc issues.
> =09sub #4, r15
>
> This is better than
> =09mov @r15, r10
> =09mov 2(r15), r11
> cause we win one cycle and 2 bytes in first case.
>
> In the code below the first pattern being used in cmpSI just before jump =
> insn.
> the r15 sould be dead or set after jump insn, but gcc does set such a fla=
> g to=20
> the register cause of end of function. So, sub #4, r15 being issued
just=20
> before jump insn, which clobbers SR.
>
> ~d
