Interpreting Assembly Code Comparison [duplicate] - memory

This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Confusing add command in x86 assembly
I would like to understand these two lines of Assembly:
8048d74: 03 44 9e fc add -0x4(%esi,%ebx,4),%eax
8048d78: 39 04 9e cmp %eax,(%esi,%ebx,4)
I think (%esi,%ebx,4) is an effective address of the form (BASE, INDEX, SCALE)
I believe the add command is taking the value at %eax, adding it to the value at [esi + ebx*4 + mem_location] and storing it in that same spot.
Then, the cmp instruction tests whether the value at [esi + ebx*4 + mem_location] is equal to the value at %eax.
So, this will return true only if one of the two values added is 0, right?

This appears to be AT&T format source code, in which the order is op source, dest. That means the first is adding the value at the effective address to eax. Then, the second line is comparing a second value to eax.

Related

How do we store large decimal/hex value in ARMs?

I run into a roadblock and not sure where to go from here. I know MOV can only store a maximum of 0-65535 in decimal. However, the value I'm trying to store is 30,402,460.
I was going to use MVN as some source mention that can store bigger number in this format:
MVN X9, #(num), #(num). However 30402460 / 110 = only equals 276,386 which is still above the decimal value of 65535 so I can't use MVN.
My question is; how do we store 30402460 to X9?
MOV is not a real instruction. It's an alias that will be turned into either MOVK, MOVN or ORR as appropriate. But each of those have their own constraints:
MOVZ can load an arbitrary 16 bits, left-shifted by 0, 16, 32 or 48 bits. So you can only use this for values with 48 bits of all zeroes.
MOVN does the same as MOVZ, but inverts the register value. So you can only use this for values with at least 48 bits of all ones.
ORR can construct a really complicated bitmask which, as best as I can tell, can be any sequence of consecutive runs of zeroes, ones, zeroes or ones, zeroes, ones, repeated by any power of two that is a dividend of the register width. So you can load values like 0xaaaaaaaaaaaaaaaa, 0xfffffff00fffffff and 0x18, but not values like 0x0 or 0x5.
The value 30402460 matches none of these constraints. The usual practice for loading such values is to use MOVZ followed by MOVK, the latter of which allows replacing 16 bits of a register without changing the other bits. So in your case:
movz x9, 0x1cf, lsl 16
movk x9, 0xe79c

Does ALU know about postfix notation?

As we all know, the ALU perform Arithmetic operation, but does the computer understand post-fix notation or not?
Assuming you mean Arithmetic/Logic Unit, no. The ALU does not understand any notation. It only understands instructions. So, for example, the machine code might include an instruction to "add R10 to R11 and store the result in R9," say (disassembled) ADD R9, R10, R11, but the machine code "notation" is understood by the Control Unit, not the ALU.
By the time the ALU receives the information, it is encoded in the form of various control lines being asserted. For instance, in the above example, the CU might assert control lines for "add," "input A is R10," "input B is R11," and "store result in R9." These lines determine how the ALU and the register file behave, and result in the operation desired.
Textual notation, such as 5 + 8 or (+ x 19) or x 19 15 + * or indeed ADD R9, R10, R11, is understood by software, doing processing at a much higher level than the ALU does. It is that software that interprets, say, postfix notation, and issues the instructions that cause the ALU to execute the desired operations.

Understand what a command does

I'm learning x86 syntax.
I've stumbled across this command which I don't seem to be sure what it does:
cmpl $0x0,%cs:0x6574
I know cmp just compares the difference and sets the flags. And the l to indicate that unsigned values are being compared.
My question is:
What are we comparing ?
The value in 0x0 against what value %cs:0x6574 ? cs register contains an address, should I add 0x6574 to it and extract the value ? something like:
mem[cs+0x6575]
Thanks in advance!
Assuming this is from real mode code it is default segment override. So instead of implicit DS use CS segment.
In real mode address calculation is a bit different. Value of segment is first multiplied by 16 and than offset is added.
So in your notation it will be
mem[16*cs+0x6575]

WinDbg callstack hexadecimal offset [duplicate]

This question already has answers here:
How to understand the call stack of Visual Studio?
(3 answers)
Closed 6 years ago.
what does the hexadecimal value (with the +) behind the function name stands for ?
00 012ff668 7795aa24 ntdll_778f0000!LdrInitShimEngineDynamic+0x726
01 012ff8a0 77956e84 ntdll_778f0000!WinSqmSetDWORD64+0x14e4
02 012ff8f4 77956cd0 ntdll_778f0000!LdrInitializeThunk+0x1c4
03 012ff8fc 00000000 ntdll_778f0000!LdrInitializeThunk+0x10
These numbers indicate offset from the nearest resolved function entry. The higher number WinSqmSetDWORD64+0x14e4 indicates you have symbol loading issues and Windbg used the export table to get the function name and generated the large offset based on the function names it got from the export table.

Poke opcodes into memory

Hi I am trying to understand whether it is possible to take instruction opcodes and 'poke' them into memory or smehow convert them to a binary program. I have found an abandoned lisp project here: http://common-lisp.net/viewvc/cl-x86-asm/cl-x86-asm/ which takes x86 asm instructions and converts them into opcodes (please see example below). The project does not go further to actually complete the creation of the binary executable. Hence I would need to do that 'manually' Any ideas can help me. Thanks.
;; assemble some code in it
(cl-x86-asm::assemble-forms
'((.Entry :PUSH :EAX)
(:SUB :EAX #XFFFEA)
(:MOV :EAX :EBX)
(:POP :EAX)
(:PUSH :EAX)
(.Exit :RET))
Processing...
;; print the assembled segment
(cl-x86-asm::print-segment)
* Segment type DATA-SEGMENT
Segment size 0000000C bytes
50 81 05 00 0F FF EA 89
03 58 50 C3
Clozure Common Lisp for example has this built-in. This is usually called LAP, Lisp Assembly Program.
See defx86lapfunction.
Example:
(defx86lapfunction fast-mod ((number arg_y) (divisor arg_z))
(xorq (% imm1) (% imm1))
(mov (% number) (% imm0))
(div (% divisor))
(mov (% imm1) (% arg_z))
(single-value-return))
SBCL can do some similar with VOP (Virtual Operations).
http://g000001.cddddr.org/2011-12-08
I learned that it can be done using CFFI/FFI for example the very simple asm code:
(:movl 12 :eax)
(:ret)
This will be converted to the following sequence of octets: #(184 12 0 0 0 195) which in hex it is: #(B8 C 0 0 0 C3). The next step is to send it to a location in memory as such:
(defparameter pointer (cffi:foreign-alloc :unsigned-char :initial-contents #(184 12 0 0 0 195)))
;; and then execute it as such to return the integer 12:
(cffi:foreign-funcall-pointer pointer () :int)
=> result: 12
Thanks to the experts in #lisp (freenode irc channel) for helping out with this solution.

Resources