i wanted to generate some raw binary but for modern sse assembly
i took such function
ZeroMemorySSE:
mov edx, dword [esp+4]
mov ecx, dword [esp+8]
xorps xmm0, xmm0
loop11:
movdqu oword [edx], xmm0
add edx, 16
sub ecx, 16
jg loop11
ret
those bug eated a 30 minutes of writing
in short - when assembly this to win32 coff and disassembly i got such code
The 66 prefix is used in some SIMD encodings. MOVDQA and XORPD use it though, not MOVDQU or XORPS.
It is also used with other general purpose instructions to override the operand size (on 32-bit and 64-bit mode, it switches to 16-bit operand size, and in 16-bit mode it switches to 32-bit operand size)
67, on the other hand, when used in a 64-bit process, allows you to select 32-bit address size in certain situations which may be useful.
Encoding 8B: MOV Gv, Ev; both Gv and Ev respect the operandSize override. Since you're using a memory form of Ev, it also respects addressSize override. In this case you must remove the prefixes since it will cause the encoding 66 67 8B 54 24 to become "mov dx, word [Si+0x24]" instead, causing another catastrophic problem: your 04 will no longer be part of the instruction, and will be decoded as its own instruction. At that point your program will likely catastrophically fail since you've "derailed" the instruction pointer.
They are not obsolete, but if you use them wrong, it will cause undesirable results like Spiro said.
The 66 prefix is used in some SIMD encodings. MOVDQA and XORPD use it though, not MOVDQU or XORPS.
It is also used with other general purpose instructions to override the operand size (on 32-bit and 64-bit mode, it switches to 16-bit operand size, and in 16-bit mode it switches to 32-bit operand size)
67, on the other hand, when used in a 64-bit process, allows you to select 32-bit address size in certain situations which may be useful.
Encoding 8B: MOV Gv, Ev; both Gv and Ev respect the operandSize override. Since you're using a memory form of Ev, it also respects addressSize override. In this case you must remove the prefixes since it will cause the encoding 66 67 8B 54 24 to become "mov dx, word [Si+0x24]" instead, causing another catastrophic problem: your 04 will no longer be part of the instruction, and will be decoded as its own instruction. At that point your program will likely catastrophically fail since you've "derailed" the instruction pointer.
They are not obsolete, but if you use them wrong, it will cause undesirable results like Spiro said.
alright, could you answer me if the code generated in raw bin (seen as this jpeg picture) is 16 bit code or what? or is this 32 bit code to run in 16 bit mode? why nasm generated it such way? it would be strange if it would generate code that purpose is tu crash anywhere.. and if not crashing would it be able to really run sse code in 16bit mode or something ? (sorry if the questions is a bit indepth, but maybe someone will know this)
ps when disasembly it was bring
seem okay but do such hex is able to run on 32 windows?
some flag i think must be setted somewhere to treat this as
some 32-16 mode (as i suspect this is 32 bit code but with some
16 bit args by default)
probably this explains most of the think - i need to find some flag
to denay this 16 bit default
66 and 67 are superfluous 16-bit 8086 prefixes that you should remove when compiling for 32-bit machines.
If these are not executed in x86’s VM86 virtual mode they will be misinterpreted by the CPU and crash or cause undesirable results.
L. Spiro
if so i guess this code is unusable at all - is this code for 16 bit dos or something? - if so probably such dos code would crash on xmm cammands..
- i need to generate raw bin but proper 32 bit code
If you use NASM to output a raw binary it will assume 16-bit code for a DOS .com executable.
If you use NASM to output a raw binary it will assume 16-bit code for a DOS .com executable.
one thing is unclear, what is 16-bit mode , if this is 16 bit why it is using sse modern commands -it seem to be more like 32 with some tendency to 16 bit - or is this really 16 bit... :/
if someone could explain a bit tnx
tnx for answers, thing is more clear now
