Re: [openrisc] Re: OR1000 16 bit instruction set

["Marko Mlinar" <markom@opencores.org>]

> > it is all about demand. Right now it looks like 32-bit insn length is
most
> > wanted, especially because of the coming 64-bit superscalar version of
the
> > OR1K. It is also true that prices of Flash and RAM are droping some 30%
or
> > more each year. But if there will be enough interest for 16-bit insn
length,
> > it could become a priority.
>
> "Whatever, RAM is cheap these days" is the usual answer, but usually
> cost per MB is not the issue.  It is the wrong answer on desktop systems
> (because RAM is slow) and usually wrong in low cost embedded systems.
>
> Think low cost => small pin count package => max. 16 bit data path to
> RAM => two fetches per insn.  Also little space => max. CPU + one SDRAM
> + one flash => 16 bit data bus.  16 bit is the maximum you can actually
> get for a single SDRAM it seems, and even then 8 and less bits SDRAMs
> may be more common (and cheaper).
>
> I saw a statistic for ARM somewhere, Thumb was about comparable in speed
> (or slightly slower, not sure) to ARM on a full 32 bit architecture but
> significantly faster on 16 bit ROM/RAM.
That is true, however ICache should decrease this effect significally.
ARM's Thumb itself is about 40% slower than normal ARM ISA, running
from ICache. Still I agree it is good to make 16 bit ISA, to save some power
on bus drivers, cache, etc.

But it is really a pain to use 16 and 32 bit ISA together...
If we choose to implement OR16, I would suggest to use either OR16 or OR32
in one application.

Marko


--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml