Negative Values

[Brian Darby]

My hex_in code seems to be working properly, but it is not reconizing
0x80000000 or values near it as a negative, however it does recognize
FFFFFFFF.

[Wayne D. Heym]

My hex_in code seems to be working properly, but it is not recognizing
0x80000000 or values near it as a negative, however it does recognize
FFFFFFFF.

You may want to set a break point at the place where hex_in returns to
the caller. Look and see if the value you expect to see is in %o0
(%r8). If %r8 = 80000000, then surely a comparison with that and zero
followed by a bl instruction should cause execution to transfer to the
label of the bl instruction. Let us know what you find out!

[David Telintelo]

It's very possible that you only entered 6 zeros after the 8, in which
case there would still be a zero to the left of the 8, making your input
a positive value.

Post by Wayne D. Heym

My hex_in code seems to be working properly, but it is not recognizing
0x80000000 or values near it as a negative, however it does recognize
FFFFFFFF.

You may want to set a break point at the place where hex_in returns to
the caller. Look and see if the value you expect to see is in %o0
(%r8). If %r8 = 80000000, then surely a comparison with that and zero
followed by a bl instruction should cause execution to transfer to the
label of the bl instruction. Let us know what you find out!

[Brian Darby]

My shifting idea only works when the value isn't 0. Looks like
multiplication is the answer after all.
thanks.
b

Post by Wayne D. Heym

My hex_in code seems to be working properly, but it is not recognizing
0x80000000 or values near it as a negative, however it does recognize
FFFFFFFF.

You may want to set a break point at the place where hex_in returns to
the caller. Look and see if the value you expect to see is in %o0
(%r8). If %r8 = 80000000, then surely a comparison with that and zero
followed by a bl instruction should cause execution to transfer to the
label of the bl instruction. Let us know what you find out!
--
Wayne

[Wayne D. Heym]

Post by Brian Darby
My shifting idea only works when the value isn't 0. Looks like
multiplication is the answer after all.

If we do what we're doing to the running sum (not to the individual
digit's value), then multiplication by 16 and shifting to the left by 4
bits really are the same thing. I wonder what the problem really was. . . .

Cheers!

[Brian Darby]

shifting 0 is still 0. so when i "or"ed it against the previous value, the bits didn't move.

David - best believe i was counting my 0s carefully...;)

"Wayne D. Heym" <***@cse.ohio-state.edu> wrote in message news:***@cse.ohio-state.edu...


My shifting idea only works when the value isn't 0. Looks like
multiplication is the answer after all.
If we do what we're doing to the running sum (not to the individual digit's value), then multiplication by 16 and shifting to the left by 4 bits really are the same thing. I wonder what the problem really was. . . .

Cheers!

[Wayne D. Heym]

Post by Brian Darby
shifting 0 is still 0. so when i "or"ed it against the previous
value, the bits didn't move.

Well, you still have me confused. Multiplying 0 by 16 is still 0, too,
so I still don't see the difference.

[Brian Darby]

your right, either way it looks like I need some branch statements to handle the zero case
"Wayne D. Heym" <***@cis.ohio-state.edu> wrote in message news:***@cis.ohio-state.edu...


shifting 0 is still 0. so when i "or"ed it against the previous value, the bits didn't move.

Well, you still have me confused. Multiplying 0 by 16 is still 0, too, so I still don't see the difference.

[Wayne D. Heym]

you're right, either way it looks like I need some branch statements
to handle the zero case

The algorithm that I use for hex_in is the following:

object Character ch;
object Integer sum;

// start sum at 0
getchar (ch); // ta getchar
while (ch != '\n')
{
sum = sum * 16 + Proper_Digit_Value_Associated_With_Character (ch);
getchar (ch); // ta getchar
}
// sum has the correct value when this loop concludes


Of course, there's a bit of complexity in the conversion handled by my
"call" to Proper_Digit_Value_Associated_With_Character, but I claim that
this algorithm does the job correctly.

It will even handle the input string "0000001a\n" correctly. Object sum
remains at zero until the character '1' is encountered, then it becomes
1 before being multiplied by 16 to become sixteen; then ten is added to
it to make it 26 (in other words, 0x1A).

[Brian Darby]

Thanks, I have it working now. I stayed with the shifts and just handled
the zero case.
Are we required to handle the leading 0s?

Post by Wayne D. Heym

you're right, either way it looks like I need some branch statements
to handle the zero case

object Character ch;
object Integer sum;
// start sum at 0
getchar (ch); // ta getchar
while (ch != '\n')
{
sum = sum * 16 + Proper_Digit_Value_Associated_With_Character (ch);
getchar (ch); // ta getchar
}
// sum has the correct value when this loop concludes
Of course, there's a bit of complexity in the conversion handled by my
"call" to Proper_Digit_Value_Associated_With_Character, but I claim that
this algorithm does the job correctly.
It will even handle the input string "0000001a\n" correctly. Object sum
remains at zero until the character '1' is encountered, then it becomes
1 before being multiplied by 16 to become sixteen; then ten is added to
it to make it 26 (in other words, 0x1A).
--
Wayne

[Wayne D. Heym]

Post by Brian Darby
Are we required to handle the leading 0s?

Yes, that would still be legal "hexadecimal notation for a nonnegative
numeric value", but this item shouldn't be worth more than 5 points.