Liste des Groupes | Revenir à c arch |
John Savard <quadibloc@servername.invalid> schrieb:
Thus, instead of having mode bits, one _could_ do the following:
>
Usually, have 28 bit instructions that are shorter because there's
only one opcode for each floating and integer operation. The first
four bits in a block give the lengths of data to be used.
>
But have one value for the first four bits in a block that indicates
36-bit instructions instead, which do include type information, so
that very occasional instructions for rarely-used types can be mixed
in which don't fill a whole block.
>
While that's a theoretical possibility, I don't view it as being
worthwhile in practice.
I played around a bit with another scheme: Encoding things intoNot having seen said encoding scheme:: I suspect you used the Rd=Rs1
128-bit blocks, with either 21-bit or 42-bit or longer instructions
(or a block header with six bits, and 20 or 40 bits for each
instruction).
Did that look promising? Not really; the 21 bits offered a lotBut beating RISC-V is easy, try getting you instruction count down to VAX counts without losing the ability to pipeline and parallel
of useful opcode space for two-register operations and even for
a few of the often-used three-register, but 42 bits was really
a bit too long, so the advantage wasn't great. And embedding
32-bit or 64-bit instructions in the code stream does not really
fit the 21-bit raster well, so compared to an ISA which can do so
(like My 66000) it came out at a disadvantage. Might be possible
to beat RISC-V, though.
Les messages affichés proviennent d'usenet.