1/1 
|
16-bit ISA
by Unknown on Mar 14, 2005 |
Not available! | ||
|
Disclaimer: In my writing below, 16 and 32 bits mean length of instructions, not data processing width. It is all about synergy. A long time ago at the beginning of the openrisc project, there was a 16-bit instruction subset. Then it become more of its own separate ISA because it was very difficult to maintain 16-bit and 32-bit in the same instruction set (too many complications). Eventually the 16-bit died because there was not enough resources to be focused on both (it eventually needed its own toolchain and its own processor implementations). I support different extensions, but as long as they are done in a modular way. In this particular case I think condensed 16 bit instructions would have an important role in embedded applications, reducing code size which results in smaller flash memories and less power dissipation (entire instruction fetching gets reduced from moving 32 bits wide instructions down to 16 bits, smaller instruction caches etc). Also there are many other "extensions" that could be done in a modular way. For example there are different applications that use a common openrisc base coupled with their own applications specific custom instructions. Imagine having a library of custom instructions for these specific applications (encryption, compression, DSP, ...). This was also the intent way binutils is done in a way that new instructions can be very easily added (there is a table with encodings). And if adding a new custom instructions is too much hassle with the binutils, then there is always an option to add a custom unit. In fact custom units can accomplish the same as custom instructions - they are there so you wouldn't have to mess with binutils all the time. Imagine having a library of custom units for specific applications... If done in a modular way, it would be very easy to use. So I'm all for this "extensions" of different kinds, as long as everything is done in a modular way and if within a scope of openrisc framework. The main reason why the 16-bit ISA has failed was because it got away too much from the 32-bit ISA and it didn't benefit from the synergy effect anymore. Remember, we are relatively small group, and all the efforts that go into openrisc project have to be very carefully spread and not wasted, because if there will be many subprojects that will grow into its own separate projects, then the *synergy* effect will be lost. |
|||
|
16-bit ISA
by Unknown on Mar 14, 2005 |
Not available! | ||
|
I am all for a 16bit ISA.
However no matter what you do, it will always need it's own toolchain.
Hopefully set using a switch like --or16is (openrisc 16bit instruction
set?).
The easiest way to start is to reduce all 3register into 2register operand
instructions. And probably limit the number of register, e.g. max16 instead
of 32 (to keep the analogy).
This means there will be a fixed destination register;
So instead of: r1+r2->r3, it would be r1+r2->r1 (or r2 if you like, as long
as it's consistent).
After reading the 16bit instruction, it can be easily decoded into the
original 32bit instruction. Thus the 16bit opcode can run natively on the
32bit OR1200, removing the need for rtl changes.
It may be even possible to turn on/off the 16bit->32bit decoder by a bit in
a special register.
The location of the decoder has quite some impact;
1. after the cache, reduces the cache size; 16 instead of 32bits
2. before the cache, allows mixing 32bit and 16bit opcodes. The cache
contains only the 32bit (native and decoded) instructions.
3. critical path, ....
The above are the easy and obvious issues. What about loading a register?
Currently it's done by loading the upper and lower16bits separately. How to
do this in a 16bit ISA; use 4 instructions? Only do a load in native 32bit
code?
The latter requires less or equal the amount of instructions compared to
only 16bit instructions. And it doesn't require modifications to the
load/store structure.
//16bit instructions
Load bits 31:24 r1
Load bits 23:16 r1
Load bits 15:08 r1
Load bits 07:00 r1
//using native 32bit instructions
Switch to 32bit instruction set
Load bits 31:16 r1
Load bits 15:00 r1
Switch to 16bit instruction set
For a single load the amount of instructions is the same. For multiple
stores, the native code is smaller and faster (6 versus 8 instructions).
//16bit instructions
Load bits 31:24 r1
Load bits 23:16 r1
Load bits 15:08 r1
Load bits 07:00 r1
Load bits 31:24 r2
Load bits 23:16 r2
Load bits 15:08 r2
Load bits 07:00 r2
//using native 32bit instructions
Switch to 32bit instruction set
Load bits 31:16 r1
Load bits 15:00 r1
Load bits 31:16 r2
Load bits 15:00 r2
Switch to 16bit instruction set
Just my 2 cents .....
Richard
-----Original Message-----
From: openrisc-bounces@opencores.org
[mailto:openrisc-bounces@opencores.org] On Behalf Of Damjan Lampret
Sent: Monday, March 14, 2005 12:43 PM
To: List about OpenRISC project
Subject: [openrisc] 16-bit ISA
Disclaimer: In my writing below, 16 and 32 bits mean length
of instructions, not data processing width.
It is all about synergy.
A long time ago at the beginning of the openrisc project,
there was a 16-bit instruction subset. Then it become more of
its own separate ISA because it was very difficult to
maintain 16-bit and 32-bit in the same instruction set (too
many complications). Eventually the 16-bit died because there
was not enough resources to be focused on both (it eventually
needed its own toolchain and its own processor implementations).
I support different extensions, but as long as they are done
in a modular way. In this particular case I think condensed
16 bit instructions would have an important role in embedded
applications, reducing code size which results in smaller
flash memories and less power dissipation (entire instruction
fetching gets reduced from moving 32 bits wide instructions
down to 16 bits, smaller instruction caches etc).
Also there are many other "extensions" that could be done in
a modular way.
For example there are different applications that use a
common openrisc base coupled with their own applications
specific custom instructions. Imagine having a library of
custom instructions for these specific applications
(encryption, compression, DSP, ...). This was also the intent
way binutils is done in a way that new instructions can be
very easily added (there is a table with encodings). And if
adding a new custom instructions is too much hassle with the
binutils, then there is always an option to add a custom
unit. In fact custom units can accomplish the same as custom
instructions - they are there so you wouldn't have to mess
with binutils all the time.
Imagine having a library of custom units for specific
applications... If done in a modular way, it would be very
easy to use.
So I'm all for this "extensions" of different kinds, as long
as everything is done in a modular way and if within a scope
of openrisc framework. The main reason why the 16-bit ISA has
failed was because it got away too much from the 32-bit ISA
and it didn't benefit from the synergy effect anymore.
Remember, we are relatively small group, and all the efforts
that go into openrisc project have to be very carefully
spread and not wasted, because if there will be many
subprojects that will grow into its own separate projects,
then the *synergy* effect will be lost.
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc
|
|||
1/1