From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-12-16 10:10:31
Hi!
On Sun, Dec 15, 2002 at 10:52:37PM +0100, Groepaz wrote:
> only serious problem left right now is that we need some kind of timer-api
> that can be used for synchronization.
That's right. You may try to use clock() for synchronizing until something
better is available. The nachm player and Adam Dunkels uip TCP stack do this.
[joystick driver]
> i would really vote for loadable modules here aswell....
I'm not really sure in this case. Loadable modules mean that a program gets
the heap routines and file i/o always linked in. A simple
int main (void)
{
em_load_driver ("c64-ram.emd");
}
does have a size of ~3K because of that. Of course, bigger programs will use
file i/o anyway, and such programs may also use the heap for other things, but
for small programs it's quite an impact. In addition, it makes simpler
programs more complex, because one does always have to load a driver. And
last, there are still platforms without file i/o, so these platforms cannot
support a joystick (it would be stupid to have a joystick as a module for some
platforms and statically linker routines for others).
Another disadvantage of modules (not only true for joystick drivers) is that
it's an all or nothing approach. When linking statically, you will get just
the routines that are needed. When using conio for example, if your program
only uses clrscr(), it will get just that. When moving conio into a module,
the module can only be loaded as a whole, so cputc(), gotoxy() and friends
would also be loaded even if they are not needed.
So while loadable modules are a really nice feature, they are not the silver
bullet. There are libraries that can be made loadable modules without
problems, and there are others, where this is not so clear.
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 : 2002-12-16 10:11:40 CET