Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!STONY-BROOK.SCRC.SYMBOLICS.COM!jrd From: jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) Newsgroups: comp.sys.atari.8bit Subject: Re: Relocatable file format? Message-ID: <19880828154642.9.JRD@MOA.SCRC.Symbolics.COM> Date: 28 Aug 88 15:46:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 59 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 :-}