[OpenBIOS] Re: Paflof update

[Stefan Reinauer]

* 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 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

-- 
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 at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..