4 ms·

I'm sure someone has thought of this before, but there's x86 as the full ISA, and there's x86 as gcc (or whatever) actually uses it. What if you had one or two

by 13of40 3y ago

I'm sure someone has thought of this before, but there's x86 as the full ISA, and there's x86 as gcc (or whatever) actually uses it. What if you had one or two cores that actually run x86 and the rest just run a reasonable subset of it until they hit a weird instruction and hand the thread over to the more formal one?

StressedDev 3y ago
You don't need special cores. One thing a lot of people do not seem to realize is compilers do not use the full instruction set. They use a subset and this subset is what has to be fast. Here are the common x86 instructions I remember when I debugged disassembled source code (1). - mov (an instruction to load, store data) - Basic arithmetic instructions (add, sub, div, mul, etc.) - Bitwise operators (or, and, xor, shift, etc.) - Compare (cmp) - Branch (jz, jnz, j, ret, etc.) - There was one weird instruction I would occasionally see. It was used to zero memory (I forget its name). My guess is the compiler used it because it was faster than running creating a loop which zeroed memory. The point is, people seem to assume ALL instructions have to be fast. The only instructions which have to be fast are the ones the compilers are using. The rest just have to work. Making the rarely used instructions work probably takes up a negligible amount of space on a typical core. Moving these instructions to a special core would not get you much but would make old software run slower (becuase of the context switch to the other core and/or a limited number of cores it could run on). Note that I know AMD and Intel both have a lot of guidance for compiler writers. (1) I debugged disabled code because I was debugging optimized code and it was the only way to reliable determine why a function crashed or malfunctioned.
- Someone 3y ago
  > One thing a lot of people do not seem to realize is compilers do not use the full instruction set. They use a subset and this subset is what has to be fast. That’s a self-fulfilling prophecy. Compiler writers won’t use the instructions that are (relatively) slow. If, tomorrow, Intel makes ‘add’ slow, compilers will eventually start compiling addition as negation + subtraction (and AMD will become more popular) That’s what makes hardware designers unhappy sometimes. If they ship a shiny faster CPU that requires a large overhaul of compilers, it can take time for compiler writers to catch up. Hardware designers shouldn’t (only) aim for getting closer to the local optimum of where compiler writers are, but also for the higher peaks of where they could be.
  - saagarjha 3y ago
    Hardware designers typically work with compiler authors to get them to use instructions they'd like.
immibis 3y ago
They already do this. The core has 4 or 5 decoders that work in parallel to decode up to 16 instruction bytes, and only the first one can handle more complex instructions. If there is a complex instruction after the first slot in the byte chunk, it realigns the instruction stream (how's that for technobabble?) so the first decoder gets the complex instruction in the next cycle. This means to exploit your processor's full decode performance you have to reorder your instructions so the complex ones are the first in each 16-byte group, or something like that.
deleted 3y ago
[deleted]
fulafel 3y ago
Lots of companies have tried the road of making existing code execute slowly in a "legacy" mode and asking code to be recompiled to get performance. Those companies generally are not around anymore.

by 13of40 3y ago

StressedDev 3y ago

You don't need special cores. One thing a lot of people do not seem to realize is compilers do not use the full instruction set. They use a subset and this subset is what has to be fast. Here are the common x86 instructions I remember when I debugged disassembled source code (1). - mov (an instruction to load, store data) - Basic arithmetic instructions (add, sub, div, mul, etc.) - Bitwise operators (or, and, xor, shift, etc.) - Compare (cmp) - Branch (jz, jnz, j, ret, etc.) - There was one weird instruction I would occasionally see. It was used to zero memory (I forget its name). My guess is the compiler used it because it was faster than running creating a loop which zeroed memory. The point is, people seem to assume ALL instructions have to be fast. The only instructions which have to be fast are the ones the compilers are using. The rest just have to work. Making the rarely used instructions work probably takes up a negligible amount of space on a typical core. Moving these instructions to a special core would not get you much but would make old software run slower (becuase of the context switch to the other core and/or a limited number of cores it could run on). Note that I know AMD and Intel both have a lot of guidance for compiler writers. (1) I debugged disabled code because I was debugging optimized code and it was the only way to reliable determine why a function crashed or malfunctioned.

Someone 3y ago
> One thing a lot of people do not seem to realize is compilers do not use the full instruction set. They use a subset and this subset is what has to be fast. That’s a self-fulfilling prophecy. Compiler writers won’t use the instructions that are (relatively) slow. If, tomorrow, Intel makes ‘add’ slow, compilers will eventually start compiling addition as negation + subtraction (and AMD will become more popular) That’s what makes hardware designers unhappy sometimes. If they ship a shiny faster CPU that requires a large overhaul of compilers, it can take time for compiler writers to catch up. Hardware designers shouldn’t (only) aim for getting closer to the local optimum of where compiler writers are, but also for the higher peaks of where they could be.
- saagarjha 3y ago
  Hardware designers typically work with compiler authors to get them to use instructions they'd like.

immibis 3y ago

They already do this. The core has 4 or 5 decoders that work in parallel to decode up to 16 instruction bytes, and only the first one can handle more complex instructions. If there is a complex instruction after the first slot in the byte chunk, it realigns the instruction stream (how's that for technobabble?) so the first decoder gets the complex instruction in the next cycle. This means to exploit your processor's full decode performance you have to reorder your instructions so the complex ones are the first in each 16-byte group, or something like that.

deleted 3y ago

[deleted]

fulafel 3y ago

Lots of companies have tried the road of making existing code execute slowly in a "legacy" mode and asking code to be recompiled to get performance. Those companies generally are not around anymore.