How many x86 instructions are there?
fgiesen.wordpress.com
fgiesen.wordpress.com
A "projection" is the imposition of a tree-like structure on the DAG, followed by a cut of the tree to make it practicalable in size. Aliasing mnemonics in the tree can cause confusion for the user---or aid in understanding.
These articles are noting that there are many ways to project the x86 ISA.
[1]: https://software.intel.com/en-us/articles/pin-a-dynamic-bina...
[2]: https://software.intel.com/en-us/articles/xed-x86-encoder-de...
Last I checked, using default GCC settings you can drastically change the performance of the resulting app by passing different flags. This obviously depends a lot on the app, but I recall a simple raytracing program I wrote in C++ in University being sped up quite a bit when I passed it flags to optimize for Pentium4+, because it leveraged certain SSE instructions.
MSVC++ with optimizations turned on actually bundles multiple copies of the binary in the resulting .exe file, and is able to pick the optimal one (based on the ISA extensions your CPU supported) at runtime. I'm sure you can do something comparable with binaries produced by GCC and CLang.
Now.. do I think this improperly optimized binaries are a problem plaguing us? No. Because the large native applications that would really benefit (such as Chrome/V8) have already dealt with this. The smaller apps (think a small GTK app like gedit) won't see a noticeable performance benefit. And most newer, consumer applications (Spotify, Slack, Skype) are written in something like Node anyways.
The only thing I can find on it though is this IEEE document reference: http://ieeexplore.ieee.org/document/6136696/
Anyway, it actually ran neither (the core is more like Itanium) and had a separate chip that JIT compiled ARM and x86 to the internal ISA.
But yes, as far as I'm aware, what killed the x86 support was licensing.
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.
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?
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=...). People like legulere would thus clearly nitpick that the criterion "instruction sets that have been developed independently" is not satisfied here.
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.
As someone who's not a jvm or hw person: why's that?
The "killer feature" was that you could run CP/M programs on your PC. As long as the CP/M programs weren't "naughty" and didn't use Z80 instructions (a different superset of 8080). CP/M itself had system calls which emulated the Z80 instructions (mainly LDIR), which could be "accelerated" if the processor was a real Z80, but of course programs occasionally ignored this and just used the Z80 instructions directly.
-ae only if the word is a) not an abbreviation, b) Latin, and c) a-declension.
It might be octopodes in those other languages, but octopi is the pattern most expect from the current structure and therefore it is more correct; scholars of exceptions be forgiven for their pedantic ways.
> It’s surprisingly hard to give a good answer (the question was raised in this article). It depends on how you count, and the details are interesting (to me anyway).