1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

68k chip, Diab Compiler and odd behavior

Discussion in 'Embedded' started by Scott, Apr 9, 2004.

  1. Scott

    Scott Guest

    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.

    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;
    Scott, Apr 9, 2004
    1. Advertisements

  2. ^^^ This is usually best left to the compiler to decide; there is rarely
    an advantage to using the register declaration...
    Make up your mind; is it 16 or 32 bits?
    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.

    A curly brace wouldn't hurt here... {
    Gene S. Berkowitz, Apr 9, 2004
    1. Advertisements

  3. Scott

    CBFalconer Guest

    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)"
    CBFalconer, Apr 9, 2004
  4. 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 S. Berkowitz, Apr 9, 2004
  5. Scott

    CBFalconer Guest

    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 */
    CBFalconer, Apr 9, 2004
  6. Scott

    Richard Guest

    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, Apr 9, 2004
  7. No; in the OP's code, shift is INITIALIZED to 1 EVERY time through the
    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.
    ...which is why I recommended moving the initialization outside the loop,
    and shift by 1 each time within the loop.

    Gene S. Berkowitz, Apr 9, 2004
  8. Scott

    Ben Bradley Guest

    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.
    Ben Bradley, Apr 9, 2004
  9. Scott

    CBFalconer Guest

    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. :-(
    CBFalconer, Apr 10, 2004
  10. Scott

    Scott Guest

    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, Apr 12, 2004
  11. Scott

    Scott Guest

    I don't know why the debugger was skipping lines 13 and 14 and going
    to 15 and not executing, but know why my display was not being updated
    correctly. tmpfaultvalue was being set to a mask of 65535 (0xFFFF). As
    a result, the first 16 faults on the display were being updated. The
    problem is that there are 19 faults on the display.

    Scott, Apr 13, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.