5 ms·

Why does the 80486 take longer to execute simple instructions than complex ones?

mysterydip 6y ago
This is relevant for me as I'm making a game using a codebase from the mid 90s designed for the 486 (a mix of C and assembler). I assume most of this was known and optimized for at the time but something to consider as I add features to keep performance.
- temac 6y ago
  You can find the i486 programmer's reference manual easily. It contains, in the part documenting all the instructions, the number of cycles they take. (That's kind of a simplification, but in the context of the in-order, small pipeline, and not-superscalar i486, not by much.)
  - mysterydip 6y ago
    Oh excellent, I'll check that out. Been a while since I read a microprocessor book.
jug 6y ago
This reminds me of my teacher in micro architecture who mocked the insanity of the Pentium 4 NetBurst pipeline. It's hard to believe today that Intel fully expected and were commited to make that stuff run in upwards of 10 GHz. Meanwhile, AMD offered tongue in cheek Prescott Survival Kits¹ due to, uh thermal hazards. Those were the days. :-) ¹ https://i.imgur.com/BYtbfDX.jpg https://i.imgur.com/BYtbfDX.jpg
- theandrewbailey 6y ago
  Those "Extreme Edition" CPUs[0] were nicknamed "Emergency Edition" for a reason. [0] https://en.wikipedia.org/wiki/Pentium_4#Gallatin_(Extreme_Edition) https://en.wikipedia.org/wiki/Pentium_4#Gallatin_(Extreme_Ed...
- bogomipz 6y ago
  >"This reminds me of my teacher in micro architecture who mocked the insanity of the Pentium 4 NetBurst pipeline." Could you elaborate on what exactly was so insane about the the Netburst microarchitecture?
  - Spare_account 6y ago
    Not the same person but I assume it is related to the issues discussed under "Scaling up issues" here: https://en.wikipedia.org/wiki/NetBurst_(microarchitecture)#Scaling-up_issues https://en.wikipedia.org/wiki/NetBurst_(microarchitecture)#S...
HenryBemis 6y ago
> the 80486 is not a RISC CPU My immediate thought when I saw the title was: "hey that is a CISC CPU, right?". I only get the chance to have the CISC/RISC dialogue once every couple of years. Most IT folks don't bother with chatting about CPU architecture any more. These were some fun discussions to have back in the day. With the price and speed that CPUs have nowadays these discussions feel redundant.
- haneefmubarak 6y ago
  Hit me up anytime you'd like to have an architecture convo, esp a cisc / RISC discussion. Keybase in profile, but lmk of a different medium would be more palatable.
- als0 6y ago
  Not just price and speed. The original motivation behind RISC was to make a chip that was simple enough to fit all the functionality onto one die. However, chips have been on a single die for many years, so that's no longer an advantage. The actual instruction set design is much less (but still) important these days. There aren't many "pure" RISC designs left because the universal demand for accelerated encryption, decompression, vectorization etc outweigh the ideological need for a pure design. IMHO what's more relevant today is having an instruction set that compilers can fully exploit, rather than having an instruction set that's optimized for human understanding. In other words, it's no longer a decision between complex and simple.
  - lou1306 6y ago
    > There aren't many "pure" RISC designs left True, from the point of view of the "user" (i.e., the compilers). Internally, most CISC machines nowadays are essentially RISC machines with a CISC-to-microcode translator, so you could also say that there aren't many "pure" CISCs left either :)
    - als0 6y ago
      Indeed, with either macro-op and micro-op fusion microarchtecture some of the performance costs are amortised.
PopePompus 6y ago
Life was so simple back in the 1970s, when I began to program. Processor manuals for CPUs had a table of instruction timings, and you could just add up those times for each instruction and figure out exactly how long a code segment would take to execute. No branch prediction failures, no cache misses, no pipeline quirks...
- iamgopal 6y ago
  the amount of transistors required to do those extra jobs, couldn't be used for extra core ? Will it be faster or slower ?
  - jcranmer 6y ago
    It doesn't really work like that. It is ridiculously easy to stamp out ALUs on a die, but the problem is keeping those ALUs fed with useful data. And memory just can't keep up with modern CPU clock speeds. Modern CPUs use cache hierarchies to push off having to access main memory as late as possible, and even then, they use a lot of transistors to deal with the fact that even on-chip caches are slow compared to the ALUs. GPUs instead use those transistors to keep as many threads running as possible, treating a request to go to main memory as an event to switch to another bank of threads while it waits for the memory request to come back.
  - lmm 6y ago
    We do have processors that use their silicon to implement a bunch of simple, consistent cores that do simple operations; the most common form are GPUs. They can run parallel operations much more efficiently, and theoretically perhaps most or all programs could be implemented in a way that would be more efficient on those processors. But certainly the fastest way that's been found to run existing C-style code is these very complex execution pipelines; extra cores are not the limiting factor for most workloads.
- Scoundreller 6y ago
  Also made it really easy to time your glitch attacks against “secure” MCUs ;)
- 6y ago
chasingthewind 6y ago
Sometimes with these incredibly specific SO questions that have incredibly detailed and knowledgeable answers I start wondering what the likelihood is that they happened organically vs the likelihood that they were teed up Quora style to improve content quality.

This is relevant for me as I'm making a game using a codebase from the mid 90s designed for the 486 (a mix of C and assembler). I assume most of this was known and optimized for at the time but something to consider as I add features to keep performance.

temac 6y ago
You can find the i486 programmer's reference manual easily. It contains, in the part documenting all the instructions, the number of cycles they take. (That's kind of a simplification, but in the context of the in-order, small pipeline, and not-superscalar i486, not by much.)
- mysterydip 6y ago
  Oh excellent, I'll check that out. Been a while since I read a microprocessor book.

jug 6y ago

This reminds me of my teacher in micro architecture who mocked the insanity of the Pentium 4 NetBurst pipeline. It's hard to believe today that Intel fully expected and were commited to make that stuff run in upwards of 10 GHz. Meanwhile, AMD offered tongue in cheek Prescott Survival Kits¹ due to, uh thermal hazards. Those were the days. :-) ¹ https://i.imgur.com/BYtbfDX.jpg https://i.imgur.com/BYtbfDX.jpg

theandrewbailey 6y ago
Those "Extreme Edition" CPUs[0] were nicknamed "Emergency Edition" for a reason. [0] https://en.wikipedia.org/wiki/Pentium_4#Gallatin_(Extreme_Edition) https://en.wikipedia.org/wiki/Pentium_4#Gallatin_(Extreme_Ed...
bogomipz 6y ago
>"This reminds me of my teacher in micro architecture who mocked the insanity of the Pentium 4 NetBurst pipeline." Could you elaborate on what exactly was so insane about the the Netburst microarchitecture?
- Spare_account 6y ago
  Not the same person but I assume it is related to the issues discussed under "Scaling up issues" here: https://en.wikipedia.org/wiki/NetBurst_(microarchitecture)#Scaling-up_issues https://en.wikipedia.org/wiki/NetBurst_(microarchitecture)#S...

HenryBemis 6y ago

> the 80486 is not a RISC CPU My immediate thought when I saw the title was: "hey that is a CISC CPU, right?". I only get the chance to have the CISC/RISC dialogue once every couple of years. Most IT folks don't bother with chatting about CPU architecture any more. These were some fun discussions to have back in the day. With the price and speed that CPUs have nowadays these discussions feel redundant.

haneefmubarak 6y ago
Hit me up anytime you'd like to have an architecture convo, esp a cisc / RISC discussion. Keybase in profile, but lmk of a different medium would be more palatable.
als0 6y ago
Not just price and speed. The original motivation behind RISC was to make a chip that was simple enough to fit all the functionality onto one die. However, chips have been on a single die for many years, so that's no longer an advantage. The actual instruction set design is much less (but still) important these days. There aren't many "pure" RISC designs left because the universal demand for accelerated encryption, decompression, vectorization etc outweigh the ideological need for a pure design. IMHO what's more relevant today is having an instruction set that compilers can fully exploit, rather than having an instruction set that's optimized for human understanding. In other words, it's no longer a decision between complex and simple.
- lou1306 6y ago
  > There aren't many "pure" RISC designs left True, from the point of view of the "user" (i.e., the compilers). Internally, most CISC machines nowadays are essentially RISC machines with a CISC-to-microcode translator, so you could also say that there aren't many "pure" CISCs left either :)
  - als0 6y ago
    Indeed, with either macro-op and micro-op fusion microarchtecture some of the performance costs are amortised.

PopePompus 6y ago

Life was so simple back in the 1970s, when I began to program. Processor manuals for CPUs had a table of instruction timings, and you could just add up those times for each instruction and figure out exactly how long a code segment would take to execute. No branch prediction failures, no cache misses, no pipeline quirks...

iamgopal 6y ago
the amount of transistors required to do those extra jobs, couldn't be used for extra core ? Will it be faster or slower ?
- jcranmer 6y ago
  It doesn't really work like that. It is ridiculously easy to stamp out ALUs on a die, but the problem is keeping those ALUs fed with useful data. And memory just can't keep up with modern CPU clock speeds. Modern CPUs use cache hierarchies to push off having to access main memory as late as possible, and even then, they use a lot of transistors to deal with the fact that even on-chip caches are slow compared to the ALUs. GPUs instead use those transistors to keep as many threads running as possible, treating a request to go to main memory as an event to switch to another bank of threads while it waits for the memory request to come back.
- lmm 6y ago
  We do have processors that use their silicon to implement a bunch of simple, consistent cores that do simple operations; the most common form are GPUs. They can run parallel operations much more efficiently, and theoretically perhaps most or all programs could be implemented in a way that would be more efficient on those processors. But certainly the fastest way that's been found to run existing C-style code is these very complex execution pipelines; extra cores are not the limiting factor for most workloads.
Scoundreller 6y ago
Also made it really easy to time your glitch attacks against “secure” MCUs ;)
6y ago

chasingthewind 6y ago

Sometimes with these incredibly specific SO questions that have incredibly detailed and knowledgeable answers I start wondering what the likelihood is that they happened organically vs the likelihood that they were teed up Quora style to improve content quality.