From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-05-23 00:01:43
Hi! On Mon, May 22, 2000 at 11:12:57PM +0200, Groepaz wrote: > well, the reason *why* i expected the linker to act like it does when "fill=yes" > is, that you can assign a memory adress to a segment. if the linker wont use > this value anyway, what should it be good for? like, if it will end up in one > clumsy binary anyway, why bother about having segments at all? I have explained it in some older mail, but here is it again: There is a difference between relocation and placement. The linker does both, but it is not the same. You may relocate a piece of code to run at address $1000 but place it at address $2000. The address given in the memory area statement is the relocation address. Code put into this area is relocated to run at the given address. The placement of the code is a result of several other statements and the load address of the resulting binary file. Most other 6502 development tools don't make a difference between relocation and placement (in fact, many available tools do not even support relocatable intermediate files). This may be the reason, why the concept looks strange on the first glance. > "fill=no" WOULD make sence incase you would write out the different segments > to seperated files and then link them together to a runable c64 exe with some > other tool. then again, why using a linker and write out tons of files that > you have to link together afterwards to run them... fill=yes would mean that you will *always* get a file with the size of the memory area. This means that any assembler program that uses something like the standard memory configuration will be 54K in size, even a simple "hello world" with 40 bytes of code+data. I don't think that people will like this default, and that it will cause a lot of questions. Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:36 CET