Hi Alex,
Thanks... Fixed...
...Only one character at the end, but such a massive result :)
~d
On Wednesday 02 October 2002 06:17, Alexey Zaparovanny wrote:
> 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
--
/********************************************************************
("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
`6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
(_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
_..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
(il),-'' (li),' ((!.-' +7 (812) 3468202, 5585314
********************************************************************/
