| |
| |
| |
|
Comments:
<0> What is the size of an entry on an x86 stack?
<1> depends on cpu mode
<0> I ***ume 32 bit
<1> t'is usually 16 bits in RM
<1> 32-bit in modern OSes using PM32
<1> 64-bit on modern OSes in 64-bit moe
<2> which segment sets the default address and/or operand sizes for an instruction?
<2> I'm wondering, since both code and data descriptors have the USE16/USE32 (B) bit.
<2> does anyone know if there is a way to override the displacement size in nasm?
<3> suiraM: what does that mean?
<3> suiraM: are you saying you want to use disp32 addressing, when nasm is choosing disp8?
<2> for example.
<2> since nasm doesn't support the notion of overwriting code, I can't do something like:
<2> mov eax, [esi+0xfffff]
<2> org $-f
<2> dd 4
<2> Of course, I could ***emble it manually with db and dd, but there's a reason why I'm using an ***embler and not an octal editor X-D
<2> These alternate encodings are useful for stuff like doing alignment of branch targets that are also part of the code stream, or making patchable displacements.
<4> osdev
<4> oops
<5> is there any x86 instruction which effects both eax and ebx?
<2> anyone here know whether the address and operand sizes on x86 are set by the segment being referenced, or the code segment? also, whether these are controlled by the same segment or not?
<6> suiraM: doesn't it depend on whether you are in real mode or protected mode?
<6> Izak: popa
<5> lindi-: wow, nifty, I didn't think about it :)
<6> Izak: why do you need it? ;)
<5> lindi-: optimization :)
<6> Izak: writing compiler?
<5> lindi-: not yet, but reading (:
<5> lindi-: not good enough, any other instructions?
<6> libdisasm or XDE has a list
<5> http://bastard.sourceforge.net ?
<2> lindi- I'm talking about pmode.
<6> libdasm is better for realmode stuff
<6> Izak: are you writing it for protected mode?
<5> lindi-: yup
<1> suiraM: it's determined by D bit in code segment descriptor
<2> ok, so the D bit in the data segment descriptors is entirely superfluous?
<1> suiraM: except for implicit stack accesses, which are determined by D bit in stack segment
<1> no, it's used for stacks
<2> ok.
<1> push eax will use esp if ss.D = 1, sp otherwise
<2> and will I need the operand size prefix to push ax then?
<2> or will that part be determined by cs.D ?
<1> in all other cases, address size is determined by cs.D, xor presence of 0x67 prefix
<1> operand size is determined by cs.D, xor presence of 0x66 prefix
<2> ok, thanks.
<1> push eax will need 0x66 if CS.D == 0
<2> I have a feeling I still have a ways to go before I start typing up kernels in octal ;)
<2> I take it I still need 0x66 for mov ebp, esp (not trying to be dense, just don't want to have to ask again later if surprised)
<1> mov ebp, esp == 0x66 0x8... if CS.D == 0
<1> but, why do you need to move esp to ebp?
<2> hmm... also begs the question of stack-relative EAs; are displacements and SIB bytes treated according to ss.D, or are they treated according to cs.D ?
<1> cs.D
<2> ok, great :)
<1> ss.D is only used for implicit stack accesses
<1> like in push/pusha/pushf
<2> ah, not for mov ax, [bp+4] and the like?
<1> call/ret/iret
<1> no, those are only dependent on CS.d
<2> ok. makes sense.
<1> not sure what's up with leave and enter... and possibly other weird stuff
<1> brb
<2> thanks :)
<0> I have a question...why is mov always referred to as movl ?
<0> I've noticed this with quite a few other instruction as well.
<7> PuppiesOnAcid: l for long
<0> So what is the difference between the two?
<7> you use it when you're doing 32-bit stuff, i believe
<2> puppies; it's an artifact of AT&T syntax.
<2> puppies; they append the operand length to the mnemonic _in addition_ to using the appropriate register name.
<2> puppies; so what would, in Intel syntax, be "MOV AL, 0", "MOV AX, 0" or "MOV EAX, 0" would be "movb $0, %al", "movw $0, %ax" or "movl $0, %eax" in AT&T syntax.
Return to
#asm
or
Go to some related
logs:
devdsp no such device
kororaa coldplug block udev
#web
install rpm utility ubuntu
the gimp how to justify
#web
#centos
debian 82573V install
gentoo Win32 LoadLibrary failed to load: avisynth.dll
mason request_args empty
|
|