From: Greg King (gngking_at_erols.com)
Date: 2002-11-22 19:05:11
-----Original Message----- From: Ullrich von Bassewitz Date: Wednesday, November 20, 2002 06:44 PM Subject: Re: [cc65] Extended memory > > On Wed, Nov 20, 2002 at 11:48:49PM +0100, groepaz wrote: > > Well, I'd say that's the responsibility of the programmer. > > Unfortunately, a programmer does not know which modules from a library > contain code with these requirements. > > I forgot that I did this before, and that there is an easy solution:-) > > Just place the code that has to go into low-memory into a special segment > (which is always the same, regardless of the module). Then, place this segment > as first segment into the memory area using the linker config. In fact, this > approach does exactly the same as your suggestion of "a place at the > beginning" linker command. The C128 uses this solution, since the interrupt- > handler for the RS232 module has to go into low-memory. When I read the IDE64 Hard-disk Controller's documents, I realized that the C64 target, also, needs to protect interrupt-handlers (for the mouse, too). Your solution should be made a standard part of the built-in scripts of all of the targets. (Some of the targets might not need to protect a segment, but there could be common library-routines that want it.) Perhaps, we can call that segment, "SAFE". (It must be "type=rw".) Then, we can go through the entire library, find subroutines that might need that protection, and put them into "SAFE". Another good idea from the C128 ld65-script is the "STARTUP" segment. It should be standard, too. Then, we would not need to name a target's start-up file on ld65's command-line. That file could be moved into the library-archive. When cc65 sees a definition of main(), it would add a reference to _exit, to force the linking of that file. ---------------------------------------------------------------------- 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 : 2002-11-22 19:07:23 CET