From: Marko Mäkelä (marko.makela_at_hut.fi)
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: http://www.kahlin.net/daniel/over5/pub/over5-20021117.tar.gz
Now also at http://www.funet.fi/pub/cbm/crossplatform/transfer/Linux/
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
like
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.
Marko
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.