> If I get 1 Mtip (million token instructions per minute), I'll be very hap=
> py.=20
> I was thinking of 'pipelining' as many tokens as possible. Basically I'll=
> =20
> just load, say 10 tokens instead of 1. If the program branches out of the=
> =20
> cached tokens, I will have to reload.

|I think the advantage of your approach is that typically the serial interfaces
|to the EEPROMS allow for sequential access without having to reload the address
|of the byte read. So by setting up one address then reading 10 tokens you can
|save up to 30 bytes of command/address loads.

If you're using bit-banged access to the code-store EEPROM, I don't see
any real advantage to prefetching data.  It would certainly be worthwhile
to take advantage of I2C sequential access, but this could simply be done
by having the read_memory routine check the current address against the
requested address.  If they match just do a read_byte rather than doing
the full addressing sequence.  Beyond that, though, what do you save?

By contrast, if one is using a PIC with built-in SPI hardware to help
with the EEPROM accesses (and even SPI hardware could help if data-in and
data-out were tied together) having a one-byte readahead could be quite
useful since 8 of the 9 clocks for each byte could be handled in hardware
while software was processing the previous byte.

BTW, another suggestion for speeding up the interpreter: use four I2C
devices with a shared clock wire and seperate data wires.  This would
allow 32 bits of data to be read much faster than with a single device.
The one caveat would be that all accesses (reads and writes) would be
32 bits wide (for fastest access, each byte would be stored as two bits
on each device).  This caveat aside, though, the much-improved data
speed should make that method pretty quick.



Attachment converted: wonderland:WINMAIL.DAT (????/----) (00006F11)