View Single Post
#8
18th November 2013, 06:28 PM
 HatCat Alpha Tester Project Supporter Senior Member Join Date: Feb 2007 Location: In my hat. Posts: 16,260

Quote:
 Originally Posted by retroben Bits are in the same byte of an address. 8bits=1byte with ten placements. The bits are as follows. bit0? 0=0 neutral bit1 1=1 bit2 2=2 bit3 4=4 bit4 8=8 bit5 10=16 bit6 20=32 bit7 40=64 bit8 80=128 bit9? FF=255 maximum (256th number including zero) It can use any and every mixture of bits. Example:bits 6,5,and 3 20+10+4=34 (52 in decimal).
Actually bits 6, 5, and 3 is 64+32+8, which is 104.
You said 52 which is only half of 104 because you got the bit offsets wrong.

First, there are only 8 bits in a byte, not 10.
There's no "bit8" and "bit9".
It's just bits 0 to 7, numbered little-endian.

Second, bit 0 is NOT "neutral".
2 to the power of 0 is 1, not 0.
So bit 0 means you mask | 1,
bit 1 means you mask | 2,
bit 2 means you mask | 4,
etc. all your values are off.

Quote:
 Originally Posted by retroben 00-7F in hex are the positive numbers. 80-FF in hex are the negative numbers. Couning down from FF. Examples: FF= -1 FE= -2 80= -127 (maximum negative) 7F= +127 (maximum positive)
This is true only if you assume two things:
• The corresponding integer storage is sign-extended (a "signed" int), to 8-bit precision.
• The CPU processor registering the numbers uses two's complement negation.

If it were a CPU besides MIPS/Intel it could be 1's complement negation, and negative numbers would not look exactly as you said.

More over, for our purposes, either in hacking or otherwise, a "byte" in a memory viewer should always default to an "unsigned char" perspective in C, so rather than sign-extending it, we're better off initially interpreting memory results as zero-extended bytes in the range 0:+255, not -128:+127.

Quote:
 Originally Posted by retroben To think,I learned hex all on my own,not in school.
Doesn't surprise me. It's at least what I did.