5 ms·

ISA's today don't need to be human understandable. ISA's of old would have an "ADD" instruction that added two numbers. New ISA's should have crazy complex in

ISA's today don't need to be human understandable. ISA's of old would have an "ADD" instruction that added two numbers. New ISA's should have crazy complex instructions that implement things helpful to make javascript/python/whatever run fast. We should set mostly-automated design-space-search programs off to consider millions of autogenerated new instructions and simultaneously figure out how that would impact compilers, CPU design, power consumption, performance, etc.

saagarjha 3y ago
There is no "one" thing that makes JavaScript or Python run fast. And even if there was, how do you know the Python of 10, 20, 30 years from now still does that? What happens if someone buys your processor but they aren't running JavaScript on it? We have accelerator blocks for specialized tasks (media decoding, matrix multiplication, …) already. Doing this for other things is hard. The post itself talks about a failed attempt called Jazelle that was only really useful under a very specific set of constraints.
- znpy 3y ago
  Older ARM cpus had a whole extension named Jazelle to execute jvm bytecode in hardware. https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
  - saagarjha 3y ago
    Yes, this is what I was referring to :)
  - charlieyu1 3y ago
    Interesting. In a hypothetical future we may have CPUs running Python/JS bytecodes directly. We are nowhere near that point though. Probably would only happen if we have a grand unification of CPU architectures.
- rbanffy 3y ago
  > There is no "one" thing that makes JavaScript or Python run fast. IIRC, The M series processors were explicitly designed with extra instructions for commonly used JS functionality. Compilers for that platform can rely on such instructions for other languages as well. Also, SPARC was designed to run C code fast - a function call would require little more than moving the register window to preserve the caller's context. Because of that, calling a function had a very small penalty compared to other architectures of the time.
  - duskwuff 3y ago
    > The M series processors were explicitly designed with extra instructions for commonly used JS functionality. I think I know what you're thinking of and it's a little overblown. It's a single instruction - FJCVTZS - which performs a specific type of floating-point to integer conversion. It's a standard ARMv8.3 instruction, not an Apple extension. https://developer.arm.com/documentation/dui0801/l/A64-Floating-point-Instructions/FJCVTZS--A64- https://developer.arm.com/documentation/dui0801/l/A64-Floati...
  - saagarjha 3y ago
    Compilers don't typically emit those instructions, it's people working on runtimes that need its semantics who do. Also, my understanding (to be fair I haven't really used SPARC much) is that register windows didn't really pan out as being efficient in practice. I think because people couldn't program for it?
tlb 3y ago
It's feasible to have compilers automatically figure out how to use novel ISA features. But designing a microarchitecture & logic based on a proposed ISA is still years of expert human labor, so it's hard to evaluate the performance (both ILP and clock speed) of a novel ISA.
- londons_explore 3y ago
  I dunno - in some architectures, a new instruction is just a couple of lines of verilog to implement in the silicon: https://github.com/YosysHQ/picorv32/blob/master/picorv32.v#L1068 https://github.com/YosysHQ/picorv32/blob/master/picorv32.v#L... (this is the 'subtract' alu instruction decoder in pico riscv for example)
  - rcxdude 3y ago
    That is basically a toy example though. With a design like that you do just do the simple thing, but it's not fast or efficient
- rbanffy 3y ago
  It's usually a better approach to link to libraries that decide at runtime (and save the decision somewhere) which is the optimal code path for a given architecture.

saagarjha 3y ago

There is no "one" thing that makes JavaScript or Python run fast. And even if there was, how do you know the Python of 10, 20, 30 years from now still does that? What happens if someone buys your processor but they aren't running JavaScript on it? We have accelerator blocks for specialized tasks (media decoding, matrix multiplication, …) already. Doing this for other things is hard. The post itself talks about a failed attempt called Jazelle that was only really useful under a very specific set of constraints.

znpy 3y ago
Older ARM cpus had a whole extension named Jazelle to execute jvm bytecode in hardware. https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- saagarjha 3y ago
  Yes, this is what I was referring to :)
- charlieyu1 3y ago
  Interesting. In a hypothetical future we may have CPUs running Python/JS bytecodes directly. We are nowhere near that point though. Probably would only happen if we have a grand unification of CPU architectures.
rbanffy 3y ago
> There is no "one" thing that makes JavaScript or Python run fast. IIRC, The M series processors were explicitly designed with extra instructions for commonly used JS functionality. Compilers for that platform can rely on such instructions for other languages as well. Also, SPARC was designed to run C code fast - a function call would require little more than moving the register window to preserve the caller's context. Because of that, calling a function had a very small penalty compared to other architectures of the time.
- duskwuff 3y ago
  > The M series processors were explicitly designed with extra instructions for commonly used JS functionality. I think I know what you're thinking of and it's a little overblown. It's a single instruction - FJCVTZS - which performs a specific type of floating-point to integer conversion. It's a standard ARMv8.3 instruction, not an Apple extension. https://developer.arm.com/documentation/dui0801/l/A64-Floating-point-Instructions/FJCVTZS--A64- https://developer.arm.com/documentation/dui0801/l/A64-Floati...
- saagarjha 3y ago
  Compilers don't typically emit those instructions, it's people working on runtimes that need its semantics who do. Also, my understanding (to be fair I haven't really used SPARC much) is that register windows didn't really pan out as being efficient in practice. I think because people couldn't program for it?

tlb 3y ago

It's feasible to have compilers automatically figure out how to use novel ISA features. But designing a microarchitecture & logic based on a proposed ISA is still years of expert human labor, so it's hard to evaluate the performance (both ILP and clock speed) of a novel ISA.

londons_explore 3y ago
I dunno - in some architectures, a new instruction is just a couple of lines of verilog to implement in the silicon: https://github.com/YosysHQ/picorv32/blob/master/picorv32.v#L1068 https://github.com/YosysHQ/picorv32/blob/master/picorv32.v#L... (this is the 'subtract' alu instruction decoder in pico riscv for example)
- rcxdude 3y ago
  That is basically a toy example though. With a design like that you do just do the simple thing, but it's not fast or efficient
rbanffy 3y ago
It's usually a better approach to link to libraries that decide at runtime (and save the decision somewhere) which is the optimal code path for a given architecture.