ARM chips have an instruction with JavaScript in the name

Post by formerly_proven » Sat, Oct 17, 2020, 7:42 PM UTC

klelatti wrote: post #43

olliej wrote: post #37

Earlier quoted context omitted.

Correct, the overhead is minimal - it basically just makes the float->int conversion use a fixed set of rounding and clamping modes, irrespective of what the current mode flags are set to. The problem is JS's double->int conversion was effectively defined as "what wintel does by default", so on arm, ppc, etc you need a follow on branch that checks for the clamping requirements and corrects the result value to what x8…

Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Sounds too like performance gains will depend on how often the branch is taken which seems highly dependent on the values that are being converted?

Post by brundolf » Sat, Oct 17, 2020, 7:51 PM UTC

formerly_proven wrote: post #51

klelatti wrote: post #43

Earlier quoted context omitted.

Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Sounds too like performance gains will depend on how often the branch is taken which seems highly dependent on the values that are being converted?

> Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Most languages don't start with a spec, so the semantics of a lot of these get later specced as "uhhhhh whatever the C compiler did by default on the systems we initially built this on".

Post by olliej » Sat, Oct 17, 2020, 7:53 PM UTC

freeone3000 wrote: post #44

klelatti wrote: post #43

Earlier quoted context omitted.

Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Sounds too like performance gains will depend on how often the branch is taken which seems highly dependent on the values that are being converted?

The branch always has to be taken if executing JavaScript, because otherwise how would you tell if the value was correct or not? You'd have to calculate it using this method regardless and then compare!

Post by ramshorns » Sat, Oct 17, 2020, 8:03 PM UTC

mhh__ wrote: post #2

Unless I misread the current arm docs, I don't think this is still present in the ISA as of 2020? The whole RISC/CISC thing is long dead anyway, so I don't really mind having something like this on my CPU. Bring on the mill (I don't think it'll set the world on fire if they ever make it to real silicon but it's truly different)

Post by elygre » Sat, Oct 17, 2020, 8:06 PM UTC

alain94040 wrote: post #39

mhh__ wrote: post #2

Unless I misread the current arm docs, I don't think this is still present in the ISA as of 2020? The whole RISC/CISC thing is long dead anyway, so I don't really mind having something like this on my CPU. Bring on the mill (I don't think it'll set the world on fire if they ever make it to real silicon but it's truly different)

To understand RISC, ignore the acronym it stands for, instead just think fixed-instruction, load-store architecture. That's what RISC really means today. No variable-length instructions. No arithmetic instructions that can take memory operands, shift them, and update their address at the same time.