Message board for the users of flat assembler.
> Main > Using a 16bits op-code in 32bits environment (flat model)
SoLo2 10 Mar 2007, 16:47
I wish to use the instruction/op-code:
mov bx,var var db 0
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
Is this possible?
Last edited by SoLo2 on 10 Mar 2007, 23:42; edited 1 time in total
|10 Mar 2007, 16:47||
LocoDelAssembly 10 Mar 2007, 17:08
mov bx, var and $ffff
But you are asking for problems using only the lower 16 bits of addresses on 32 bit environment
|10 Mar 2007, 17:08||
DOS386 10 Mar 2007, 20:49
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 ...
Bug Nr.: 12345
Title: Hello World program compiles to 100 KB !!!
Status: Closed: NOT a Bug
|10 Mar 2007, 20:49||
SoLo2 10 Mar 2007, 23:40
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.
|10 Mar 2007, 23:40||
LocoDelAssembly 11 Mar 2007, 01:33
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).
|11 Mar 2007, 01:33||
SoLo2 13 Mar 2007, 17:00
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
|13 Mar 2007, 17:00||
SoLo2 10 Apr 2007, 04:44
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.
|10 Apr 2007, 04:44||
Hayden 10 Apr 2007, 05:54
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
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?
|10 Apr 2007, 05:54||
MazeGen 10 Apr 2007, 06:35
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
db 67h mov ax, [ds:bp+di]
|10 Apr 2007, 06:35||
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.