4 ms·

is out of order processing part of the open spec for RISC-V? or something they added on top?

by iiiiiggggjjjh 4y ago

rwmj 4y ago
It would be an implementation detail, why would the ISA spec need to cover it?
- msla 4y ago
  > It would be an implementation detail, why would the ISA spec need to cover it? Someone asking this in a thread about MIPS is somewhat amusing. Back in The Day (1986) the MIPS I architecture had a few "implementation details" in its ISA, like branch delay slots (even if you take a jump opcode, the next opcode in the instruction stream after that jump is still executed) and load delay slots (the data from a load opcode isn't immediately available, and this delay is software-visible) and integer multiplication and division opcodes that not only had architectural delay slots, executing in parallel with the instructions after the multiplication or divide opcode, but stored their results in special HI and LO registers not used for any other purpose. The underlying goal was to make a chip with a heavy focus on pipelining.
  - rwmj 4y ago
    The extra funny thing is that later revisions of the architecture had to carry all that dead weight around long after the microarchitecture changed so it was no benefit. And then Intel made pretty much the same mistake with Itanic.
    - pjmlp 4y ago
      Itanic only happened because AMD had the licenses to produce AMD64, otherwise Intel would eventually managed to push it to everyone else, no matter what.
      - hakfoo 4y ago
        I'm curious how far in advance Intel had planned out the IA-64 vision. Itanium makes more sense if viewed through the lens of "we want to get into the high-margin spaces currently occupied by boutique architectures like Alpha, PA-RISC, SPARC, etc." This is a place where they could say "recompile all your software for 30% more performance" and get away with it. If they sincerely imagined "one day, we also cut over from x86 to IA-64 on the desktop", they must have expected that to happen several generations further along than the platform ever got. They had an emulation mode in early Itania, but it was slow enough that there's no way they could say to people with a straight face that it was a viable choice. This also seems like it would raise tensions with Microsoft, who is equally beholden to the promise of "your old closed-source stuff will still work in 20 years." They have to figure out how to work around the factors Intel has given them.
        pjmlp 4y ago
        As proven by all ARM attempts, Microsoft is also allowing themselves a certain flexibility, also do not forget that for Alpha they did colaborate on a x86 JIT compiler for Windows NT.
      - yjftsjthsd-h 4y ago
        Are you implying that Intel created Itanium in response to AMD64? Because my impression, backed by checking dates on Wikipedia, is that IA64 was in the works for years before AMD64 - https://en.wikipedia.org/wiki/IA-64 https://en.wikipedia.org/wiki/IA-64 says "Intel and HP partnered in 1994 to develop the IA-64 ISA [...] The original goal year for delivering the first Itanium family product, Merced, was 1998." and https://en.wikipedia.org/wiki/X86-64#History https://en.wikipedia.org/wiki/X86-64#History frames AMD64 as a response to Itanium, and says "AMD originally announced AMD64 in 1999 [...] The first AMD64-based processor, the Opteron, was released in April 2003.". Edit: Or are you suggesting only that IA-64 went horribly wrong because Intel couldn't bully the market into accepting it?
        pjmlp 4y ago
        I am implying that if AMD wasn't allowed the x86 licenses that enabled them to create AMD64, the market had to deal with Itanium no matter what, Windows was already ported, some big UNIX names like HP had offerings, and that would be it, done.
deleted 4y ago
[deleted]
wk_end 4y ago
Out-of-order execution is a feature of the microarchitecture, not the ISA. That is, RISC-V is an instruction set - it defines the language you use to describe work to the processor. Any given RISC-V processor needs to understand that language, but how it actually does the work is up to it. Out-of-order execution means that the CPU, internally, won't necessarily do the work in the order given, which lets it use its internal resources more efficiently...but externally there should be no observable difference.
- pjmlp 4y ago
  As we learned back in the Pentium days, there are observable differences anyway, if anything in performance, and unless the out-of-order execution is super clever, Assembly needs to be written in a form that helps the CPU units to work best.
  - throwaway4good 4y ago
    As chips grow more and more complex the ISA matters less and less for performance. Of course it still matters for vendor lock-in (ie Windows only running on X86) and politics (license fees and preventing China from using it).
    - pavlov 4y ago
      Windows runs pretty well on ARM64 these days. They even have emulation for x86 plugins loaded into ARM binaries. All it really needs is Qualcomm to come out with ARM chips that could compete with Apple’s. Of course that’s a tall order…
  - VLM 4y ago
    > if anything in performance Have to be careful not to leak data in a crypto timing attack. A good analogy of the problem would be: If one compared a long secure password one byte at a time and instantly returned an error upon failure of first match, it looks like a nice long password, but with an oscilloscope you could figure out the long password by repeatedly guessing one byte of the password at a time because each time you get one byte's worth correct, it fails a couple cycles later in the process. It "feels" like a 16 character string should be somewhat less than 2 * 128 bits of security (aside from normal looking text doesn't use all 8 bits per byte) but it would really only require on average 16 * 128 attempts to crack any 16 character password via this timing attack because on average you'd guess the next letter of the password every hundred or so attempts. Obviously real attacks are more obscure, but anything that messes with control flow is worrisome. Its theoretically possible to write code that would be secure on a "dumb" processor but under some kind of branch predicting out of order "smart" processor that might not even exist at the time the code is written, running the code might leak crypto data. This can all be worked around at some effort.

is out of order processing part of the open spec for RISC-V? or something they added on top?

rwmj 4y ago

It would be an implementation detail, why would the ISA spec need to cover it?

msla 4y ago
> It would be an implementation detail, why would the ISA spec need to cover it? Someone asking this in a thread about MIPS is somewhat amusing. Back in The Day (1986) the MIPS I architecture had a few "implementation details" in its ISA, like branch delay slots (even if you take a jump opcode, the next opcode in the instruction stream after that jump is still executed) and load delay slots (the data from a load opcode isn't immediately available, and this delay is software-visible) and integer multiplication and division opcodes that not only had architectural delay slots, executing in parallel with the instructions after the multiplication or divide opcode, but stored their results in special HI and LO registers not used for any other purpose. The underlying goal was to make a chip with a heavy focus on pipelining.
- rwmj 4y ago
  The extra funny thing is that later revisions of the architecture had to carry all that dead weight around long after the microarchitecture changed so it was no benefit. And then Intel made pretty much the same mistake with Itanic.
  - pjmlp 4y ago
    Itanic only happened because AMD had the licenses to produce AMD64, otherwise Intel would eventually managed to push it to everyone else, no matter what.
    - hakfoo 4y ago
      I'm curious how far in advance Intel had planned out the IA-64 vision. Itanium makes more sense if viewed through the lens of "we want to get into the high-margin spaces currently occupied by boutique architectures like Alpha, PA-RISC, SPARC, etc." This is a place where they could say "recompile all your software for 30% more performance" and get away with it. If they sincerely imagined "one day, we also cut over from x86 to IA-64 on the desktop", they must have expected that to happen several generations further along than the platform ever got. They had an emulation mode in early Itania, but it was slow enough that there's no way they could say to people with a straight face that it was a viable choice. This also seems like it would raise tensions with Microsoft, who is equally beholden to the promise of "your old closed-source stuff will still work in 20 years." They have to figure out how to work around the factors Intel has given them.
      - pjmlp 4y ago
        As proven by all ARM attempts, Microsoft is also allowing themselves a certain flexibility, also do not forget that for Alpha they did colaborate on a x86 JIT compiler for Windows NT.
    - yjftsjthsd-h 4y ago
      Are you implying that Intel created Itanium in response to AMD64? Because my impression, backed by checking dates on Wikipedia, is that IA64 was in the works for years before AMD64 - https://en.wikipedia.org/wiki/IA-64 https://en.wikipedia.org/wiki/IA-64 says "Intel and HP partnered in 1994 to develop the IA-64 ISA [...] The original goal year for delivering the first Itanium family product, Merced, was 1998." and https://en.wikipedia.org/wiki/X86-64#History https://en.wikipedia.org/wiki/X86-64#History frames AMD64 as a response to Itanium, and says "AMD originally announced AMD64 in 1999 [...] The first AMD64-based processor, the Opteron, was released in April 2003.". Edit: Or are you suggesting only that IA-64 went horribly wrong because Intel couldn't bully the market into accepting it?
      - pjmlp 4y ago
        I am implying that if AMD wasn't allowed the x86 licenses that enabled them to create AMD64, the market had to deal with Itanium no matter what, Windows was already ported, some big UNIX names like HP had offerings, and that would be it, done.

deleted 4y ago

[deleted]

wk_end 4y ago

Out-of-order execution is a feature of the microarchitecture, not the ISA. That is, RISC-V is an instruction set - it defines the language you use to describe work to the processor. Any given RISC-V processor needs to understand that language, but how it actually does the work is up to it. Out-of-order execution means that the CPU, internally, won't necessarily do the work in the order given, which lets it use its internal resources more efficiently...but externally there should be no observable difference.

pjmlp 4y ago
As we learned back in the Pentium days, there are observable differences anyway, if anything in performance, and unless the out-of-order execution is super clever, Assembly needs to be written in a form that helps the CPU units to work best.
- throwaway4good 4y ago
  As chips grow more and more complex the ISA matters less and less for performance. Of course it still matters for vendor lock-in (ie Windows only running on X86) and politics (license fees and preventing China from using it).
  - pavlov 4y ago
    Windows runs pretty well on ARM64 these days. They even have emulation for x86 plugins loaded into ARM binaries. All it really needs is Qualcomm to come out with ARM chips that could compete with Apple’s. Of course that’s a tall order…
- VLM 4y ago
  > if anything in performance Have to be careful not to leak data in a crypto timing attack. A good analogy of the problem would be: If one compared a long secure password one byte at a time and instantly returned an error upon failure of first match, it looks like a nice long password, but with an oscilloscope you could figure out the long password by repeatedly guessing one byte of the password at a time because each time you get one byte's worth correct, it fails a couple cycles later in the process. It "feels" like a 16 character string should be somewhat less than 2 * 128 bits of security (aside from normal looking text doesn't use all 8 bits per byte) but it would really only require on average 16 * 128 attempts to crack any 16 character password via this timing attack because on average you'd guess the next letter of the password every hundred or so attempts. Obviously real attacks are more obscure, but anything that messes with control flow is worrisome. Its theoretically possible to write code that would be secure on a "dumb" processor but under some kind of branch predicting out of order "smart" processor that might not even exist at the time the code is written, running the code might leak crypto data. This can all be worked around at some effort.