* Segher Boessenkool segher@chello.nl [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 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
What's wrong?
it just "feels" ugly to me.
What about using it until someone comes up with a nicer solution? We're modular enough
for the dictionaries, a little playing around with HERE and LAST and LATEST will do. fcode lookup tables are only valid for the package that defines it, and only during package loading, so i see no problem there?
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.
Stefan