[libre-riscv-dev] multi issue

[Jacob Lifshay]

we will additionally need to decide which variety of long instruction
encoding we will support: the encoding in the original spec or the new
encoding proposed by clifford wolf.

The way I had been planning on decoding multiple instructions is to read
multiple 16-bit units from the instruction cache, then, for every unit,
calculate the length of the instruction that might start at that unit, then
calculate which units actually start instructions for the first N
instructions, where N is the max decode count, then mux the instructions
into N ILEN-bits slots where each slot additionally has a valid bit. the N
slots then can be then enqueued into the instruction queue. the fetch
address would then be updated by the number of units that were successfully
added to the queue.

On Thu, May 30, 2019, 15:42 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> Oh, nearly forgot, there is a potential reason for having separate
> instruction decode Q from instruction issue Q, the SV vectorisation
> hardware "for-loop" which issues multiple element based sub-instructions
> based on the VL vector length.
>
> This engine will live *between* these two queues.
>
> So the instruction issue Q will be much larger and take a lot more entries
> than the instruction decode Q.
>
> The opportunity therefore exists to "normalise" the instruction to a
> uniform length, with partial decode.
>
> Also, predication gets added at the issue Q (creates a shadow, there will
> need to be special predication Function Units, very similar to Branch
> Units).
>
> There will also need to be a special unit for that vectorised MV.X
> instruction we discussed, Jacob.
>
> L.
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>