Re: Constructing a relocation page table

From: Marko Mäkelä (
Date: 2003-04-29 08:39:02

On Mon, Apr 28, 2003 at 09:30:28PM +0200, Daniel Kahlin wrote:
> I use the same trick for over5.  Assembling is so fast nowadays that it is 
> no problem assembling the same file twice.   There is a small utility 
> (tlrreloc) included in the over5-archive (compilable on unix-like 
> systems).

Thanks, I'll have a look at this.  A build-dependency on the C compiler
is not that bad.

> Archive here:

Now also at

Ullrich van Bassewitz:
> Both methods may be more "intelligent" than assembling the binary twice,
> but I doubt they're easier.

You are probably right.

> A combination of 1. or 2. together with some limit to the supported
> relocations will probably give the smallest code size.

Well, I think that 256 bytes is a reasonable limit.  It looks like I
will apply Daniel's tool, since it is in principle compatible with any
assembler tool.

André Fachat:
> I guess you mean "is out of the question" :-)

Well, it almost is, since I did a lot of work to refactor and port the
code from DASM (whose license is non-free according to the Debian Free
Software Guidelines) to xa.

There are two annoying bugs that I have noticed in xa.  First, comments
are not only terminated by newline but also by a colon.  This could be
worked around with the -M command line option.  Second, macro names seem
to be forbidden in comments (maybe they are expanded there).

Cameron Kaiser:
> I know, it's on my rotating project list. Someone submitted a number of 
> generic patches which I need to incorporate, although I still want to
> rewrite the whole thing in Perl if possible.

Why make the tool dependent on a multi-megabyte package?  Well, maybe
it's not an issue these days, as Perl can be installed easily on any
modern system, including Win32.

Larry Anderson:
> You might want to take a look at Supermon for the PET, It uses a
> relocating loader based on the value of the upper limit of the free memory.

Thanks for the hint, I'll have a look at it.

> As long as the object code isn't self modifying

Self-modifying code shouldn't be a problem, unless there is something
lda #<address_within_the_code
sta vector
lda #>address_within_the_code
sta vector+1
or "double indirection" where a self-modified code modifies some code.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.