something wrong with masm6.1 documentation

[megabyte]

hi there, i've just started learning assembly and i get a couple o questions

1) how can i create an x86 segment with d=0 (16 bit operands and addresses) with 32 bit limit, that is the full 4gig.......since the masm assume by default that 16bit segments are gonna execute in real or v86 mode so he make  the offset 16 bit with the operands and the addresses......of course u still can do 32bit stuff but with the size prefixes, which will lead us to the second question

2)why this statement generates an error on the masm in 32 bit segment, actually in the flat mode, allthough it's totally legal to use 16 bit address in 32 bit segment and that's why x86 architacture get the address size prefix

                mov eax, [bx]

if my questions where posted before i hope anybody forward me the thread,

thx in advance for ur help

[MichaelW]

Hello megabyte, welcome to the forum.

In your first question you seem to be describing "unreal mode":

http://en.wikipedia.org/wiki/Unreal_mode

To clarify some of the wikipedia information, once unreal mode has been enabled loading a segment register from real mode will change the segment base, but not the segment limit. A major weakness of unreal mode is that most software that switches temporarily to protected mode and then back to real mode (some versions of HIMEM.SYS, the BIOS Extended Memory functions, etc) will disable unreal mode.

In answer to your second question, MASM will not encode instructions that "mix 16-bit and 32-bit offsets in an expression", I think because there is no good reason to do so. But you can encode such instructions manually, and the processor will accept them:

Code Select Expand


00401002 678B07     mov  eax,[bx]

But AFAIK in a normal Windows app executing an instruction that contains a 16-bit offset value will always trigger an exception.

[zooba]

Simple solution:

Code Select Expand

and ebx, 0000FFFFh
mov eax, [ebx]

:U

[hutch--]

There is a problem with this encoding anyway,

Code Select Expand


mov eax, [bx]


It is still an operand size mismatch and I know of no MOV opcode that will perform the action where a 16 bit address is loaded into a 32 bit register.

Its easy enough to encode,

Code Select Expand


xor eax, eax
mov ax, [bx]


You can try this action with zero extension,

Code Select Expand


movzx eax, WORD PTR [bx]


But it already makes the assumption that addressing is in 16 bit mode, not 32 bit.

For what you are after, I would get the Intel manuals for the possible architecture with x86 opcodes.

[zooba]

Code Select Expand


xor eax, eax
mov ax, [bx]


Code Select Expand


movzx eax, WORD PTR [bx]


These won't read a DWORD from the memory location though, they'll only read a WORD. You're better off to clear the top 16-bits of ebx and use the whole thing.

[hutch--]

The obvious is that a 16 bit address if you are using 16 bit addressing can read anything within its addressing range, all of 64k.

I guess our friend is trying to do the jump from real mode to protected mode for a system boot and in this context I would recommend NASM or FASM as they both can write mixed opcodes of this type.

[MichaelW]

It looks to me like mov eax, [bx] is a legitimate instruction, even in a 32-bit segment. I took the encoding from the Intel manuals, and I posted the disassembly, and then just assumed that it would work. I have now tested it by using an FS override to get the allowable offset into the 16-bit range.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    ASSUME fs:nothing

    mov     ebx, 2
    mov     eax, fs:[ebx]
    print uhex$(eax),13,10

    db      64h,67h,8Bh,07h   ;mov   eax, fs:[bx]
    print uhex$(eax),13,10

    inkey "Press any key to exit..."
    exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start


Code Select Expand


00000012
00000012
Press any key to exit...


But even if the assembler would assemble it directly, I can see no good reason to use this form of instruction in a 32-bit app, when you could just a well use a 32-bit register.

FWIW, both FASM and GAS will assemble mov  eax, [bx] correctly and without complaint, but GoAsm will return:

Code Select Expand


Error!
Only 32 bit register allowed as index register:-
mov   eax, [bx].


[megabyte]

thx a lot everybody for answering my questions, especially <MichaelW> for showing me a new way to write overrided instructions using the "DB" directive,

and back to my first question........i understand what is the unreal mode is, and what i'm talkin about is the same thing but in protected mode......

for instance u may need to process a lot of 16bit data, which will naturally force u to reset the D bit, so u can avoid the severe overhead of the prefixes, which may dramatically increase and slow down ur code, but at the same time u wana retain ur 4 gig segment limit..............
this is in protected mode not unreal mode since i'm using the D bit which is specified in the segment descriptor and used in the protected mode only..........

[MichaelW]

Why not just process the 16-bit data as 32-bit data? AFAIK for recent processors working with 16-bit data as 16-bit data involves inefficiencies beyond just the prefix overhead. See Mark Larson's optimization tutorial, available here:

http://www.website.masmforum.com/mark/index.htm

Or Agner Fog's Pentium Optimization document, available here:

http://www.agner.org/assem/

Or the IA-32 Intel Architecture Optimization Reference Manual, available here:

http://developer.intel.com/design/Pentium4/documentation.htm

[MazeGen]

megabyte, don't forget that using flat model in win32 environment, the memory area 0000-FFFF is prohibited because of trapping null pointers. I'm not an expert, but we probably can't use 16-bit operands and adresses for this reason. I'm also not sure if PE format enables such memory and operand model.

Probably for this reason are also prohibited instructions like mov eax,[bx] in masm, even though they can be legally used for accesing FS:.