Bug 841

Summary: Idea for openpower/x86/aarch64/riscv/etc. programmable decoder
Product: Libre-SOC's first SoC Reporter: Jacob Lifshay <programmerjake>
Component: Source CodeAssignee: Jacob Lifshay <programmerjake>
Status: DEFERRED ---    
Severity: enhancement CC: libre-soc-bugs, lkcl
Priority: ---    
Version: unspecified   
Hardware: Other   
OS: Linux   
NLnet milestone: --- total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0 parent task for budget allocation:
child tasks for budget allocation: The table of payments (in EUR) for this task; TOML format:

Description Jacob Lifshay 2022-05-26 10:15:40 BST 
writing this down before I forget:
i have an idea for a cpu that can execute any isa by having the decoder be programmable, so we could build a compiler that takes qemu's source (or similar) -- probably the guest instruction to tiny-code-gen translator -- and spits out a binary that programs the decoder to decode that selected instruction set. (taking qemu's source and using it to program a fully-general decoder probably would get around patents on the instruction sets, since the isa vendors presumably are fine with qemu decoding their instruction sets (the vendors often contribute to qemu), and this is just another way of executing parts of qemu).

the decoder would be made from 2 parts, a fpga-style pipeline (fast-path) that decodes several instructions per clock along with a flag for when it needs to fallback to the slow-path, and a turing-complete slow path that either is a simple cpu that spits out the decoded instructions or gets the main cpu to execute the program to decode instructions (via a super-fast interrupt).

the decoded instructions would then go into an uop-cache, so programs can still generally run quickly even if the instructions used are complex/slow to decode.
Comment 1 Luke Kenneth Casson Leighton 2022-05-26 10:50:05 BST 
this was the entire basis of Transmeta. they still got sued into oblivion by 
at least Intel. also the DEC Alpha team was bought wholesale by Intel not
for the hardware but for their *software* JIT compiler, which Intel then used
to create exactly what you're describing: CISC-to-RISC *hardware* level
microcoded JIT translation, and patented the s*** out of it.

other than that it's a fantastic idea that keeps coming
up and i have vague recollections that OPF would very much like to see
user-programmable micro-coding become part of the Power ISA.
(caveat: it's a hell of a lot of work).
Comment 2 Jacob Lifshay 2022-05-26 11:02:33 BST 
(In reply to Luke Kenneth Casson Leighton from comment #1)
> this was the entire basis of Transmeta. they still got sued into oblivion by 
> at least Intel. 

afaict the difference is transmeta's jit translator isn't derived from something that intel already gave a patent grant for the use of (like in the apache 2.0 license) where intel has contributed to open source software that decodes x86 instructions.

by having the binary programmed into our decoder be derived from something intel already granted patent licenses for (something like qemu), our decoder benefits from those patent licenses for decoding x86 specifically. that wouldn't affect the actual decoder hw, which is why that has to not be x86-specific.

> also the DEC Alpha team was bought wholesale by Intel not
> for the hardware but for their *software* JIT compiler, which Intel then used
> to create exactly what you're describing: CISC-to-RISC *hardware* level
> microcoded JIT translation, and patented the s*** out of it.

iirc they started doing that more than 20yr ago so those patents should be expired...also intel wasn't the first one to have a programmable decoder with microcode.