31–40 of 312 posts
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?
Earlier quoted context omitted.
No it doesn’t, it’s still surprising to see a CPU instruction added specifically to cater for such a high level language like JS. It does totally makes sense though, given the importance of JS and it’s common use in mobiles.
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,…
It seems like every 2 months I feel the burn of JS not having more standard primitive types and choices for numbers. I get this urge to learn Rust or Swift or Go which lasts about 15 minutes... until I realize how tied up I am with JS. But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development.
I think that day might be sooner than anyone thinks- Chromium is dominant enough now that their including Dart as a first-class language (or more likely, a successor to Dart) will likely be a viable strategy soon.
Of course, the wildcard is Apple, but ultimately Dart can compile down to JS- being able to write in a far superior language that natively runs on 80% of the market and transpiles to the rest is suddenly much more of a winning proposition.
FTA: > Which is odd, because you don't expect to see JavaScript so close to the bare metal. This seems to ignore all the work done on server-side javascript with projects such as node.js and deno, as well as the fact that cloud service providers such as AWS have been developing their own ARM-based servers.
Just because a language is used on servers / at scale / in enterprise, doesn't make it any closer to the metal. I mean, look at Python, Java, or Ruby: All used on servers for "serious" applications, but certainly not any sort of "bare metal" languages still.
It seems like every 2 months I feel the burn of JS not having more standard primitive types and choices for numbers. I get this urge to learn Rust or Swift or Go which lasts about 15 minutes... until I realize how tied up I am with JS. But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development.
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”.
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?
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 x86 does.
Honestly it would not surprise me if the perf gains are due to removing the branch rather than the instruction itself.
It seems like every 2 months I feel the burn of JS not having more standard primitive types and choices for numbers. I get this urge to learn Rust or Swift or Go which lasts about 15 minutes... until I realize how tied up I am with JS. But I do think one day (might take a while) JS will no longer be the obvious choice for front-end browser development.
Are you saying you'd like to have specific int32, int64, float32, float64 types?
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)
No variable-length instructions. No arithmetic instructions that can take memory operands, shift them, and update their address at the same time.
My guess is that this is what JIT people asked for.
Don't sufficiently advanced compilers infer what the real type of a variable is, in the most important cases?
The real problem is that JS inherited the x86 behavior, so everyone has to match that. The default ARM behavior is different. All this instruction does is perform a standard fpu operation, but instead of passing the current mode flags to the fpu, it passes a fixed set irrespective of the current processor mode.
As far as I can tell, any performance win comes from removing the branches after the ToInt conversion that are normally used to match x86 behavior.