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

81–90 of 312 posts

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

#81

Post by sharpneli »

Joker_vD wrote: post #72
alain94040 wrote: post #39

Earlier quoted context omitted.

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.

What is with variable-length instruction aversion? Why is it better to load a 32-bit immediate with two 4-byte instructions (oh, and splitting it in 12/20 bit parts is non-intuitive because of sign extension, thanks RISC V authors) than with one 5-byte instuction?

Fixed width instructions allow trivial parallel instruction decoding.

With variable length instructions one must decode a previous one to figure out where the next one will start.

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

#82

Post by sterlind »

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…

maybe this will lead to the revival of Transmeta-like architectures? I always had a soft spot for reprogrammable microcode.

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

#83

Post by mhh__ »

userbinator wrote: post #45
alain94040 wrote: post #39

Earlier quoted context omitted.

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.

...and even ARM breaks instructions into uops, just like x86.

Of course it does. The level of abstraction required for modern pipelining and OOo scheduling is still beneath ARM. I'm not that familiar with the details of arm on paper but it's not that low level by research standards.

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

#84

Post by FullyFunctional »

orf wrote: post #23
est31 wrote: post #13

Earlier quoted context omitted.

Not surprising to me to see CPU instructions being added for widely used use cases. Basically, a CPU instruction set maker's job is to perform clustering of the tasks that the CPUs do and accelerate commonly used tasks. If people do a lot of AES, the instruction set maker adds AES extensions. If people do a lot of CRC, they add CRC instructions. If people convert doubles to integers all day in a very JS specific way,…

Can you name any other instructions with the name of a programming language in the actual instruction name? No? Then it seems way more specific than the other examples you listed. So specific that it’s only applicable to a single language and that language is in the instruction name. That’s surprising, like finding an instruction called “python GIL release”.

Well if you go far enough back, it was not usual to find special allowance for programming language constructs (like procedure linkage that supported display, useful for languages like Pascal with nested procedures etc).

The reason you don't find this is that all "modern" processors designed since ~ 1980 are machines to run ... C as the vast majority (up until ~ Java) of all software on desktops and below were written in C. This also has implications for security as catching things like out of bound access or integer overflow isn't part of C so doing it comes with an explicit cost even when it's cheap in hardware.

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

#85

Post by fred256 »

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!

If you always take a branch, it's not a branch.

Or did you mean by "taken" that the branch instruction has to be executed regardless of whether the branch is taken or not?

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

#87

Post by tekromancr »

brundolf wrote: post #53
formerly_proven wrote: post #51

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). 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".

Seeing as JavaScript was designed and implemented in two weeks, I'm betting this is the answer

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

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

#88

Post by wnoise »

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?

It's not like other languages are well-adapted to that either. That's a hard target to code for.

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

#89

Post by klelatti »

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…

It's obviously interesting to understand performance on real life JS and Python workloads and maybe to use this to inform ISA implementations.

I don't think that it's being suggested that ISAs should be designed to closely match the nature of these high level languages. This has been tried before (e.g. iAPX 432 which wasn't a resounding success!)

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

#90

Post by matthewmacleod »

throwaway_pdp09 wrote: post #80
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…

Please No. 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. There have been attempts to move the hardware 'upwards' to meet the software and it's not generally worked well. No special purpose language supporting hardware exists now that I'm aware of - lisp machines, smalltalk machines, Rekursiv, stretch, that 1980s object ori…

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.

Post reply on HN