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