8bit var holds 16bit data!??

hi all,

so i've been having very odd problems with signed math lately, and have recently gone through the trouble to make a pic serial calculator to test a few things. using the following code as an example of what i'm testing, i am quite confused by the pic's behaviour. in this example, assume a and b are always less than $80 (positive).

in hex (2's comp math) take the following example,
$00 - $05 = $FB
since the result is greater than $80, it is negative.
to find the magnitude of a negative number:
result = ~$FB+1 = $05

''''''''''''''''''''
a var byte
b var byte
result var byte
neg var bit

neg = 0
a = 0
b = 5

result = a - b 'the answer is -5, in 2's comp: $FB

if (result > $80) then neg = 1 ' test for negative numbers

result = ~(result) ' this yeilds $04
result = result +1 ' this should yield 5 - the correct magnitude
''''''''''''''''''''

what i get instead, is a 16 bit value for result. as soon as i NOT the result the binary value dumped over serial is 16 bits - $FF04. if i hserout he decimal value, i get 65284. how is this happening?

if someone could please explain this, i'd really appreciate it. i can't see how the pic can allocate a byte for the variable, then write a word to it without crashing. i must be doing something wrong, the pic couldn't function if memory allocation was that untrustworthy - the stack would get hosed.

mofarngo

We can't debug your code as you have not posted the part that is actually causing the "problem".

Using appropriate modifiers with HSEROUT would do the trick.

See: Manual Section 5.31

mofarngo

We can't debug your code as you have not posted the part that is actually causing the "problem".

Using appropriate modifiers with HSEROUT would do the trick.

See: Manual Section 5.31

I've run into this problem before. The ~ operator returns a 16 bit result. If you store the result into your one byte var, the upper word is truncated thus removing the uneccesary bits.

I suspect you were doing something like:
HSEROUT ["0-5=", ~Result+1]

If so, that would cause exactly what you describe. The pseudo code posted however does not suffer from this problem.

Quote:

---

Originally Posted by pwhitt

I've run into this problem before. The ~ operator returns a 16 bit result. If you store the result into your one byte var, the upper word is truncated thus removing the uneccesary bits.

I suspect you were doing something like:
HSEROUT ["0-5=", ~Result+1]

If so, that would cause exactly what you describe. The pseudo code posted however does not suffer from this problem.

---

The problem is:
You are outputting a VAR that has been declared as BYTE with a resolution of 16 bits,
that doesn't make much sense, does it?

Try:
HSEROUT [DEC3 result] ' for Decimal output (3 Digits)

HSEROUT [HEX2 result] ' for Hexadecimal output (2 Digits)

See: Manual Section 5.31

<i>"The problem is:
You are outputting a VAR that has been declared as BYTE with a resolution of 16 bits, that doesn't make much sense, does it?"</i>

NavMicroSystems, if you mean the output of the HSEROUT statement:

HSEROUT ["0-5=", ~Result+1]

No, I'm outputting the result of a 16bit operation, not a VAR at all (this would likely end up in a terminal full of garbage - not numbers at all). I should have been more clear and typed:

HSEROUT ["0-5+",BIN ~Result+1]
which should yield: 1111111100000101 and I think this corresponds to the incorrect value given above.

However if our friend Mofarngo were to write this value to Result first, the leading word would be truncated, resulting in: 00000101, which is what he wants.

pwhitt is right. When you include the equation inline with HSEROUT ["0-5=", ~Result+1] you're telling PBP to output the "result" of ~result+1.

And since the compliment is handled as a 16-bit operation, HSEROUT is going to send a 16-bit result computed internally by the inline equation ~result+1.

You can see how this works with something like this;

HSEROUT ["100 * 50 = ", DEC 100*50,13,10]

Note there's no reference to any variable. Only an equation. That's pretty much the same thing as passing ~result+1 to HSEROUT. It's going to print the result of the equation, and not the byte variable result.

thanks guys - that was a stupid oversight on my part.

i was doing exactly "serout [~result+1]" to get the result.

writing the result to the var and then sending over serial fixed it right away. oops!