Stefan Reinauer wrote:
- Segher Boessenkool email@example.com [020626 07:58]:
you actually don't need to know endianness to implement a fast unaligned-*** in pure Forth :)
: unaligned-l@ here /l move> here l@ ;
Ah.. nice idea. Which makes me think it might be worth writing accelerated versions of move, that only copy unaligned starts/ends of a block byte per byte and use cell size copying for the rest. Don't know whether it's worth the overhead for the typical amount of data copied with move in an OF implementation.
Most probably it's worth the effort. Not too much effort, either:
MOVE --> memmove() MOVE> --> memcpy()
most hardware won't allow general unaligned accesses to be atomic anyway... i doubt we'll ever see unaligned-*** used on anything that's not just ram, so there's no problem here.
graphics hardware might need it. i.e. but that can be considered RAM
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.
is it legal for an fcode program to overload words defined within the lower space (i.e. 0x000-0x5ff)? If not, we can keep this list static and split the array up in 2 parts, one for the static data, one for the dynamic table that can be changed by user packages (i.e. containing fcode#s above 0x800) This would really speedup initialization when creating a new package or executing an fcode program using byte-load in general.
The FCode table is just (number of bits per cell) x 0.5kB big, and is only needed during package load, so I don't see the problem here?
- To unsubscribe: send mail to firstname.lastname@example.org with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..