Most probably it's worth the effort. Not too much effort, either:
MOVE --> memmove() MOVE> --> memcpy()
which just moves the implementation down a layer and speeds things up for host execution. If we want to get this thing to flash we have to do it ourselfes anyways, no matter whether we write it in forth or use a C/asm optimized memmove/memcpy
Ah, c'mon. You can link against some libraries and get memmove() et. al. for free, even when doing embedded work. This problem has been solved so many times already that there are lots of good, free, implementations available.
Graphics drivers need to be (partly) written in C or asm anyway (esp. the "blitter" parts), so as not too make the system feel sluggish.
Which was the reason why i proposed C written unaligned words.
Optimized blitters won't use unaligned accesses anyway (except for some boundary cases, maybe).
The "problem" is that it takes paflof about 1.2secs per package on a 667MHz 21264 to initialize this table. Not really fatal, but I still
Huh?
want to see that compressed dictionary dumps are smaller than fcode drivers before I consider them the universal solution.
Just wait and see, I guess...
Segher
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..