4 ms·
What do you consider as "unrelated"? For example modern ARMv8 cores understand 3 instruction sets: AArch32, Thumb2 and AArch64. AArch32 and Thumb may be related
by wolfgke 10y ago
What do you consider as "unrelated"? For example modern ARMv8 cores understand 3 instruction sets: AArch32, Thumb2 and AArch64. AArch32 and Thumb may be related, but AArch64 is more different (no conditional execution, more registers etc. for example). Though you would perhaps still consider them as related.
EDIT: Similarly, modern x86-64 cores support at least three instruction sets: x86-16 (real mode), x86-32 (protected mode) and x86-64 (long mode). These are related, but at least I claim that x86-16 and x86-64 are very different in practise.
A perhaps better example is Jazelle on older ARM cores, which supported exectuting most of Java VM's instruction set directly on the processor.
Or another example: The instruction set of many processors is separated into several parts that work and encode quite differently. For example the x87 instructions are stack-based instead of register-based. Or I have heard that AltiVec instructions encode and work quite differently from normal PowerPC instructions. The only reason why these are not considered as different instruction sets is that they lie in the same opcode space. If you consider instruction sets that "just lie in the same opcode space, but are otherwise mostly unrelated" as unrelated, then there are some instruction sets that evolved as hybrids of different instruction sets for controlling different functional units.
Or another example is many SoCs contain additional coprocessors and ARM's instruction set contains instruction for controlling them. These coprocessors execute different instruction set. But perhaps you would consider this not as "one processor" but rather several communicating processors on one chip.
TLDR: Define what you mean with "[one] processor" and with "unrelated" in terms of encoding of instructions.
- legulere 10y agoYour examples are all instruction sets that were developed with the idea in mind that they run together with the other instruction sets. What I meant with unrelated is instruction sets that have been developed independently and were not meant to run on the same cpu from the beginning. For instance a cpu that supports both the Risc-V and the Power architecture.
- umanwizard 10y agoLook again -- he mentioned Jazelle, does that fit the bill?
- wolfgke 10y ago> What I meant with unrelated is instruction sets that have been developed independently and were not meant to run on the same cpu from the beginning. Beside umanwizard's comment: What do you consider as "same CPU" here? As I wrote there exist SoCs that can execute multiple instruction sets (for example some DSP at the side of an ARM core, where both instruction sets were developed independently). Do you consider this as "the same CPU" or not and what is the reason why you say "yes" or "no" here?
- spc476 10y agoThere was the V20/V30. It was a drop-in replacement for the 8088 that could also execute 8080 (or Z80---it's been awhile since I used one) code (it was also faster at executing 8088 code, which is why a lot of people used it). While the 8088 is descended from the 8080, it's not binary compatible (completely different opcodes) and probably fits your criteria.
- wolfgke 10y agoIt was the Intel 8080 not the Z80 for which the V20/V30 had an emulation mode (just looked it up). To do some nitpicking on this great example: The Intel 8086/8088 was designed to be assembly source compatible (up to search & replace) to the Intel 8080 (source: https://en.wikipedia.org/w/index.php?title=Intel_8086&oldid=735318399#The_first_x86_design https://en.wikipedia.org/w/index.php?title=Intel_8086&oldid=...). People like legulere would thus clearly nitpick that the criterion "instruction sets that have been developed independently" is not satisfied here.
- kbenson 10y ago> A perhaps better example is Jazelle on older ARM cores, which supported exectuting most of Java VM's instruction set directly on the processor. That's interesting. I vaguely remember one of my professors mentioning that one of the original plans for Java was to have processors that could execute the bytecode (somewhat) directly. I wasn't aware any actually existed.
- Tuna-Fish 10y agoIt existed, but went away because Java bytecode is semantically a terrible language for a CPU to execute. Jitting it down to something that fits hardware better greatly increases speed, so the best you can do is move that jit into hardware, and even then you are hamstrung by the verbosity of the bytecode.
- GFK_of_xmaspast 10y ago> Java bytecode is semantically a terrible language for a CPU to execute As someone who's not a jvm or hw person: why's that?
- Tuna-Fish 10y agoJava bytecode is stack-based and serializes all execution in a thread. In CPU design, you get speed by doing things in parallel, and doing the transformation of Java bytecode stream to some format that allows more instruction-level parallelism takes more time than is available in a CPU frontend.