68k chip, Diab Compiler and odd behavior

Let me first say that I am new to the embedded development community.
I have been tasked with determining the problem with the code below.
Let me explain what is happening and why I find it strange. The
problem is in the inner for loop. The first 16 times through the loop
all lines execute as expected. After that, when I step through with
the debugger, line 12 is executed and the debugger skips 13 and 14,
and goes to line 15. The debugger will not step into the function on
line 15, gScreenIO.Special(), it just pops out and goes to line 12
again to repeat the pattern.

I am using Diab Data 4.0b, SingleStep 7.03 on a Windows NT
environment. I have never seen this kind of thing before. I find it
quite odd. I have tried changing the data types of shiftcnt, shift and
count to the largest types possible; same behavior. We can't get any
help from Windriver (I think they bought Diab compiler) because we
haven't given them enough money.

Any help would be *greatly* appreciated. 
TIA.

1void SetSysWin( void )  // Highlight all fault buttons //
{
2  register _faults *fltptr = Disfaults;
3  ulword tmpfaultvalue;
4  ulword shiftcnt;
5  ulword shift; 
6  uword  count;
 
7  for( count = 0; count < MaxFaults; count++ )
  {
8    tmpfaultvalue = fltptr[count].faultvalue;
9    if(tmpfaultvalue)// don't need to check all the bits if there is
no fault
    {
10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
shift through
      {
11        shift = 1;

12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )
13          if( ! ( fltptr->faultsalreadydisplayed & shift ) )
          {
14            fltptr->faultsalreadydisplayed |= shift;  
15            gScreenIO.Special(butPress, Faults[count][shiftcnt]);
          }
      } 
16      gScreenIO << flush; // STS
    }
  } // end of for count loop

17  return;
}

In article <2a55e2bc.0404090600.36d709b@posting.google.com>, sts_222
@hotmail.com says...
> Let me first say that I am new to the embedded development community.
> I have been tasked with determining the problem with the code below.
> Let me explain what is happening and why I find it strange. The
> problem is in the inner for loop. The first 16 times through the loop
> all lines execute as expected. After that, when I step through with
> the debugger, line 12 is executed and the debugger skips 13 and 14,
> and goes to line 15. The debugger will not step into the function on
> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> again to repeat the pattern.
> 
> I am using Diab Data 4.0b, SingleStep 7.03 on a Windows NT
> environment. I have never seen this kind of thing before. I find it
> quite odd. I have tried changing the data types of shiftcnt, shift and
> count to the largest types possible; same behavior. We can't get any
> help from Windriver (I think they bought Diab compiler) because we
> haven't given them enough money.
> 
> Any help would be *greatly* appreciated. 
> TIA.
> 
> 1void SetSysWin( void )  // Highlight all fault buttons //
> {
> 2  register _faults *fltptr = Disfaults;

^^^ This is usually best left to the compiler to decide; there is rarely
an advantage to using the register declaration...

> 3  ulword tmpfaultvalue;
> 4  ulword shiftcnt;
> 5  ulword shift; 
> 6  uword  count;
>  
> 7  for( count = 0; count < MaxFaults; count++ )
>   {
> 8    tmpfaultvalue = fltptr[count].faultvalue;
> 9    if(tmpfaultvalue)// don't need to check all the bits if there is
> no fault
>     {
> 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> shift through

Make up your mind; is it 16 or 32 bits?

>       {
> 11        shift = 1;

You should probably move this assigment OUTSIDE the for(shiftcnt) loop,
then simply shift it left by one bit each time at the end of the loop:

shift = 1;
for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) 
{
   ..tests go here
   shift <<= 1;
}

Compile this file with optimization OFF (no -XO switch).
SingleStep is incredibly bad at showing the actual location within
optimized for(..) loops, unless you drop into disassembly mode.

 
> 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )

A curly brace wouldn't hurt here... {

> 13          if( ! ( fltptr->faultsalreadydisplayed & shift ) )
>           {
> 14            fltptr->faultsalreadydisplayed |= shift;  
> 15            gScreenIO.Special(butPress, Faults[count][shiftcnt]);
>           }
..and here }
>       } 
> 16      gScreenIO << flush; // STS
>     }
>   } // end of for count loop
> 
> 17  return;
> }

--Gene

Scott wrote:
> 
> Let me first say that I am new to the embedded development community.
> I have been tasked with determining the problem with the code below.
> Let me explain what is happening and why I find it strange. The
> problem is in the inner for loop. The first 16 times through the loop
> all lines execute as expected. After that, when I step through with
> the debugger, line 12 is executed and the debugger skips 13 and 14,
> and goes to line 15. The debugger will not step into the function on
> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> again to repeat the pattern.
> 
... snip ...
> 
> 7  for( count = 0; count < MaxFaults; count++ )
>   {
> 8    tmpfaultvalue = fltptr[count].faultvalue;
> 9    if(tmpfaultvalue)// don't need to check all the bits if there is
> no fault
>     {
> 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> shift through
>       {
> 11        shift = 1;
> 
> 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )

Don't use // comments in newsgroups, they don't wrap well.

Apart from the silly type names (what is wrong with unsigned long
etc?) just monitor the value of shift.  It should be 1, 2, 8, ....
which I doubt is what you want.  At shiftcnt == 16 it is shifting
off the left, and becoming zero, which has a tendency to inhibit
any action controlled by your line 12.  Maybe the initialization
of shift should go, and the expression should be: "if (shift = (1
<< shiftcnt)) & tmpfaultvalue)"

-- 
Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses.  - James Rhodes.

In article <4076BAB8.ED557162@yahoo.com>, cbfalconer@yahoo.com says...
> Scott wrote:
> > 
> > Let me first say that I am new to the embedded development community.
> > I have been tasked with determining the problem with the code below.
> > Let me explain what is happening and why I find it strange. The
> > problem is in the inner for loop. The first 16 times through the loop
> > all lines execute as expected. After that, when I step through with
> > the debugger, line 12 is executed and the debugger skips 13 and 14,
> > and goes to line 15. The debugger will not step into the function on
> > line 15, gScreenIO.Special(), it just pops out and goes to line 12
> > again to repeat the pattern.
> > 
> ... snip ...
> > 
> > 7  for( count = 0; count < MaxFaults; count++ )
> >   {
> > 8    tmpfaultvalue = fltptr[count].faultvalue;
> > 9    if(tmpfaultvalue)// don't need to check all the bits if there is
> > no fault
> >     {
> > 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> > shift through
> >       {
> > 11        shift = 1;
> > 
> > 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> 
> Don't use // comments in newsgroups, they don't wrap well.
> 
> Apart from the silly type names (what is wrong with unsigned long
> etc?) just monitor the value of shift.  It should be 1, 2, 8, ....
> which I doubt is what you want.  At shiftcnt == 16 it is shifting
> off the left, and becoming zero, which has a tendency to inhibit
> any action controlled by your line 12.

If the odd typing can be believed, "shift" is an unsigned long, which
defaults to 32 bits with the Diab compiler, so I don't think it's 
falling off the end.  A more appropriate name would be "Bitmask",
because that's what it is.

--Gene

"Gene S. Berkowitz" wrote:
> cbfalconer@yahoo.com says...
>> Scott wrote:
>>>
>>> Let me first say that I am new to the embedded development community.
>>> I have been tasked with determining the problem with the code below.
>>> Let me explain what is happening and why I find it strange. The
>>> problem is in the inner for loop. The first 16 times through the loop
>>> all lines execute as expected. After that, when I step through with
>>> the debugger, line 12 is executed and the debugger skips 13 and 14,
>>> and goes to line 15. The debugger will not step into the function on
>>> line 15, gScreenIO.Special(), it just pops out and goes to line 12
>>> again to repeat the pattern.
>>>
>> ... snip ...
>>>
>>> 7  for( count = 0; count < MaxFaults; count++ )
>>>   {
>>> 8    tmpfaultvalue = fltptr[count].faultvalue;
>>> 9    if(tmpfaultvalue)// don't need to check all the bits if there is
>>> no fault
>>>     {
>>> 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
>>> shift through
>>>       {
>>> 11        shift = 1;
>>>
>>> 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )
>>
>> Don't use // comments in newsgroups, they don't wrap well.
>>
>> Apart from the silly type names (what is wrong with unsigned long
>> etc?) just monitor the value of shift.  It should be 1, 2, 8, ....
>> which I doubt is what you want.  At shiftcnt == 16 it is shifting
>> off the left, and becoming zero, which has a tendency to inhibit
>> any action controlled by your line 12.
> 
> If the odd typing can be believed, "shift" is an unsigned long,
> which defaults to 32 bits with the Diab compiler, so I don't think
> it's falling off the end.  A more appropriate name would be
> "Bitmask", because that's what it is.

Yes it is falling off, at count = 16, with a 32 bit unsigned
long.  At that point you are shifting 65536 left 16 places, with
result 0.

After 8 in the above sequence comes 128.  I.e. it is not really
the bitmask you want if you are trying to scan bits in
tmpfaultvalue.  If you need a mask that moves left, use the code I
suggested and you snipped.  If you just need to test the bits in
sequence, then:

   for (tfv = tmpfaultvalue, i = 0; i < MAGICSIZE; i++, tfv >>= 1)
{
      if (1 & tfv) {
         /* action */
      }
   }

-- 
Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses.  - James Rhodes.

CBFalconer <cbfalconer@yahoo.com> wrote in news:4076E618.D7B44993
@yahoo.com:

> "Gene S. Berkowitz" wrote:
>> cbfalconer@yahoo.com says...
>>> Scott wrote:
>>>>
>>>> Let me first say that I am new to the embedded development 
community.
>>>> I have been tasked with determining the problem with the code below.
>>>> Let me explain what is happening and why I find it strange. The
>>>> problem is in the inner for loop. The first 16 times through the 
loop
>>>> all lines execute as expected. After that, when I step through with
>>>> the debugger, line 12 is executed and the debugger skips 13 and 14,
>>>> and goes to line 15. The debugger will not step into the function on 
>>>> line 15, gScreenIO.Special(), it just pops out and goes to line 12
>>>> again to repeat the pattern.
>>>>
>>> ... snip ...
>>>>
>>>> 7  for( count = 0; count < MaxFaults; count++ )
>>>>   {
>>>> 8    tmpfaultvalue = fltptr[count].faultvalue;
>>>> 9    if(tmpfaultvalue)// don't need to check all the bits if there 
is
>>>> no fault
>>>>     {
>>>> 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
>>>> shift through
>>>>       {
>>>> 11        shift = 1;
>>>>
>>>> 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )
>>>
>>> Don't use // comments in newsgroups, they don't wrap well.
>>>
>>> Apart from the silly type names (what is wrong with unsigned long
>>> etc?) just monitor the value of shift.  It should be 1, 2, 8, ....
>>> which I doubt is what you want.  At shiftcnt == 16 it is shifting
>>> off the left, and becoming zero, which has a tendency to inhibit any
>>> action controlled by your line 12. 
>> 
>> If the odd typing can be believed, "shift" is an unsigned long, which
>> defaults to 32 bits with the Diab compiler, so I don't think it's
>> falling off the end.  A more appropriate name would be "Bitmask",
>> because that's what it is. 
> 
> Yes it is falling off, at count = 16, with a 32 bit unsigned
> long.  At that point you are shifting 65536 left 16 places, with
> result 0.
> 
> After 8 in the above sequence comes 128.  I.e. it is not really
> the bitmask you want if you are trying to scan bits in
> tmpfaultvalue.

shift is reset to 1 each pass through the loop, so the sequence is the 
expected 1,2,4,8,16,32,....

Certainly not the way I would code it, but, I don't see a problem with 
that offhand, assuming that ulword is indeed an unsigned 32 bit integer.

-- 
Richard

In article <4076E618.D7B44993@yahoo.com>, cbfalconer@yahoo.com says...
> "Gene S. Berkowitz" wrote:
> > cbfalconer@yahoo.com says...
> >> Scott wrote:
> >>>
> >>> Let me first say that I am new to the embedded development community.
> >>> I have been tasked with determining the problem with the code below.
> >>> Let me explain what is happening and why I find it strange. The
> >>> problem is in the inner for loop. The first 16 times through the loop
> >>> all lines execute as expected. After that, when I step through with
> >>> the debugger, line 12 is executed and the debugger skips 13 and 14,
> >>> and goes to line 15. The debugger will not step into the function on
> >>> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> >>> again to repeat the pattern.
> >>>
> >> ... snip ...
> >>>
> >>> 7  for( count = 0; count < MaxFaults; count++ )
> >>>   {
> >>> 8    tmpfaultvalue = fltptr[count].faultvalue;
> >>> 9    if(tmpfaultvalue)// don't need to check all the bits if there is
> >>> no fault
> >>>     {
> >>> 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> >>> shift through
> >>>       {
> >>> 11        shift = 1;
> >>>
> >>> 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> >>
> >> Don't use // comments in newsgroups, they don't wrap well.
> >>
> >> Apart from the silly type names (what is wrong with unsigned long
> >> etc?) just monitor the value of shift.  It should be 1, 2, 8, ....
> >> which I doubt is what you want.  At shiftcnt == 16 it is shifting
> >> off the left, and becoming zero, which has a tendency to inhibit
> >> any action controlled by your line 12.
> > 
> > If the odd typing can be believed, "shift" is an unsigned long,
> > which defaults to 32 bits with the Diab compiler, so I don't think
> > it's falling off the end.  A more appropriate name would be
> > "Bitmask", because that's what it is.
> 
> Yes it is falling off, at count = 16, with a 32 bit unsigned
> long.  At that point you are shifting 65536 left 16 places, with
> result 0.

No; in the OP's code, shift is INITIALIZED to 1 EVERY time through the 
loop.
The 1st pass, shift (1) is shifted left shiftcnt (0) bits == 1.
The 2nd pass, shift (1) is shifted left shiftcnt (1) bits == 2.
The 3rd pass, shift (1) is shifted left shiftcnt (2) bits == 4.
etc.
..which is why I recommended moving the initialization outside the loop,
and shift by 1 each time within the loop.

--Gene

In comp.arch.embedded, Gene S. Berkowitz <first.last@comcast.net>
wrote:
>You should probably move this assigment OUTSIDE the for(shiftcnt) loop,
>then simply shift it left by one bit each time at the end of the loop:
>
>shift = 1;
>for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) 
>{
>   ..tests go here
>   shift <<= 1;
>}

>You should probably move this assigment OUTSIDE the for(shiftcnt) loop,
>then simply shift it left by one bit each time at the end of the loop:

   I might argue that the mask (the variable named 'shift') is a
second loop index, and stick the initialization and 'incrementing'
into the for statement:

for(shiftcnt = 0, shift = 1;  shiftcnt < 32;  shiftcnt++, shift <<= 1)
{

12        if( shift & tmpfaultvalue )
...

}

The code is effectively no different from yours, but it makes it more
obvious that both shiftcnt and shift are loop variables, set in the
for statement, and read but not changed inside the loop.

-----
http://mindspring.com/~benbradley

"Gene S. Berkowitz" wrote:
> 
> In article <4076E618.D7B44993@yahoo.com>, cbfalconer@yahoo.com says...
> > "Gene S. Berkowitz" wrote:
> > > cbfalconer@yahoo.com says...
> > >> Scott wrote:
> > >>>
> > >>> Let me first say that I am new to the embedded development community.
> > >>> I have been tasked with determining the problem with the code below.
> > >>> Let me explain what is happening and why I find it strange. The
> > >>> problem is in the inner for loop. The first 16 times through the loop
> > >>> all lines execute as expected. After that, when I step through with
> > >>> the debugger, line 12 is executed and the debugger skips 13 and 14,
> > >>> and goes to line 15. The debugger will not step into the function on
> > >>> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> > >>> again to repeat the pattern.
> > >>>
> > >> ... snip ...
> > >>>
> > >>> 7  for( count = 0; count < MaxFaults; count++ )
> > >>>   {
> > >>> 8    tmpfaultvalue = fltptr[count].faultvalue;
> > >>> 9    if(tmpfaultvalue)// don't need to check all the bits if there is
> > >>> no fault
> > >>>     {
> > >>> 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> > >>> shift through
> > >>>       {
> > >>> 11        shift = 1;
> > >>>
> > >>> 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> > >>
> > >> Don't use // comments in newsgroups, they don't wrap well.
> > >>
> > >> Apart from the silly type names (what is wrong with unsigned long
> > >> etc?) just monitor the value of shift.  It should be 1, 2, 8, ....
> > >> which I doubt is what you want.  At shiftcnt == 16 it is shifting
> > >> off the left, and becoming zero, which has a tendency to inhibit
> > >> any action controlled by your line 12.
> > >
> > > If the odd typing can be believed, "shift" is an unsigned long,
> > > which defaults to 32 bits with the Diab compiler, so I don't think
> > > it's falling off the end.  A more appropriate name would be
> > > "Bitmask", because that's what it is.
> >
> > Yes it is falling off, at count = 16, with a 32 bit unsigned
> > long.  At that point you are shifting 65536 left 16 places, with
> > result 0.
> 
> No; in the OP's code, shift is INITIALIZED to 1 EVERY time through the
> loop.
> The 1st pass, shift (1) is shifted left shiftcnt (0) bits == 1.
> The 2nd pass, shift (1) is shifted left shiftcnt (1) bits == 2.
> The 3rd pass, shift (1) is shifted left shiftcnt (2) bits == 4.
> etc.
> ..which is why I recommended moving the initialization outside the loop,
> and shift by 1 each time within the loop.

You are right - I missed that reinitialization.  The code is even
more obscured than it appears at first.  So I have been talking my
usual nonsense.  Bah.  But the suggestion fitted the described
failure point, which blinded me even further. :-(

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

sts_222@hotmail.com (Scott) wrote in message news:<2a55e2bc.0404090600.36d709b@posting.google.com>...
> Let me first say that I am new to the embedded development community.
> I have been tasked with determining the problem with the code below.
> Let me explain what is happening and why I find it strange. The
> problem is in the inner for loop. The first 16 times through the loop
> all lines execute as expected. After that, when I step through with
> the debugger, line 12 is executed and the debugger skips 13 and 14,
> and goes to line 15. The debugger will not step into the function on
> line 15, gScreenIO.Special(), it just pops out and goes to line 12
> again to repeat the pattern.
> 
> I am using Diab Data 4.0b, SingleStep 7.03 on a Windows NT
> environment. I have never seen this kind of thing before. I find it
> quite odd. I have tried changing the data types of shiftcnt, shift and
> count to the largest types possible; same behavior. We can't get any
> help from Windriver (I think they bought Diab compiler) because we
> haven't given them enough money.
> 
> Any help would be *greatly* appreciated. 
> TIA.
> 
> 1void SetSysWin( void )  // Highlight all fault buttons //
> {
> 2  register _faults *fltptr = Disfaults;
> 3  ulword tmpfaultvalue;
> 4  ulword shiftcnt;
> 5  ulword shift; 
> 6  uword  count;
>  
> 7  for( count = 0; count < MaxFaults; count++ )
>   {
> 8    tmpfaultvalue = fltptr[count].faultvalue;
> 9    if(tmpfaultvalue)// don't need to check all the bits if there is
> no fault
>     {
> 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> shift through
>       {
> 11        shift = 1;
> 
> 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> 13          if( ! ( fltptr->faultsalreadydisplayed & shift ) )
>           {
> 14            fltptr->faultsalreadydisplayed |= shift;  
> 15            gScreenIO.Special(butPress, Faults[count][shiftcnt]);
>           }
>       } 
> 16      gScreenIO << flush; // STS
>     }
>   } // end of for count loop
> 
> 17  return;
> }

Thanks for the input gentlemen. 

I don't know why the programmer didn't use unsigned long instead of
typedefing ulword. I thought the same thing when I saw that. Adds to
the confusion. Along with the silly "16 bits to shift through"
comment. 16 or 32?

I'll try and let you know what happens.

Scott