[comp.sys.atari.8bit] Relocatable file format?

hoser@ucrmath.UUCP (Mark Houser) (08/19/88)

In the ICD product catalog (88-89) the SpartaDOS X cartridge states that the
"file loader supports relocatable files and symbolic linking".  What is the
format of the relocatable files which this loader supports? I want to write
a macro assembler/linker and I would like its relocatable files to conform
to whatever the "standard" format is on the Atari 8-bit for relocatable files.
I had already considered an object file format for use with a linker, but it
would be a better if I could use some sort of standard format which would be
able to take advantage of file loader of SpartaDOS X.  If there isn't a
standard, what is the format of the files that ICD is supporting?  Am I
misinterpretting what ICD means by "relocatable files and symbolic linking"?

Any information would be appreciated.

Mark Houser					|
Department of Mathematics and Computer Science	|  ucsd!ucrmath!hoser
University of California, Riverside		|

cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (08/20/88)

In article <387@ucrmath.UUCP>, hoser@ucrmath.UUCP (Mark Houser) writes:
> 
> I want to write
> a macro assembler/linker and I would like its relocatable files to conform
> to whatever the "standard" format is on the Atari 8-bit for relocatable files.

I think you're going to find that this is an in-house or "de facto," rather 
than "official," standard.  There is NO "official" relocatable file format;
Atari never supported or implemented any such thing, so it's pretty likely 
just ICD's brainchild.

Someone else on this net (was it John Dunning, of Kermit65 fame?  Forgive me
if it was someone else) mentioned to me a couple of months ago that he was 
trying to implement something along the lines of your idea: an assembler and
linker etc. to use, support, and manipulate relocatable code and files.  All
in all, I'll be glad to see it, but it sounds to me like it's going to be 
difficult, because of the 6502's lack of any PC offset register.  The idea of
relocatable code descended from mainframes and met the microprocessor indus-
try on its way up, so the "high end" micro CPUs can do this "no sweat."  On
the 6502, you'll have to relocate the code and resolve all address references
down to absolutes before ever giving control to the loaded code...  Like I 
said, I'll be impressed and GLAD to see this when it's ready!

Hope this helps.

  Chris Chiesa
    recent graduate, Ball State University, CS Dept. 
-- 
UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa 
cfchiesa@bsu-cs.UUCP                                           

jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (08/28/88)

    Date: 19 Aug 88 19:57:55 GMT
    From: bsu-cs!cfchiesa@iuvax.cs.indiana.edu  (Christopher Chiesa)

    In article <387@ucrmath.UUCP>, hoser@ucrmath.UUCP (Mark Houser) writes:
    >
    > I want to write
    > a macro assembler/linker and I would like its relocatable files to conform
    > to whatever the "standard" format is on the Atari 8-bit for relocatable files.

    I think you're going to find that this is an in-house or "de facto," rather
    than "official," standard.  There is NO "official" relocatable file format;
    Atari never supported or implemented any such thing, so it's pretty likely
    just ICD's brainchild.

I believe that's true.

    Someone else on this net (was it John Dunning, of Kermit65 fame?  Forgive me
    if it was someone else) mentioned to me a couple of months ago that he was
    trying to implement something along the lines of your idea: an assembler and
    linker etc. to use, support, and manipulate relocatable code and files.  All
    in all, I'll be glad to see it, but it sounds to me like it's going to be
    difficult, because of the 6502's lack of any PC offset register.  

Also true, but misses the point slightly.  The kind of relocatable code
I'm talking about is not code where you could pick 'those bytes there'
up and plunk them down someplace else and have them still run.  You
could do that, probably by adopting a convention about using someplace
in page 0 as a base register, but it'd be gross.
								      The idea of
    relocatable code descended from mainframes and met the microprocessor indus-
    try on its way up, so the "high end" micro CPUs can do this "no sweat."  On
    the 6502, you'll have to relocate the code and resolve all address references
    down to absolutes before ever giving control to the loaded code...  

Exactly.  In fact, this sort of paradigm is used all over the place.
(See the executable format for the Atari ST) It turns out that you can
make the loader pretty simple and fast if you pick the right format for
describing the relocation info.  That's tricky on the 8-bitters, because
the word length is not the same as the length of a pointer.  That means
that you end up trying to generate a byte in memory that's (for
instance) the high half of the address of a symbol AFTER it's been
relocated.  Blech.

What I have in mind is not quite that ambitious.  I'm building an
assembler that generates relocatable object modules, (those of you
who've hacked on ancient Xerox mainframes will notice my terminology
showing thru) and a linker that links the object modules together into a
non-relocatable executable image.  That's a much more manageable
project, I think, 'cause it removes the requirement that the code itself
be relocatable, but preserves the ability to run the code at any given
place in memory; all you need do is re-link with different base address.

									Like I
    said, I'll be impressed and GLAD to see this when it's ready!

It's coming; just taking its time.  (Despite my blithe statements, it
really is tricky to get right) Besides, I've had to take time off from
it to spend on my REAL job :-}