My understanding of x86 registers say that each register can be accessed by the entire 32 bit code and it is broken into multiple accessible registers.
In this example EAX being a 32 bit register, if we call AX it should return the first 16 bits, and if we call AH or AL it should return the next 8 bits after the 16 bits and AL should return the last 8 bits.
So my question, because I don't truly believe is this is how it operates. If we store the 32 bit value aka EAX storing:
0000 0100 0000 1000 0110 0000 0000 0111
So if we access AX it should return
0000 0100 0000 1000
if we read AH it should return
0000 0100
and when we read AL it should return
0000 0111
Is this correct? and if it is what value does AH truly hold?
No, that's not quite right.
EAX is the full 32-bit value
AX is the lower 16-bits
AL is the lower 8 bits
AH is the bits 8 through 15 (zero-based)
So AX is composed of AH:AL halves, and is itself the low half of EAX. (The upper half of EAX isn't directly accessible as a 16-bit register; you can shift or rotate EAX if you want to get at it.)
For completeness, in addition to the above, which was based on a 32-bit CPU, 64-bit Intel/AMD CPUs have
RAX, which hold a 64-bit value, and where EAX is mapped to the lower 32 bits.
All of this also applies to EBX/RBX, ECX/RCX, and EDX/RDX. The other registers like EDI/RDI have a DI low 16-bit partial register, but no high-8 part, and the low-8 DIL is only accessible in 64-bit mode: Assembly registers in 64-bit architecture
Writing AL, AH, or AX leaves other bytes unmodified in the full AX/EAX/RAX, for historical reasons. i.e. it has to merge a new AL into the full RAX, for example. (In 32 or 64-bit code, prefer a movzx eax, byte [mem] or movzx eax, word [mem] load if you don't specifically want this merging: Why doesn't GCC use partial registers?)
Writing EAX zero-extends into RAX. (Why do x86-64 instructions on 32-bit registers zero the upper part of the full 64-bit register?)
Again, all of this applies to every register, not just RAX. e.g. writing DI or DIL merges into the old RDI, writing EDI zero-extends and overwrites the full RDI. Same for R10B or R10W writes merging, writing R10D leaving R10 independent of the old R10 value.
AX is the 16 lower bits of EAX. AH is the 8 high bits of AX (i.e. the bits 8-15 of EAX) and AL is the least significant byte (bits 0-7) of EAX as well as AX.
Example (Hexadecimal digits):
EAX: 12 34 56 78
AX: 56 78
AH: 56
AL: 78
| 0000 0001 0010 0011 0100 0101 0110 0111 | ------> EAX
| 0100 0101 0110 0111 | ------> AX
| 0110 0111 | ------> AL
| 0100 0101 | ------> AH
no your ans is Wrong
Selection of Al and Ah is from AX not from EAX
e.g
EAX=0000 0000 0000 0000 0000 0000 0000 0111
So if we call AX it should return
0000 0000 0000 0111
if we call AH it should return
0000 0000
and when we call AL it should return
0000 0111
Example number 2
EAX: 22 33 55 77
AX: 55 77
AH: 55
AL: 77
example 3
EAX: 1111 0000 0000 0000 0000 0000 0000 0111
AX= 0000 0000 0000 0111
AH= 0000 0000
AL= 0000 0111
No -- AL is the 8 least significant bits of AX. AX is the 16 least significant bits of EAX.
Perhaps it's easiest to deal with if we start with 04030201h in eax. In this case, AX will contain 0201h, AH wil contain 02h and AL will contain 01h.
The below snippet examines EAX using GDB.
(gdb) info register eax
eax 0xaa55 43605
(gdb) info register ax
ax 0xaa55 -21931
(gdb) info register ah
ah 0xaa -86
(gdb) info register al
al 0x55 85
EAX - Full 32 bit value
AX - lower 16 bit value
AH - Bits from 8 to 15
AL - lower 8 bits of EAX/AX
I've recently stumbled upon an interesting compiler code which I don't understand.
Take the following code:
unsigned char x;
...
x |= 127;
x |= 128;
For the first statement, the compiler generates:
or eax, 0x7f.
However, for the second statement, it becomes:
or eax, 0xffffff80
It seems that for values less than 127, one byte values are used whereas after 128 dword's are preferred.
Does anybody have any idea why this happens?
I reproduced this gcc 6.2 (latest I think).
I tried to post on the gcc mailing lists (gcc-bugs#gcc.gnu.org or gcc-help#gcc.gnu.org ) but I only got delivery failures.
Both instructions are 3 bytes wide as is apparent from the disassembly output:
83 c8 7f or $0x7f,%eax
83 c8 80 or $0xffffff80,%eax
The 83 / 1 is 32-bit register / memory with 8-bit sign-extended immediate value:
83 /1 ib OR r/m32,imm8 r/m32 OR imm8 (sign-extended).
Thus in effect it does change the non-visible part of the 32-bit register, but it doesn't matter. It is not less efficient than any other method. There is also no instruction that would not sign-extend the 8-bit immediate value, except those that operate with 8-bit register halves/quarters. But using this instruction makes it work the same way with other registers that are addressable with r/m32 but which cannot be accessed as individual bytes (edi, esi for example).
If:
(I believe the registers are adjacent to one another...)
A BYTE 0xB, 0d20, 0d10, 0d13, 0x0C
B WORD 0d30, 0d40, 0d70, 0hB
D DWORD 0xB0, 0x200, 0x310, 0x400, 0x500, 0x600
Then:
What is [A+2]? The answer is 0d20 or 0x15
What is [B+2]? The answer is 40 or 0x28
What is [D+4]? Not sure
What is [D-10]? Not sure
I think those are the answers but I am not sure. Since a WORD is 1 BYTE, AND DWORD is 2 WORDS, then as a result when you are counting the array of [B+2] for example, you should be starting at 0d30, then 0d40 (count two WORD). And [A+2] is 0d20 because you are counting two bytes. What am I doing wrong? Please help. Thank you
EDIT
So is it because: Taking into account that the first value of A,B, and D are offsets x86 is little endian... A = 0d10, count 2 more from there B...bytes (in decimal) = 30,0,40,0,70,0,11,0 B is 0d40, count 2 more bytes from that D...bytes (in hex) = 0x200, 0,0,0,...0,2,0,0,...0x10,3,0,0,...0,4,0,0,...0,5,0,0,...0,6,0,0 D is 0x200. Count 4 bytes from there. Count 10 bytes backwards from 0xb0. So wouldn't [D-10] be equal to 0x0C? Thank you
Also if I did [B-3], would it be 0d13? I was told it actually is between 0d10 and 0d13 such that it will be 0A0D and due to little endian will be 0D0A. Is that correct? Thank you!!
EDIT
WORD are 2 BYTEs. DWORD are two WORDs ("D" stands for "double"). QWORD is 4*WORD (Quad).
Memory is addressed in bytes, ie. content of memory can be viewed as (for three bytes with values: 0xB, 20, 10):
address | value
----------------
0000 | 0B
0001 | 14
0002 | 0A
WORD then occupies two bytes in memory, on x86 the least significant byte goes at lower address, most significant is at higher address.
So WORD 0x1234 is stored in memory at address 0xDEAD as:
address | value
----------------
DEAD | 34
DEAE | 12
Registers on x86 are special tiny bit of memory located directly on CPU itself, which is not addressable by the numerical addresses like above, but only by the instruction opcode containing the number of register (in source their are named ax, bx, ...).
That means you have no registers in your question, and it makes no sense to talk about registers in it.
In normal assembler [B+2] would be BYTE 40, (bytes at B are: 30, 0, 40, 0, 70, 0, 11, 0). In MASM it may be different, as it's trying to work with "variables" considering also their size, so [B+2] may be treated as WORD 70. I don't know for sure, and I don't want to know, MASM has too many quirks to be used logically, and you have to learn them. (just create short code with B WORD 0, 1, 2, 3, 4 MOV ax,[B+2] and check the disassembly in debugger).
[A+2] is 10. You are missing the point that [A] is [A+0]. Like in C/C++ arrays, indexing goes from 0, not from 1.
Rest of answers can be easily figured out, if you draw the bytes on the paper (for example DWORD 0x310 compiles to 10 03 00 00 hexa bytes).
I wonder where you got 0x15 in first possible answer, as I don't see any value 21 in A.
edit due to new comments ... I will "compile" it for you, make sure you either understand every byte, or ask under answer which one is not clear.
; A BYTE 0xB, 0d20, 0d10, 0d13, 0x0C
A:
0B 14 0A 0D 0C
; B WORD 0d30, 0d40, 0d70, 0hB
B: ;▼ ▼ ▼ ▼
1E 00 28 00 46 00 0B 00
; D DWORD 0xB0, 0x200, 0x310, 0x400, 0x500, 0x600
D: ;▼ ▼ ▼ ▼ ▼ ▼
B0 00 00 00 00 02 00 00 10 03 00 00 00 04 00 00 00 05 00 00 00 06 00 00
Notice how A, B and D are just labels marking some address in memory, that's how most Assemblers work with symbols. In MASM it's more tricky, as it tries to be "clever" and keeps not only the address around, but also it knows the D was defined as DWORD and not BYTE. That's not the case with different assemblers.
Now [D+4] in MASM is tricky, it will probably use the size knowledge to default to DWORD size of that expression (in other assemblers you should specify, like "DWORD PTR [D+4]", or it is deduced from target register size automatically, when possible). So [D+4] will fetch bytes 00 02 00 00 = DWORD 00000200. (I just hope MASM doesn't recalculate also the +4 offset as +4th dword, ie +16 in bytes).
Now to your comments, I will torn them apart into tiny bits with mistakes, as while often it's easy to understand what you did mean, in Assembly once you start writing code, it's not enough to have good intention, you must be exact and accurate, CPU will not fill any gap, and do exactly what you wrote.
Can you explain how did you get 0d13 of A and through to 0d30 of B #Jester?
Go to my "compiled" bytes, and D-1 (when offset are in bytes) means one byte back from D: address, ie. that 00 at the end of B line. Now for D-10 count 10 bytes back from D: ... That will go to 0D in A line, as 8 bytes are in B array, and remaining two are at end of A array.
Now if you read from that address 4 bytes: 0D 0C 1E 00 = DWORD 001E0C0D. (Jester mixed up decimal 13 into 13h by accident in his final "dword" value)
each value in B will occupy two "slots" as you count back? And each value in A will occupy four "slots"?
It's other way around, two values in B will form 1 DWORD slot, and four values in A will form 1 DWORD. Just as "D" data of 6 DWORD can be treated also as 12 WORD values, or 24 BYTE values. For example DWORD PTR [A+2] is 1E0C0D0A.
first value of A,B, and D are offsets x86 is little endian
"value of A" is actually some memory address, I think I automatically don't mention "value" in such case, but "address", "pointer" or "label" (although "value of symbol A" is valid English sentence, and can be resolved after symbols have addresses assigned).
OFFSET A has particular special meaning in MASM, taking the byte offset of address A since the start of it's segment (in 32b mode this is usually the "address" for human, as segments start from 0 and memory is flat-mapped. In real mode segment part of address was important, as offset was only 16 bit (only 64k of memory addressable through offset only)).
In your case I would say "value at A", as "content of memory at address A". It's subtle, I know, but when everyone talks like this, it's clear.
B is 0d40
[B+2] is 40. B+2 is some address+2. B is some address. It's the [x] brackets marking "value from memory at x".
Although in MASM it's a bit different, it will compile mov eax,D as mov eax,DWORD PTR [D] to mimic "variable" usage, but that's specific quirk of MASM. Avoid using that syntax, it hides memory usage from unfocused reader of source, use mov eax,[D] even in MASM (or get rid of MASM ideally).
D...bytes (in hex) = 0x200, 0,0,0,...
0x200 is not byte, hexa formatting has that neat feature, that two digits pair form single byte. So hexa 200 is 3 digits => one and half of byte.
Consider how those DWORD values were created from bytes.. in decimal formatting you would have to recalculate the whole value, so bytes 40,30,20,10 are 40 + 30*256 + 20*65536 + 10*16777216 = 169090600 -> the original values are not visible there. With hexa 28 1E 14 0A you just reassemble them in correct order 0A141E28.
D is 0x200.
No, D is address. And even [D] is 0xB0.
Count 10 bytes backwards from 0xb0. So wouldn't [D-10] be equal to 0x0C?
B0 is at D+0 address. You don't count it into those 10 bytes in [D-10], that B0 is zero bytes beyond D (D+0). Look at my "compiled" memory and count bytes there to get comfortable with offsets.
For example in IA-32 instructions.
0x00401000 = 0x8B
0x00401001 = 0x75
0x00401002 = 0xF0
0x00401003 = 0x03
0x00401004 = 0xD1
0x00401005 = 0x8D
I have those codes in my process and when I readprocessmemory from 0~5,
disassembler knows that 0x8B 0x75 0xF0 is one instruction.
8B75 F0 = MOV ESI,[EBP+0xF0]
But, what if I read it from 1~5. I will miss 0x8B from one instruction.
Will disassembler skip it?
If the disassember starts with 0x75 then it's going to try to interpret it as an instruction code. If it can't, it will show it as a data byte in your code space and move on to the next byte. – lurker
I have a variable defined in C on a PIC24
Let's say the name of the variable (in the C file) is The_Number_Of_Bytes
In the PIC24 C code, it is defined like this....
unsigned long The_Number_Of_Bytes=0; // number of bytes in buffer
I'm going to be called when an array of bytes named DATABUF01 will contain The_Number_Of_Bytes bytes (sorry for the implied redundancy) and I will need to make sure that I do that many bytes, exactly, and then stop.
I'm pretty confident that the number will be less than 65535, so why it is an unsigned long is for other discussions. For now, I want to know; which is the high order word and which is the low order word ? (For that matter, is long a 32 bit number in PIC24 C ?)
Could somebody tell me What will be in W2 and W3 in this example ?
Mov.W #_The_Number_Of_Bytes, W1 ;From the dispatcher
Mov.W [W1++], W2 ;My question: Hi Order or Low Order ?
Mov.W [W1], W3 ;My question: Hi Order or Low ?
Mov.W #_DATABUF01, W4 ;The Start
Mov.B [W4++], W5 ;First byte...
: ;Whatever
: ;Whatever
: ;Whatever
Could someone please confirm or correct my thinking about Hi / Low order of the unsigned long int ?
EDIT commenter requested this. May answer the question (comments are mine)
Requested comment, The size appears to be 4 bytes, from this...
45: unsigned long i=0;
0AB6A B80060 mul.uu 0x0000,#0,0x0000 ;make a zero
0AB6C 980710 mov.w 0x0000,[0x001c+2] ;no clue which word
0AB6E 980721 mov.w 0x0002,[0x001c+4] ;aha, if I made it 1 or 2, I'd know
46: unsigned int Fischer;
47:
48: Fischer = sizeof(i);
0AB70 200040 mov.w #0x4,0x0000 ;So it must be 4
0AB72 780F00 mov.w 0x0000,[0x001c] ;okay, it's a 4 byte number
49:
Here's a snippet from MPLAB C Compiler for PIC24 MCU's User's Guide:
5.3 DATA REPRESENTATION
Multibyte quantities are stored in “little endian” format, which means:
The least significant byte is stored at the lowest address
The least significant bit is stored at the lowest-numbered bit position
As an example, the long value of 0x12345678 is stored at address 0x100 as follows:
0x1000x1010x1020x103
0x78 0x56 0x34 0x12
As another example, the long value of 0x12345678 is stored in registers w4 and w5:
w4 w5
0x56780x1234
you can also view the assembly for a program to try to get an idea of how their compiler does it... for instance:
int main(int argc, char** argv)
{
long i = 56;
long j = i;
return 0;
}
becomes... ( xc16-gcc -S main.c )
.file "/Users/grady/MPLABXProjects/testpic24.X/main.c"
.section .text,code
.align 2
.global _main ; export
.type _main,#function
_main:
.set ___PA___,1
lnk #12
mov w0,[w14+8]
mov w1,[w14+10]
mov #56,w4
mov #0,w5
mov.d w4,[w14]
mov.d [w14],w4
mov w4,[w14+4]
mov w5,[w14+6]
clr w4
mov w4,w0
ulnk
return
.set ___PA___,0
.section __c30_signature, info, data
.word 0x0001
.word 0x0000
.word 0x0000
; MCHP configuration words
.set ___PA___,0
.end