🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.asm.x86
Article #187

Re: 32bit Assembler ( figureing out relocations )

#187
From: Kazimir Kylheku
Date: Mon, 16 Jan 1995 22:14
100 lines
6312 bytes
In article <3f9kib$36o@flood.xnet.com>,
Erica A. Ramsey <lajade@xnet.com> wrote:
>Hello, I want to write an assembler. I notice that dos .exe files have
>relocation tables in them. This allows a module to relocated at load time.
>Well, I recently looked inside a 32bit protected mode program and they have
>relocation tables too. Well, i want to create a 32bit assembler with C
>extentions, and I guess, as I can see now, i'll have to maintain a relocation
>table too. The relocation table has address of items to be relocated at
>load time.
>
>I really don't see why a relocation table is necessary for 32bit protected
>mode or even dos programs!!! the offsets within the modules themselves
>don't change, regardless of the address the module was loaded at!!!

You are right. Relocation tables date back to the 1960's - before many
computers had virtual memory.

In protected mode, you can run each program at the same logical
address, either through segmentation or through paging.

>The only use of relocation tables for dos .exe files, I think, is that if
>one is using far pointers. The same for 32bit protected mode programs,
>relocation is only needed if the program uses 48bit far pointers; remember,
>in 32bit protected mode a far pointer is 16bit selector plus 32bit offset.
>If I say ahead time that one cannot use far pointers then  I should be
>fine; ie, I will not need relocation tables. Or I could be wrong, I'm so
>confused help!

No, 48 bit far pointers are not used in the same way in the 386 as in
the 8086.  Keep in mind that segments are *required* in the 8086 to
reach the entire address space, whereas the physical address space in
the 386 is entirely addressable by an offset.

>How do I know which items should be relocatable ? 'call' instructions

You are also forgetting that you can achieve segment relocation by
changing the values of the descriptors. The selectors shouldn't have
to change.  A program can contain a statement like "CALL
0001:000001FD".  This simply means call the logical address 1FD within
whatever segment is referenced by selector 0001. Change the descriptor
for 0001, and you point the segment reference somewhere else, without
changing the code.

It's not necessary to segment your code or your data structures,
however - it only makes things more complicated than they need to be.
With a simple 4GB flat memory model you can address and manage all of
your memory just as well.

As an example, the HP-UX operating system (for HPPA RISC machines)
divides the virtual address space into 1-GB quadrants. Code goes into
quadrant 1.  Data into quadrant 2. Shared libraries go into quadrant 3
(I think).  Most likely, the OS code can be seen in quadrant 4. It's
rather a neat division.

When the CPU is switched from one process to another, the OS switchs
to a different page table that points to different code and data, but
keeps the same aliases for shared references, such as the libraries or
OS code.

>shouldn't need to be relocated because 'call' instructions are relative
>from pc counter; correct? conditional jumps shouldn't need to be relocated
>because they are also relative from pc counter. But, jmp instructs
>and variables would have to be relocatable because they are absolute
>addresses in some cases and in the other cases they need to relocated
>because the datum of data segment has changed. is this correct? gimme
>more help! please.

Again, this is true of the 8086, but in the 386 protected mode, you
simply update the segment descriptor tables, and leave the selectors
alone.

>Is a link phase really necessary ? Can't I just create exe modules? I
>don't plan to have libraries or anything.

If all you want is to take a single program file and produce machine
code, you can have your compiler/assembler produce the binary image
directly. If you restrict yourself thus, the link-edit phase can be
dispensed with.

I don't think that the EXE format can support protected mode programs.
You can write a a DOS extender as an EXE file, and have the extender
set up the machine for running your 32-bit protected mode program.

>I have gnu assembler source from binutils. does anyone have any
>experience porting gas to dos ?

Yes, DJ Delorie does. Have you looked that the DJGPP package? It's a
port of the GNU development tools to DOS and comes with an extender
that sets up a protected-mode environment for your executables. It
automatically sets up demand paging, so you can easily run programs
that outstrip your physical memory.

The way it's set up is that you run a program called GO32.EXE, which
sets up the environment for your executable and then loads & runs it
(actually it page-faults it in on demand). There are various options
for combining GO32 with the a.out executable, so that the user can run
a simple .EXE file instead of typing "GO32 <program>" Regardless of
the invocation method, the .EXE headers only affect the GO32 extender,
not the image of your a.out executable. GO32 executables always start
at the same logical address, thus absolute references are not a problem.
Technical Details
Message-ID: <3fer4rINN25u@keats.ugrad.cs.ubc.ca>
Path: arc1-ca.pugleaf.net!nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!ub4b!EU.net!howland.reston.ans.net! gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!cs.ubc.ca!keats.ugrad.cs.ubc.ca!not-for-mail
References: <3f9kib$36o@flood.xnet.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 11318c,14c198d00592d0c8
X-Google-Attributes: gid11318c,public
X-Google-Thread: 10f6aa,14c198d00592d0c8
X-Google-Attributes: gid10f6aa,public
X-Google-Thread: 110292,14c198d00592d0c8
X-Google-Attributes: gid110292,public
X-Google-Thread: 102bfa,14c198d00592d0c8
X-Google-Attributes: gid102bfa,public
X-Google-Thread: 114917,14c198d00592d0c8
X-Google-Attributes: gid114917,public
X-Google-ArrivalTime: 1995-01-17 00:54:30 PST
Path: arc1-ca.pugleaf.net!nntp.gmd.de!dearn!blekul11!idefix.CS.kuleuven.ac.be!ub4b!EU.net!howland.reston.ans.net! gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!cs.ubc.ca!keats.ugrad.cs.ubc.ca!not-for-mail
From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
Newsgroups: comp.lang.asm.x86,comp.sys.intel,alt.msdos.programmer,comp.os.msdos.programmer,gnu.gcc.help
Subject: Re: 32bit Assembler ( figureing out relocations )
Date: 16 Jan 1995 14:14:51 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Lines: 103
Message-ID: <3fer4rINN25u@keats.ugrad.cs.ubc.ca>
References: <3f9kib$36o@flood.xnet.com>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca