32 bit Flat segment 
Author Message
 32 bit Flat segment

   I am writing a program in which a single code segment overlapping
a single data segment will span the entire linear address space (not
exactly original).

   The actual data and code that derives from my source code will
all be loaded at the 16 megabyte point within the linear address
space.  Everything in the first 16Mb is set up at run time.  None
of it comes from the load image (obviously I have to write my own
loader as well).

   The hard part is getting code destined for offset 16Mb linked
at the beginning of the image.

   I know the common solution to this problem is to have the flat
segment start at a base of 16Mb.  Then the first 16Mb of linear
space are addressed as negative offsets within the flat segment.
For my use, this would be a very ugly solution.  I really want
offset zero in the segment to correspond to linear zero.

Solution 2:  Put an "org 16*1024*1024" at the beginning of the
source code and let tlink generate 16Mb of zeroes in the image
file.  Then just copy the desired image out of the massive EXE
file and discard the rest.  There are two problems:  First, tlink
takes a long time to write out 16Mb of zeroes.  Second, there is
a bug in tlink.  The general process would work perfectly for 4Mb.
(I tried it and the desired image appears 4Mb plus 512 bytes into
the EXE file).  But at 16Mb it doesn't work.  TLINK produces an
EXE with 16MB of zeroes followed a nonzero image in the right place;
But that image contains garbage, not the correct contents.

Solution 3:  Write an OBJ patcher to run after tasm but before
tlink and fix it all.  The patcher would find every 32 bit "fixup"
which is not "self relative" and add 16Mb to the corresponding
location in the LEDATA or LIDATA record.  Assuming I have only
one 32 bit segment and it is declared "PUBLIC", tasm cannot
generate any code depending on offsets within the segment without
using 32 bit fixups.

Questions:

Will it work?

Is there an easier way?

Are other people running into similar problems? (Should I post
the C source code to the OBJ patching program somewhere?)



Mon, 12 Jan 1998 03:00:00 GMT  
 32 bit Flat segment

Quote:

>    I am writing a program in which a single code segment overlapping
> a single data segment will span the entire linear address space (not
> exactly original).

You have a somewhat novel approach, normally the 386 isn't used this way.
Note that the only patches are going to be to references to your data
segment.  Shame, if it was a 68000 you could get around this whole
problem rather easily.  You'd just point an address reg at your data
and write your code to be relocatable... you could do something similar
on the 386 but the lack of registers is likely to hamper you.  
        The 386 wasn't designed for this type of thing but here's something
that may work.  Write your normal data seg before your code seg and
group them together, this way code seg offsets can be gotten from the
base of the group if you need them.  Now add an extra data seg:

highdata        segment public at 0
        org     16MB

and make a copy of all your normal data declarations in this seg, less
initializers.  You HAVE to make sure the offsets from 16MB are the same
as the offsets in your actual data seg or you'll get problems.

assumes ds:highdata

should get the assembler to use the 16MB offsets; you'r not worried about
the code segment because it does everything relative unless you are using
far jumps/calls.  I'm guessing you're not.  Of course at power-up time
if you have any pointers to your group within your data
seg you'll have to patch them... or you have to add 16MB by hand when
you're codeing the data declarations.
        You could automate the process of generating the AT seg, have
a seperate file with your data seg and have a program that parses it
and generates the AT seg... then config your make file appropriately.
However unless your data seg is going to be changed an awful lot it's
probably just as easy to do it by hand.  The only real problem you'll
run into is allocating space for strings...

David

Quote:

>    The actual data and code that derives from my source code will
> all be loaded at the 16 megabyte point within the linear address
> space.  Everything in the first 16Mb is set up at run time.  None
> of it comes from the load image (obviously I have to write my own
> loader as well).

>    The hard part is getting code destined for offset 16Mb linked
> at the beginning of the image.

>    I know the common solution to this problem is to have the flat
> segment start at a base of 16Mb.  Then the first 16Mb of linear
> space are addressed as negative offsets within the flat segment.
> For my use, this would be a very ugly solution.  I really want
> offset zero in the segment to correspond to linear zero.

> Solution 2:  Put an "org 16*1024*1024" at the beginning of the
> source code and let tlink generate 16Mb of zeroes in the image
> file.  Then just copy the desired image out of the massive EXE
> file and discard the rest.  There are two problems:  First, tlink
> takes a long time to write out 16Mb of zeroes.  Second, there is
> a bug in tlink.  The general process would work perfectly for 4Mb.
> (I tried it and the desired image appears 4Mb plus 512 bytes into
> the EXE file).  But at 16Mb it doesn't work.  TLINK produces an
> EXE with 16MB of zeroes followed a nonzero image in the right place;
> But that image contains garbage, not the correct contents.

> Solution 3:  Write an OBJ patcher to run after tasm but before
> tlink and fix it all.  The patcher would find every 32 bit "fixup"
> which is not "self relative" and add 16Mb to the corresponding
> location in the LEDATA or LIDATA record.  Assuming I have only
> one 32 bit segment and it is declared "PUBLIC", tasm cannot
> generate any code depending on offsets within the segment without
> using 32 bit fixups.

> Questions:

> Will it work?

> Is there an easier way?

> Are other people running into similar problems? (Should I post
> the C source code to the OBJ patching program somewhere?)



Mon, 12 Jan 1998 03:00:00 GMT  
 32 bit Flat segment
The description you gave in your e-mail response was incorrect.  TASM
works just fine, no matter *HOW* you use the 386.  It's ***TLINK*** that
has the bug.

Secondly, using the 386 in a flat memory model is not at all novel.  Intel
uses it.  Microsoft uses it (WinNT and Windows 95 plus Win32s uses it),
IBM uses it (first to use it in commercial product: OS/2), MMURTL uses it,
ORCA (my OS still under development) uses it, LINUX and every other UNIX
clone out for the PC uses it, many DPMI servers use it to set up virtual
machines, EMM386 uses it to simulate EMS, etc.

In fact, you'll note that in the 386 programmers reference manuals, *ALL*
protected-mode code examples, except the 80286 code, whether it is
initialization, debugging support, etc., assume a flat memory model with
xS:0000h being at 00000000h physical.  Any memory relocations uses within
the manuals use the 386's paging mechanism...not segmentation.

Writing portable code for the 386 is actually easier than writing for the
68K series of processors.  That's because most 386 instructions,
especially near functions, are IP or EIP relative.  This is not the case
with the 680x0 series, where you must manually tell the assembler to use
the xx(PC) addressing mode (although Bcc and BRA in both .S and .L forms
help a little bit).  Nonetheless, I still prefer the 68000 simply because
it doesn't have any of this segmentation BS.

Just my 32-bits worth..

Samuel A. Falvo II
Cosysop, ProNET BBS
Owner, Falvosoft

Falvosoft
Custom Software for MS-DOS and Microsoft Windows
488 Tryon Road
Utica, NY  13502



Mon, 26 Jan 1998 03:00:00 GMT  
 32 bit Flat segment

Quote:

> The description you gave in your e-mail response was incorrect.  TASM
> works just fine, no matter *HOW* you use the 386.  It's ***TLINK*** that
> has the bug.

> Secondly, using the 386 in a flat memory model is not at all novel.  Intel
> uses it.  Microsoft uses it (WinNT and Windows 95 plus Win32s uses it),
> IBM uses it (first to use it in commercial product: OS/2), MMURTL uses it,
> ORCA (my OS still under development) uses it, LINUX and every other UNIX
> clone out for the PC uses it, many DPMI servers use it to set up virtual
> machines, EMM386 uses it to simulate EMS, etc.

> In fact, you'll note that in the 386 programmers reference manuals, *ALL*
> protected-mode code examples, except the 80286 code, whether it is
> initialization, debugging support, etc., assume a flat memory model with
> xS:0000h being at 00000000h physical.  Any memory relocations uses within
> the manuals use the 386's paging mechanism...not segmentation.

> Writing portable code for the 386 is actually easier than writing for the
> 68K series of processors.  That's because most 386 instructions,

Not so.  On a 386 you just can't use PC-relative instructions to
access data, you must always do it relative to the base of a segment.
The PC-relative specification you are talking about is actually a feature
of the 68000 that is not implemented on the x86 series.

PC relative branches on the 68000 are similar to PC-relative branches
on the 386 though.  You can do something similar on both, that is use
a register to point to your data and do all your data accesses relative
to the register, but this is rarely done on a 386 because there are so
few registers while it is often done on a 68000 because there are
relatively many.

I agree, page tables and GDTs and IDTs are just too much work for anything
serious... although they make an extremely interesting toy to play with.
I like the 68000 better though.

David

- Show quoted text -

Quote:
> especially near functions, are IP or EIP relative.  This is not the case
> with the 680x0 series, where you must manually tell the assembler to use
> the xx(PC) addressing mode (although Bcc and BRA in both .S and .L forms
> help a little bit).  Nonetheless, I still prefer the 68000 simply because
> it doesn't have any of this segmentation BS.

> Just my 32-bits worth..

> Samuel A. Falvo II
> Cosysop, ProNET BBS
> Owner, Falvosoft

> Falvosoft
> Custom Software for MS-DOS and Microsoft Windows
> 488 Tryon Road
> Utica, NY  13502



Mon, 26 Jan 1998 03:00:00 GMT  
 32 bit Flat segment
Hello,
        I've finally found another user of MMURTL.
        I've got a question for you: I've booted up, but when the monitor
        program starts up, almost every thing comes up w/an error 0.
        Also, when I try to load the CLI, I get an error. I also get a
        hard disk error 632.
        Any help would be appreciated!
Thanks
Ernie Makris


Tue, 27 Jan 1998 03:00:00 GMT  
 32 bit Flat segment

 > Not so.  On a 386 you just can't use PC-relative instructions to
 > access data, you must always do it relative to the base of a segment.
 > The PC-relative specification you are talking about is actually a
 > feature of the 68000 that is not implemented on the x86 series.

 Yea, but if the segment you're using has its base at the base of memory, then
 _for all practical purposes_ you're not using the segment.

... Tagline fever is the primary symptom of the Blue Wave epidemic!!
___ Blue Wave/QWK v2.12



Tue, 27 Jan 1998 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Flat Real Mode Stack and 32-bit Code Segment Issues

2. TASM and far jumps from 16-bit segment to 32-bit segment

3. 32-bit addr in 16-bit segments - help!!!

4. 16-bit to 32-bit segments

5. Division 32-Bit/32-Bit with 16-Bit Register

6. 32 bit flat mode- info req

7. 32 bit segments; multitasking

8. i386 call gates in 32-bit segments ...

9. 32 bit segments

10. q: how do i use 32-bit segments?

11. Building 32 bit DLL from 32 bit EXE

12. 32 Bit ASM from 32 Bit Windows COBOL

 

 
Powered by phpBB® Forum Software