flat assembler
Message board for the users of flat assembler.

Index > Main > Using a 16bits op-code in 32bits environment (flat model)

Author
Thread Post new topic Reply to topic
SoLo2



Joined: 09 Mar 2007
Posts: 14
SoLo2
Hello!

I wish to use the instruction/op-code:

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
(32bits environment).

Is this possible?


Last edited by SoLo2 on 10 Mar 2007, 23:42; edited 1 time in total
Post 10 Mar 2007, 16:47
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Code:
mov bx, var and $ffff    

But you are asking for problems using only the lower 16 bits of addresses on 32 bit environment
Post 10 Mar 2007, 17:08
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:
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 Shocked ,
no 16-bit offset possible ...

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 10 Mar 2007, 20:49
View user's profile Send private message Reply with quote
SoLo2



Joined: 09 Mar 2007
Posts: 14
SoLo2
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!?
Post 10 Mar 2007, 23:40
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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).
Post 11 Mar 2007, 01:33
View user's profile Send private message Reply with quote
SoLo2



Joined: 09 Mar 2007
Posts: 14
SoLo2
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.
Post 13 Mar 2007, 17:00
View user's profile Send private message Visit poster's website Reply with quote
SoLo2



Joined: 09 Mar 2007
Posts: 14
SoLo2
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.

Rolling Eyes

Thanks, Intel.
Post 10 Apr 2007, 04:44
View user's profile Send private message Visit poster's website Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden
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?
Post 10 Apr 2007, 05:54
View user's profile Send private message Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia
MazeGen
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.
Quote:
db 67h
mov ax, [ds:bx]

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

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
Code:
db 67h
mov ax, [ds:bp+di]
    
Post 10 Apr 2007, 06:35
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.