LEA and square brackets. Another beginner question.
Mitchell Hashimoto
Like I said in my previous topic, I am just beginning to learn
assembly. I just got to the "lea" command. I've looked through and
noticed that the second operand in a lea command is always surrounded
by square brackets. Dr. Carter has pointed out that this is not the
same as dereferencing.
Example:
lea eax, [ebp - 8]
Are the square brackets a requirement? If they are not used for
dereferencing (which makes perfect sense for this command), then why
are they there? My guess is that they are like parenthesis in math,
saying "Compute this as a whole" sort of thing. But I want to ask
experienced assemblers to make sure.
Mitch
SpooK
In this particular notion of Intel-style syntax, "[]" (square brackets)
suggest that the value inside is a memory address (i.e. m16/m32)... as
opposed to "declaring" an immediate value or register.
The reason LEA is always surrounded by these square brackets, is due to
how LEA works. LEA requires a memory address value for the source
operand, and the destination operand is a 16/32-bit register (r16/r32).
As a point of technicality, you will always see those brackets when
using LEA... it might seem stupid/redundant/useless... but it allows
for programming consistency :)
Rod Pemberton
"Mitchell Hashimoto" <xmi...@gmail.com> wrote in message
news:1154801066.2...@h48g2000cwc.googlegroups.com...
Part of the problem is that you are applying high level language concepts to
assembly. Specifically, you are thinking that the syntax which indicates
the relative offset from some base address (i.e., due to segmentation) is:
1) an address (it isn't)
2) is automatically being dereferenced (it isn't)
The instruction, not the syntax, determines whether the effective linear
address is dereferenced. All but one instruction, i.e. 'lea', dereference
the effective linear address.
In a high level language, like C, variables are strictly typed. In IA-32
assembly, a register is "overloaded" from the C perspective. It can be
contain a number of different types: 32-bit unsigned value, 32-bit signed
value, a 16-bit unsigned value, 16-bit signed value, a 8-bit unsigned value,
a 8-bit signed value, or an 32-bit relative offset.
Rod Pemberton
Ratch
"Mitchell Hashimoto" <xmi...@gmail.com> wrote in message
news:1154801066.2...@h48g2000cwc.googlegroups.com...
You can try it yourself and see what happens if you do not use the
square brackets. Ratfch
Frank Kotler
Is that the floating-point version of Ratch? :)
Good point. We've got the laboratory right in front of us! Without
trying it, I'm going to guess Nasm says "invalid combination of opcode
and operands"... Yup! But that's just a syntax thing. In Gas you'd say
"leal (%ebp + %esi), %eax" or so.
There *is* a "law of nature" involved. The source operand - not
necessarily the second operand - has to be a valid effective address.
The square brackets are just "the way Nasm does it". I found "lea"
confusing because it looks like it ought to be "part of the group" with
lds, les, lss, etc. Completely different thing. "lea" looks like it
accesses memory, but it doesn't - just does arithmetic. It won't do
arbitrary arithmetic - has to be a valid effective address - but you can
still do some "tricks" with it that have nothing to do with memory...
(...inspired by some compiler-generated code Herbert showed me - I think
I got it right...)
Best,
Frank
global _start
section .data
number_string db '123', 10
section .text
_start:
nop
push number_string
call atoi
add esp, byte 4
mov ebx, eax
mov eax, 1
int 80h
atoi:
mov edx, [esp + 4] ; pointer to string
xor eax, eax ; clear "result"
.top:
movzx ecx, byte [edx]
inc edx
cmp ecx, byte '0'
jb .done
cmp ecx, byte '9'
ja .done
; we have a valid character - multiply
; result-so-far by 10, subtract '0'
; from the character to convert it to
; a number, and add it to result.
lea eax, [eax + eax * 4]
lea eax, [eax * 2 + ecx - 48]
jmp short .top
.done
ret
Eman
> There *is* a "law of nature" involved. The source operand - not
> necessarily the second operand - has to be a valid effective address. The
> square brackets are just "the way Nasm does it".
Paul A. Carter's book (i find it very good) doesn't accentuate
this for LEA in NASM. Meantime, NASM' primary document states
this explicitly in a separate paragraph.