>
> Byron A Jeff wrote:
> >=20
> > >
> > > Byron A Jeff wrote:
> > > >=3D20
> > >
> > > >=3D20
> > > > And unless the SX28 has SPI hardware built in, the serial loading o=
> f op=3D
> > > codes
> > > > is going to dominate timewise over the execution time of the byteco=
> des =3D
> > > anyway.
> > >
> > > At 50 MIPs I think it could compensate for the fact that it will be b=
> it-b=3D
> > > anged.
> >=20
> > It will. However I don't think you'll get the full 10 to 15 Mhz availab=
> le
> > bandwidth bit banging.
>
> 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.

Now that's a good idea. This is similar to the plan I had for higher
performance NPCI (Nano-Pseudo-C-Interpreted) boards. In short read the
entire program into a parallel RAM then run the program from the RAM. My
prototype was going to use a 32k static RAM and a 74HC573 latch just like
the 875X series does. I can live with a 19 pin memory interface when the
objective is to process tokens as quickly as possible. The reason for
continuing to load from the EEPROM is programming consistency. That way the
programming board can program both small low power boards and the bigger
high performance boards.

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.

> > Understood. However you could possibly examine my bytecode set and desi=
> gn
> > decisions to get a basis for designing your own.
> It will definitely help me. If you don't mind, I'd love to have a peek.

I think I wrote up a summary for my students. Will have to go looking for it
though. Will let you know...

BAJ