Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM chips have an instruction with JavaScript in the name

stackoverflow.com

Post reply on HN
Print view View original

111–120 of 312 posts

Re: ARM chips have an instruction with JavaScript in the name

#111

Post by andromeduck »

FullyFunctional wrote: post #65
elygre wrote: post #59

Earlier quoted context omitted.

Someone once explained it like “not a reduced set, but a set of reduced instructions”. Not r(is)c, but (ri)sc. Pretty much what you say, I just liked the way of describing it.

It seems to me people are ignoring that the C stands for Complexity. What's reduced is Complexity of the instruction set, not the size of it (or even the instructions themselves). In the context of the coinage of the term, they almost certainly could have called it "microcode-free ISA", but it wouldn't have sounded as cool.

Is ARM even microcode free these days?

Re: ARM chips have an instruction with JavaScript in the name

#112

Post by FullyFunctional »

dimeatree wrote: post #95
FullyFunctional wrote: post #73

Earlier quoted context omitted.

Personally I think this would be unfortunate as I don't think JavaScript is the path forward, but computers have always existed to run software (d'oh), which mean the natural selection will obviously make this happen if there is a market advantage. However I see all high performance web computing moving to WASM and JavaScipt will exist just as the glue to tie it together. Adding hardware support for this is naive and…

It would mean JavaScript would have to compile to the same byte code less there are multiple instruction sets.

Unlike Java there's no official bytecode and all implementation do it differently. I don't think any high performance implementation use bytecodes, but instead uses threaded code for their 1st tier, and native code for all others.

Re: ARM chips have an instruction with JavaScript in the name

#113

Post by domenicd »

goatlover wrote: post #103
tekromancr wrote: post #87

Earlier quoted context omitted.

Today's JavaScript is so divorced, so radically different from the the original implementation to be considered a different language, though.

Isn’t modern JS backward compatible with 1.1?

Mostly. See https://tc39.es/ecma262/#sec-additions-and-changes-that-intr... for a comprehensive list of backward-incompatible changes in the spec.

Using that list to answer your question is a bit tricky, since it also includes backward-compatibility breaks with newer features. But, e.g.,

> In ECMAScript 2015, ToNumber applied to a String value now recognizes and converts BinaryIntegerLiteral and OctalIntegerLiteral numeric strings. In previous editions such strings were converted to NaN.

and

> In ECMAScript 2015, the Date prototype object is not a Date instance. In previous editions it was a Date instance whose TimeValue was NaN.

sound like backward-incompatible changes to a JS 1.1 behavior.

Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks...

Re: ARM chips have an instruction with JavaScript in the name

#114

Post by randomsearch »

FullyFunctional wrote: post #73
chubot wrote: post #60

Emery Berger argues that the systems community should be doing exactly this -- improving infrastructure to run JS and Python workloads: https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irra... We need to incorporate JavaScript and Python workloads into our evaluations. There are already standard benchmark suites for JavaScript performance in the browser, and we can include applications written in node.js (serv…

Personally I think this would be unfortunate as I don't think JavaScript is the path forward, but computers have always existed to run software (d'oh), which mean the natural selection will obviously make this happen if there is a market advantage. However I see all high performance web computing moving to WASM and JavaScipt will exist just as the glue to tie it together. Adding hardware support for this is naive and…

Yeah WASM killing JS is an outside bet for this decade. Could happen. (Please Lord).

Re: ARM chips have an instruction with JavaScript in the name

#115

Post by domenicd »

robocat wrote: post #27
amelius wrote: post #16

Earlier quoted context omitted.

Don't sufficiently advanced compilers infer what the real type of a variable is, in the most important cases?

First comment on question: “The JavaScript engine has to do this operation (which is called ToInt32 in the spec) whenver you apply a bitwise operator to a number and at various other times (unless the engine has been able to maintain the number as an integer as an optimization, but in many cases it cannot). – T.J. Crowder” Edit: From https://www.ecma-international.org/ecma-262/5.1/#sec-9.5 9.5 ToInt32: (Signed 32 Bit…

Remember not to refer to outdated specs; the modern version is at https://tc39.es/ecma262/#sec-toint32 . The changes look editorial modernizations (i.e., I don't think there have been any bugfixes to this low-level operation in the 9 years since ES 5.1 was published), but it's better to be safe than sorry, and build the right habits.

Re: ARM chips have an instruction with JavaScript in the name

#116

Post by FullyFunctional »

masklinn wrote: post #109
FullyFunctional wrote: post #73

Earlier quoted context omitted.

Personally I think this would be unfortunate as I don't think JavaScript is the path forward, but computers have always existed to run software (d'oh), which mean the natural selection will obviously make this happen if there is a market advantage. However I see all high performance web computing moving to WASM and JavaScipt will exist just as the glue to tie it together. Adding hardware support for this is naive and…

The quote isn't really saying that JS-specific instructions need be added to the ISA though.

In that sense it's not saying anything different from what we have been doing for the past 60 years.

The only significant thing that has changed is that power & cooling is no longer free, so perf/power is a major concern, especially for datacenter customers.

Re: ARM chips have an instruction with JavaScript in the name

#117

Post by jleahy »

olliej wrote: post #37
klelatti wrote: post #31

Given that the instruction set already has a float to integer conversion it seems likely that the overhead of implementing this would be small and so given the performance (and presumably energy) win quoted elsewhere seems like a good move. It would be interesting to know the back story on this: how did the idea feed back from JS implementation teams to ARM. Webkit via Apple or V8 via Google?

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…

Not quite. JS is round towards zero, ie. the same as C. If you look at the x86 instruction set then until SSE2 (when Intel specifically added an extra instruction to achieve this) this was extremely awkward to achieve. x86 always did round-to-nearest as the default.

The use of INT_MIN as the overflow value is an x86-ism however, in C the exact value is undefined.

Re: ARM chips have an instruction with JavaScript in the name

#118

Post by klelatti »

throwaway_pdp09 wrote: post #102
matthewmacleod wrote: post #90

Earlier quoted context omitted.

Let the hardware do best what it's good at, being simple and running fast. Let the interpreter/compiler layer do its thing best, flexibility. Yeah, this is pretty much the opposite of what actually works in practice for general-purpose processors though – otherwise we'd all be using VLIW processors.

The complex processors like the PDPs were followed by risc processors because they were simpler. The hardwrae has to run code, I get that, but VLIW didn't work. Risc did. The x86 decompiles its opcodes into micro-ops which are load/store risc-y simple things. Simplicity was always the way to go. I do take your point about VLIW, but I'm kind of assuming that the CPU has to, you know, actually run real workloads. So mo…

When RISC first appeared they really were simpler than competing designs.

But today I think it's hard to argue that modern pipelined, out of order processors with hundreds of millions of transistors are in any sense 'simple'.

If there is a general lesson to be learned it's that the processor is often best placed to optimise on the fly rather than have the compiler try to do it (VLIW) or trying to fit a complex ISA to match the high level language you're running.

Re: ARM chips have an instruction with JavaScript in the name

#119

Post by masklinn »

offbynull wrote: post #86

Anyone else remember the ARM Jazelle DBX extension? I wonder if they'll end up dumping this in this the same way. I don't remember very many phones supporting DBX, but IIRC the ones that did seemed to run J2ME apps much smoother.

It's quite different though, Jazelle literally implemented java bytecode in hardware.

These instructions "merely" performs a float -> int conversion with JS semantics, such that implementations don't have to reimplement those semantics in software on ARM. The JS semantics probably match x86 so x86 gets an "unfair" edge and this is a way for ARM to improve their position.

Re: ARM chips have an instruction with JavaScript in the name

#120

Post by masklinn »

FullyFunctional wrote: post #116
masklinn wrote: post #109

Earlier quoted context omitted.

The quote isn't really saying that JS-specific instructions need be added to the ISA though.

In that sense it's not saying anything different from what we have been doing for the past 60 years. The only significant thing that has changed is that power & cooling is no longer free, so perf/power is a major concern, especially for datacenter customers.

> In that sense it's not saying anything different from what we have been doing for the past 60 years.

Yes it is? The essay's point is that "standard" hardware benchmark (C and SPEC and friends) don't match modern workloads, and should be devaluated in favour of better matching actual modern workloads.

Post reply on HN