Kronos: Soviet Processor Family for High-Level Languages (2006) [pdf](inria.hal.science)
inria.hal.science
Kronos: Soviet Processor Family for High-Level Languages (2006) [pdf]
https://inria.hal.science/hal-01568396v1/document
5 comments
That's a cute architecture. Very 1980s.
Stack-oriented, sort of like byte code. Kind of like Burroughs machines, with some influence from the Intel iAPX 432.
Vanilla architecture won out over all that machine-level cleverness.
Vanilla architecture won out over all that machine-level cleverness.
I assume the driving of choosing low er level architectures over this sort of "smart" CPU was the overall complexity of the chip, but since the 80' with been piling so much abstraction and complexity that there is nithing "vanilla" in modern CPU. I wonder if such "higher level" CPUs could be interesting implented on top of the usual microcode architecture. They would for example give more information to the branch predictor, which could have a positive impact.
It wasn’t a single or even custom chip though - built from standard bitslice.
Wasn't RISC an attempt at addressing that growing abstraction and complexity?
Definitely, some great interviews out there with Sophie Wilson (co-creator of ARM) discussing how supporting arbitrary languages was a goal of the ARM project (based on the Berkeley RISC research) from the beginning.
1 -https://youtu.be/jhwwrSaHdh8?si=mj1vl_Wy0MF-IQL4
2 - https://youtu.be/IASlQ9kjRRA?si=OPA1atrtlLdXEfTo
1 -https://youtu.be/jhwwrSaHdh8?si=mj1vl_Wy0MF-IQL4
2 - https://youtu.be/IASlQ9kjRRA?si=OPA1atrtlLdXEfTo
Aren't all ISAs "byte code" at this point? They all get translated in the microcode layer before being issued to the actual machine instructions of the various cores, at least in x86.
Are there any modern CPUs that do what RISC did and the instructions were directly implemented in circuitry, bypassing microcode translation?
I almost would like CPUs to offer programmable microcode layers at this point (yes, easier said than done) so some cores could be dedicated to emulation at the microcode level. The last major ISA switch was Apple's from x86 to ARM. But it would probably be better to just get an FPGA as part of the embarrassment of riches in chip silicon.
You know, an FPGA could be rebranded as an AI processor for the hype train. I think the AI hype they are blathering about in current processors is just vector processing that the video cards do better anyway, but I haven't bothered to parse the propaganda.
Are there any modern CPUs that do what RISC did and the instructions were directly implemented in circuitry, bypassing microcode translation?
I almost would like CPUs to offer programmable microcode layers at this point (yes, easier said than done) so some cores could be dedicated to emulation at the microcode level. The last major ISA switch was Apple's from x86 to ARM. But it would probably be better to just get an FPGA as part of the embarrassment of riches in chip silicon.
You know, an FPGA could be rebranded as an AI processor for the hype train. I think the AI hype they are blathering about in current processors is just vector processing that the video cards do better anyway, but I haven't bothered to parse the propaganda.
> Are there any modern CPUs that do what RISC did and the instructions were directly implemented in circuitry, bypassing microcode translation?
ARM, mostly. Instructions are 32 bits wide and aligned on 4-byte boundaries. This simplifies instruction decode. IA-32 does not require this, leading to considerable complexity in superscalar instruction fetch and decode.
The ARM instruction set isn't very "reduced" any more.[1] Despite this, on larger CPUs, most instructions in modern CPUs have direct hardware implementations. There are enough transistors available to do it that way.
[1] file:///home/john/Downloads/arm_instruction_set_reference_guide_100076_0100_00_en.pdf
ARM, mostly. Instructions are 32 bits wide and aligned on 4-byte boundaries. This simplifies instruction decode. IA-32 does not require this, leading to considerable complexity in superscalar instruction fetch and decode.
The ARM instruction set isn't very "reduced" any more.[1] Despite this, on larger CPUs, most instructions in modern CPUs have direct hardware implementations. There are enough transistors available to do it that way.
[1] file:///home/john/Downloads/arm_instruction_set_reference_guide_100076_0100_00_en.pdf
I'd argue that x86 and IBM z/Arch are the ones that stick out among contemporary ISAs in that they need fairly complex fron-end translation into an internal instruction format.
ARM implementations that support both ARMv7 (both ARM mode and THUMB mode) and ARMv8 also need some kind of translation in the front-end, but recent ARMs (like Apple's implementations) don't support 32-bit mode and are simpler in that way.
Most other ISAs are much closer to the metal, although many implementations still do some level of translation in the front-end (mostly fusing/splitting certain instruction combinations for better efficiency). Examples: ARMv8+, RISC-V, MIPS, Loongson, TI 6x & 7x DSP, and of course most GPUs (and my own MRISC32 ISA).
ARM implementations that support both ARMv7 (both ARM mode and THUMB mode) and ARMv8 also need some kind of translation in the front-end, but recent ARMs (like Apple's implementations) don't support 32-bit mode and are simpler in that way.
Most other ISAs are much closer to the metal, although many implementations still do some level of translation in the front-end (mostly fusing/splitting certain instruction combinations for better efficiency). Examples: ARMv8+, RISC-V, MIPS, Loongson, TI 6x & 7x DSP, and of course most GPUs (and my own MRISC32 ISA).
Not really IMO. The mapping from the important instructions to the microcode underneath is pretty direct from what I've read at least.
To give you some context, it was a local research (not mass produced) project seemingly arbitrarily financed by being hooked as a trail car to some government space program workstation development contract in turbulent late '80s and early '90s. That explains both high (interesting choices) and low (not even bothering to compete with mainstream) points.
This is one of the nicest looking vintage workstations I’ve seen in a long time.
Sounds a little bit like a similar attempt with a different approach from Intel the iAPX 432 that also tried to support high level languages in hardware and was a market failure.
The 432 was far too slow to be competitive, which was a consequence of bad implementation decisions rather than the approach itself. See https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings...
https://collection.sciencemuseumgroup.org.uk/objects/co85650...