In most instances a byte is indeed 8 bits. Some platforms may define a bit as being more than 8 bits, but in ALL IBM PC based platforms operating with one of the 8086 family of processors a byte is always eight bits. When the processor goes to fetch a byte, it will actually fetch 8 bytes or 32 bits. All modern CPU fetches are 32 bits no matter what, even in real mode although this is hidden somewhat.
So the phrase 'convert 1 byte to 8 bits' is crazy because 1 byte is 8 bits.
<1|0>*(2^0)
<1|0>*(2^1)
<1|0>*(2^2)
<1|0>*(2^3)
<1|0>*(2^4)
<1|0>*(2^5)
<1|0>*(2^6)
<1|0>*(2^7)
Assembly language data types
BYTE is 8 bits
WORD is 16 bits
DWORD is 32 bits
QWORD is 64 bits - FPU and MMX
Now this all gets confusing in C when you move to 32-bit protected mode because unsigned int are DWORDs and not WORDs. Most stay away from these data types but I stick with them.
Fact is, in any given C program a WORD is always always always going to be 16 bits in assembly. See in 32-bit mode the compiler does some jiggy stuff and makes and unsigned int into 32-bits or a DWORD. But in 16-bit mode an unsigned int is a WORD. So the best way to think about your data types is not from a C standpoint but from an assembly standpoint IMO. Simply because C can be misleading when you move from 16 to 32 bit. Assembly data types never ever change and the native language of the CPU is assembly opcodes. So a movsd will ALWAYS move 32 bits no matter what. For instance besides the stack being different in the following function, notice how it is called from C.
__Add32 proc
ARG v1:DWORD,v2:DWORD
push ebp
mov ebp,esp
mov eax,[v1]
add eax,[v2]
pop ebp
ret
__Add32 endp
16-bit version
extern "C" unsigned long Add32(unsigned long v1,unsigned long v2)
32-bit version
extern "C" unsigned int Add32(unsigned int v1,unsigned int v2)
So the C data types 'int' and 'long' change from 32-bit to 16-bit. So you would think that a double in 32-bit is actually 128 bits, but alas its not. It's still 64 bits. Also the 'char' data type does not change with 16 bit or 32 bit. It is always 8 bits. Intel has always allowed programmers to access individual bytes and will continue to based on their tech manuals. A byte on an Intel/AMD machine is always 8 bits - even on IA64.
Because of the problems associated with int and long I stay away from these names for data types and instead use their assembly equivalents. If I was programming on another platform I would typedef the C data types to correspond to the appropriate CPU data type for it.
If you want a good example of how to screw up data types and make an easy principle very convoluted, simply examine windows.h and your head will spin for days. Personally, I've never had problems with my method
But you must remember that regardless of the sign of the number, it's the number of bits in the value, including the sign bit, that will determine its data type.
