Hello!

I wish to use the instruction/op-code:



This tries to load the offset register
bx with the relative offset of 'var'.
This instruction uses an opcode that
I wish to use in a "flat" mode Pentium
(32bits environment).

Is this possible?

But you are asking for problems using only the lower 16 bits of addresses on 32 bit environment

Code size below 64 KB ?

Using "Windows" ? Then "var" will be >$401000, far above 64 KB ,
no 16-bit offset possible ...

Let's say that the possibility of
setting start address 0 is... the
Pentium should permit this with
its virtual addressing.

Then, of course, my little program
is less than 64K.

Hum!?

In the case of Windows it's impossible because $00000000..$0000FFFF are all invalid addresses and there is some APIs that if you pass a pointer with a value less than $10000 them interpret it as an atom instead of a pointer to wathever it needs. Now, if you want to do it on a standalone binary then do it if you see some benefits of it, with a 386 and newer you can. If you just need to produce small binaries then I suggest you to use EBP based tricks to achieve that. Search for vid's paratrooper game on this forum as an example (but use EBP instead of BP).

What I had thought of this virtual memory
system that intel actually uses, is that when
doing an interrupt/system call/atomic/... it
would change virtually of space state.
So the system vectors are not refereable
from the programs' self memory descriptor.
It has to first change context and refer to
a more secure memory block.
This permits having programs virtually
starting always at $0 and possesing all the
memory for themselves. Although they
share the same system vectors in another
space.

I read
http://www.x86.org/articles/pmbasics/tspec_a1_doc.htm
by Robert Collins, and
thinking now again, I see that the
segments in protected mode
aren't what they used to be.

The full compatibility to the real
8086 is lost when using 32-bits mode.

So, although the old 8086 opcodes
are there, their use is dangerous or
forbidden if not running in real mode.
Because in protected mode the
segments are mere indexes to
descriptor tables of memory blocks
and not the physical addresses
they used to be.



Thanks, Intel.

footnote:

I've read that in 16-bit realmode useing 16:16 segment:offset style pointers it is possible to specify a 16:32 style segment:offset by using the address size overide byte 67h

this example is for 16bit realmode code on a 386 ( pointers are segment:offset NOT selector:offset )

mov ax, word [ds:bx] ; move word useing 16:16 style rm-pointer

mov ax, word [ds:ebx] ; move word useing 16:32 style rm-pointer

some complilers might need to be coded as

db 67h
mov ax, [ds:bx]

wich should assemble the same as mov ax, [ds:ebx]

can anyone shed some more light on this subject please?
anyone got some examples of this?

Yeah, you can easily use 32-bit pointers in real-mode on 386+ processor, but there is real no reason to do that since using an offset above 0FFFFh causes Segment Overrun exception.

It is not so straightforward because 16-bit memory operand codes doesn't match 32-bit ones. If you want to access [ds:ebx] this way, you should use