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.