* Segher Boessenkool <segher(a)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
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
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
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
To unsubscribe: send mail to majordomo(a)freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
- free your system..