From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-01-07 07:58:49
On Sun, Jan 05, 2003 at 03:35:53PM -0500, Greg King wrote: > The lack of module-support should not be a problem. Uz was wise enough to bury > the module-loader behind "task-wrappers." Those functions [such as > joy_load_driver()] are not required actually to load anything! Any target is > free to replace the generic files with custom ones that pretend to load a > module, while really statically-linking a driver from a library. > > That's what the LUnix target does, > because a basic joystick-driver is built into the operating system. While this is one possible solution, I would prefer to have a "real" module and leave this choice to the programmer. A loadable module is only a few bytes larger than a statically linked object file. If you fear the overhead of the o65 module loader and the heap routines, my suggestion would be to replace these by Lunix native ones. As far as I understand Lunix, this has to be done anyway, at least with the head routines. > Hey, Uz! In order for that replacement-policy to be easy and efficient, you I'm not really sure if I want this replacement policy to be easy:-) Problem is that people tend to use easy solutions, and being able to write platform specific replacement modules easily means that people will do that instead of thinking about a solution that works for all platforms. Of course you are right: There are situations, where one needs machine specific code, even if all other platforms share code for a module. On the other side, having separate code means a lot more problems when maintaining this code. When I added __bzero() to the compiler for example, I forgot that GEOS has a separate implementation for memset(), so GEOS didn't have __bzero. Together with another change that caused the compiler to replace calls to memset with a fill value of zero with calls to __bzero, this meaned that programs would no longer compile for GEOS. More machine specific code means a greater chance for things like this to happen. So for now I would prefer to leave the Makefile the way it is. There is always the possibility to change it when the actual need arises. 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 : 2003-01-07 07:58:54 CET