ARM chips have an instruction with JavaScript in the name • Hacker News Board

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

#151

Post by phkahler » Sat, Oct 17, 2020, 11:11 PM UTC

Joker_vD wrote: post #76

secondcoming wrote: post #52

Earlier quoted context omitted.

Nothing justifies the prolonging of Javascript torture.

Nothing justifies the prolonging of C torture either, except of the C's wide spread. Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings?

>> Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings?

Because exposing that would be a huge burden on the compiler writers. Intel tried to move in that direction with Itanium. It's bad enough with every new CPU having a few new instructions and different times, the compiler guys would revolt if they had to care how many virtual registers existed and all the other stuff down there.

But why C? If you want languages to interface with each other it always comes down C as a lowest common denominator. It's even hard to call C++ libraries from a lot of things. Until a new standard down at that level comes into widespread use hardware will be designed to run C code efficiently.

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

#152

Post by olliej » Sat, Oct 17, 2020, 11:16 PM UTC

asddubs wrote: post #141

domenicd wrote: post #113

Earlier quoted context omitted.

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 n…

>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... can you explain what you mean? Did early js implementations not have functions inheriting the block scope?

If they’re referring to lexical block scope then indeed, js historically did not have block scoping, it was function and global scoped.

There are also differences in how eval works, etc

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

#153

Post by scottlamb » Sat, Oct 17, 2020, 11:17 PM UTC

Someone wrote: post #134

scottlamb wrote: post #127

Earlier quoted context omitted.

> With variable length instructions one must decode a previous one to figure out where the next one will start. People said the same thing about text encodings. Then UTF-8 came along. Has anyone applied the same idea to instruction encoding?

That would eat precious bits in each instruction (one in each byte, if one only indicates ‘first’ or ‘last’ bytes of each instruction). It probably is better to keep the “how long is this instruction” logic harder and ‘waste’ logic on the decoder.

That doesn't sound so bad to me, in comparison to fixed-size instructions. One bit in each byte gone to have the most common instructions take one byte instead of four. I can imagine that allowing much denser code overall.

Or it could be one bit out of every pair of bytes, to support 2-, 4-, and 6-byte instructions. I don't know much about ARM Thumb-2, except that it does 2- or 4-byte instructions, so clearly someone thought this much was a good idea.

Instruction encodings are below my usual abstraction layer; I'm just speculating...

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

#154

Post by StillBored » Sat, Oct 17, 2020, 11:18 PM UTC

alquemist wrote: post #148

randomsearch wrote: post #114

Earlier quoted context omitted.

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

We are no longer in 2005. Javascript, especially in its Typescript flavor, is a perfectly capable modern language.

Its not that it isn't capable, its that it has more gocha's than most other languages of it size (and no, just because the gocha is well defined doesn't mean that it doesn't trip programmers up).

Its also despite a couple decades of hard work by some very good compiler/JIT engineers at a considerable disadvantage perf wise to a lot of other languages.

Third its most common runtime environment, is a poorly thought out collection DP and UI paradigms that don't scale to even late 1980's levels, leading to lots of crutches. (AKA, just how far down your average infinite scrolling web page can you go before your browser either takes 10s of seconds to update, or crashes?).

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

#155

Post by titzer » Sat, Oct 17, 2020, 11:18 PM UTC

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…

> The problem is JS's double->int conversion was effectively defined as "what wintel does by default",

No, JavaScript "double to int conversion" (which only happens implicitly in bitwise operations such as |, &, etc) is not like any hardware instruction at all. It is defined to be the selection of the low-order 32-bits of a floating point number as-if it were expanded to its full-width integer representation, dropping any fractional part.

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

#156

Post by [deleted] » Sat, Oct 17, 2020, 11:19 PM UTC

jleahy wrote: post #117

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…

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.

[deleted]

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

#157

Post by why_only_15 » Sat, Oct 17, 2020, 11:23 PM UTC

monocasa wrote: post #146

why_only_15 wrote: post #69

Earlier quoted context omitted.

The JSC JIT people seemed kind of surprised by this, which was weird. Maybe the V8 JIT people asked for it?

Is there a source for that? I was under the impression this initially shipped on iOS devices so it'd be weird for JSC to be surprised by it.

According to this bug it was shipped six months after the bug was created and they didn't seem super familiar with it.

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

#158

Post by phkahler » Sat, Oct 17, 2020, 11:26 PM UTC

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…

That's rather silly. He says:

"For example, we should care less if a proposed mobile chip or compiler optimization slows down SPEC, and care more if it speeds up Python or JavaScript!"

But anything that impacts SPEC benchmarks (and the others we use for C code) is also going to impact Python performance. If you could find a new instruction that offers a boost to the Python interpreter performance that'd be nice, but it's not going to change the bigger picture of where the language fit in.

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

#159

Post by StillBored » Sat, Oct 17, 2020, 11:33 PM UTC

kps wrote: post #107

saagarjha wrote: post #94

Earlier quoted context omitted.

You do understand that current hardware exists to support C, right?

What aspect of currently popular CPU instruction sets ‘exists to support C’?

A shocking amount, but in a many cases its also what doesn't exist, or isn't optimized. C is designed to be a lowest common denominator language.

So, the whole flat memory model, large register machines, single stack registers. When you look at all the things people think are "crufty" about x86, its usually through the lenses of "modern" computing. Things like BCD, fixed point, capabilities, segmentation, call gates, all the odd 68000 addressing modes, etc. Many of those things that were well supported in other environments but ended up hindering or being unused by C compilers.

On the other side you have things like inc/dec two instructions which influence the idea of the unary ++ and -- rather than the longer more generic forms. So while the latency of inc is possibly the same as add, it still has a single byte encoding.

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

#160

Post by still_grokking » Sat, Oct 17, 2020, 11:56 PM UTC

phkahler wrote: post #151

Joker_vD wrote: post #76

Earlier quoted context omitted.

Nothing justifies the prolonging of C torture either, except of the C's wide spread. Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings?

>> Why do you think modern CPUs still expose mostly C-abstract-machine-like interface instead of their actual out-of-order, pipelined, heterogeneous-memory-hierarch-ied internal workings? Because exposing that would be a huge burden on the compiler writers. Intel tried to move in that direction with Itanium. It's bad enough with every new CPU having a few new instructions and different times, the compiler guys would…

> Until a new standard down at that level comes into widespread use hardware will be designed to run C code efficiently.

Exactly this hinders any substantial progress in computer architecture for at least 40 years now.

Any hardware today needs to simulate a PDP-7 more or less… As otherwise the hardware is doomed to be considered "slow" should it not match the C abstract machine (which is mostly a PDP-7) close enough. As there is no alternative hardware available nobody invests in alternative software runtime models. Which makes investing in alternative hardware models again unattractive as no current software could profit from it. Here we're gone full circle.

It's a trap. Especially given that improvements in sequential computing speed are already difficult to achieve and it's known that this will become even more and more difficult in the future, but the computing model of C is inherently sequential and it's quite problematic to make proper use of increasingly more parallel machines.

What we would need to overcome this would be a computer that is build again like the last time many years ago, as a unit of hard and software which is developed hand in hand with each other form the ground up. Maybe this way we could finally overcome the "eternal PDP-7" and move on to some more modern computer architectures (embracing parallelisms in the model from the ground up, for example).