Need Assistance from C Programmers

[mark pruitt]

I'm converting some C code that calculates a CRC-16 value for a string, and then
generates two one byte Block Check Characters for appending to the end of the
message. The CrcReg variable in C in an unsigned short. After calculating the
values of BCC1? and BCC2?, I use MKBYT$ to convert them to string data.

The first Block Check Character is derived from the final value accumulated in the
CRC Register as follows:

              return (~((CrcReg >> 8) & 0x00ff))

I believe it's equivalent in PowerBASIC is:

              SHIFT RIGHT CrcReg??, 8
                BCC1? = NOT(CrcReg?? AND &h00ff)

The second Block Check Character is calculated like this:

              return(~(CrcReg & 0x00ff))

It's equivalent in PowerBASIC should be:

              BCC2? = NOT(CrcReg?? AND &h00ff)

The function that calculates the 1st Block Check Character is called first, and the
function that generates the 2nd is called immeadiately after. In PowerBASIC, the
first function modifies CrcReg??. When the second function calculates BCC2, it uses
a value for CrcReg?? that is now different.

In C, does the value of CrcReg?? in the first function get modified, or does the function
merely return the value of the equation, leaving CrcReg unmodified?

Did I translate the C code correctly into PowerBASIC? Am I missing something else? Any
and all input and help appreciated.


------------------
Mark Pruitt
[email protected]

[Tom Hanlin]

In C, does the value of CrcReg?? in the first function get modified

No.

Otherwise, looks good.



------------------
Tom Hanlin
PowerBASIC Staff

[mark pruitt]

Thanks Tom. I think I can get around the problem by using another variable
to represent the value of CrcReg??, let the first function modify it, and
allow the second function to use the unmodified CrcReg??

FUNCTION GetBCC1 () AS LONG
    STATIC CopyCRC??, BCC1?
      CRC?? = CrcReg??
      SHIFT RIGHT CopyCRC??, 8
          BCC1? = NOT(CRC?? and &h00ff)
END FUNCTION

FUNCTION GetBCC2 (BCC1?) AS LONG
    STATIC BCC2?
    BCC2? = NOT(CrcReg?? AND &h00ff)
      FinalBlockCheckCharacter$ = MKBYT$(BCC1?) + MKBYT$(BCC2?)
END FUNCTION

------------------
Mark Pruitt
[email protected]



[This message has been edited by mark pruitt (edited July 29, 2003).]

[mark pruitt]

I just wanted to follow up. Knowing definately that C does not modify the value
of the variable in question (CrcReg??) was key to translating the entire set of
functions. Taking that into account, I was able to modify all appropriate sections
of the source code, and now have a set of Functions that are operating at 100%.

Perhaps if there is some merit in it, the SHIFT statement could be slightly
modified:

     SHIFT RIGHT n&, 8, x%, y&

If x% is %TRUE (or > 0), don't modify n&; store the modified value in y&. If
it's ok to modify the value of n&, omit the last two values.



------------------
Mark Pruitt
[email protected]

[Tom Hanlin]

I'll put it on the wish list. You could easily do this with functions,
though:

FUNCTION SHRL (BYVAL v AS LONG, BYVAL c AS LONG) AS LONG
    SHIFT RIGHT v, c
    FUNCTION = v
END FUNCTION

C has only two operations which modify values without an explicit
assignment: the increment (++) and decrement (--) operators. When
used as part of an expression, placing the ++ or -- operators before
a variable means that the increment or decrement will take place
before the value is evaluated in the expression; placing the
operators after the variable means that it's incremented or
decremented after the value is evaluated in the expression.

Example:

    a = 1;
    b = a++ * 2;
    // a == 2
    // b == 2
 
    a = 1;
    b = ++a * 2;
    // a == 2
    // b == 4

------------------
Tom Hanlin
PowerBASIC Staff

[mark pruitt]

Originally posted by Tom Hanlin:
You could easily do this with functions, though:

Good Point. As I was posting the last reply, I realized something similar could
be done with a Macro. I'll probably find a way to emulate the functionality of
the SHIFT statement in C and add it to my code snippets for future use.



------------------
Mark Pruitt
[email protected]