Sujet : Re: Split instruction and immediate stream
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.archDate : 24. Mar 2025, 07:47:42
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2025Mar24.074742@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5 6 7 8 9
User-Agent : xrn 10.11
Robert Finch <
robfi680@gmail.com> writes:
On 2025-03-23 8:12 a.m., Marcus wrote:
Why not always place the constant next to (right after) the instruction
that references it, instead of at an offset within the cache line?
>
That is a very good idea. It is the same thing almost as using a
variable length instruction.
b16 (both b16-dsp and b16-small) puts 4 5-bit instructions in a 16-bit
word (for an instruction in slot 0, 4 of the 5 bits are 0, so it can
only be either a nop or a call).
The lit and litc instructions take their operands from the next word
in the instruction stream (it seems to me that litc,which only takes
one byte from the instruction stream, makes sense only if there are
two litc's in one instruction word, because the program counter has to
be 16-bit-aligned on the next instruction fetch.
Control-flow instructions take take their target address from the rest
of the instruction word (i.e., a call in the first slot has a 15-bit
target, a jump in slot 2 has a 5-bit target); a control-flow
instruction in slot 3 (no bits left in the instruction word) takes the
address from the stack.
This is all designed for scrictly sequential decoding and processing,
with no pipielining. Bernd Paysan reports 200MHz for b16-dsp and
150MHz for b16-small in XC035, a 0.35um process. For comparison, the
P54C (Pentium) reached up to 200MHz and Klamath (Pentium II) up to
300M in 0.35um, but with pipelining, but also providing lots of
performance-enhancing features; and they were 32-bit CPUs, while b16
is 16-bit.
Various information on the b16 can be found at
<
https://bernd-paysan.de/b16.html>.
- anton
-- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>