[aprssig] A funny packet story/joke (The KISS guys will get it)

[Bill Herrmann]

At 06:46 PM 11/8/2005 -0800, Curt Mills wrote:
>Computer science people live by hexadecimal, at least if they do
>embedded programming.  Of course they used to use octal, where you

Curt didn't mention the reason and I thought some might be interested...

Both hexadecimal and octal are relatively easy to convert to and from 
binary. Decimal (base 10) is harder. So, computer science people use them 
to make the representation easier.

Octal represents three binary digits (bits) per digit.
Hexadecimal represents 4 bits per digit.
Octal was used most commonly till the word size on machines started 
stabilizing on multiples of 8 bits when hexadecimal made more sense.

Units:
bit - binary digit - the good old 1 or 0.
nibble - 4 bits
byte - 8 bits
word - depends on the machine, 2 bytes and 4 bytes are common,

At 09:04 PM 11/8/2005 -0500, Tad Burnett wrote:
>And 8000 < 7FFF (sometimes) ???

In signed 16 bit arithmetic it can.
The 0x part of 0x8000 is one way to say "the following number is a 
hexadecimal representation."

In most systems a signed number is indicated by the top or most significant 
bit (MSB) because it makes the physical implementation easier.

0x8000 would be -32768 decimal and 0x7fff would be +32767 in a 16 bit 
signed integer. 0x8000 is 1000000000000000 in binary. To understand why 
it's done that way add 1. The answer, of course, should be (and is) -32767. 
If you keep doing that you wind up with 0xffff which is 1111111111111111 
binary or -1 decimal. Add 1 to that and ignore the carry at the top and you 
just wound up with 0 which is, of course, the desired result.

To know whether 0x8000 is greater than or less than 0x7fff you have to know 
(a) if it's a signed integer and (b) what size the integer is. In other 
words on a small 8 bit microprocessor 0xFF might be -1 while on a 32 bit 
machine it would be 255 and -1 would be 0xFFFFFFFF. So, 0x8000 is -32768 
for a signed 16 bit integer.

Bill