[OpenBIOS] Re: Paflof update
segher at chello.nl
Fri Jun 28 16:39:19 CEST 2002
Stefan Reinauer wrote:
> * Segher Boessenkool <segher at 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 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
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 majordomo at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..
More information about the openbios