On 06/08/2013 11:00 AM, ben wrote:
The NC4000 was
fun to play with, still. I recall
comparing my 4MHz processor to Intels 80386 at 33mHz.
I wrote some optimized code to sort 1000 integers. The
NX4000 ran in about 19 millisconds.
I don't recall exactly what the 386 did but it was 2 or 3 times
slower.
I'd added one specialized hardware/code to my boards. I made
it so that if I wrote to 0FFFF and read it, it would swap the high
and low order 8 bits. It was relatively efficient because -1 was
a short constant instead of a full address.
I needed the 8 bits for my drivers for the floppy and hard drive.
I'd also add a couple parts so that on boot, I could load the core
to shadow RAM and then switch to full RAM. That allowed me to
do patching while experimenting with new core code. I'll trying to
recall the manufacture of the processor board( it is in storage ).
The other fun thing was that it could recompile the ROM image
from the hard disk in less than 15 seconds.
The 4000 had an interesting tradeoff in power to speed.
The ALU would calculate everything on each cycle and then
you'd pick the answer through a mux. This allowed things like
add or subtract to start working before the opcode was even
fetched, for the add or subtract. Long carries still consumed
more than two cycles on faster clock speeds. One threw a NOP
infront of the + instruction to allow it to complete.
It didn't make sense to me until John Ribble explained it to me.
Dwight
But the question, does Forth need to super fast?
That all depends on the application requirements, not the chosen
implementation language.
That said, though, Forth is, very generally, almost always very fast.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA