Hacker News Reader

Comment by nom | Hacker News Reader

So it was easier to add an instruction in silicon to cater for an ill-designed programming language, than to change the language itself?

I mean, if float-to-integer performance is so critical, why was this not fixed a long time ago in the language? What am I missing?

View on HN

> What am I missing?

ARM wants to be appropriate for more workloads. They don't want to have to wait for software to change. The want to sell processor designs now.

> What am I missing?

I guess the incredibly long tail of JavaScript deployments. You could change the language today and it would take years for it to percolate down to all the deployments out there. By comparison a silicon change requires zero code changes and is entirely backwards compatible. Plus there's a pretty simple marketing argument: "buy our CPU, it makes commonly-encountered workloads faster", vs "buy our CPU, when everyone upgrades the platform they use it'll be faster"

One is a technology change, the other is a culture change. The former is infinitely easier than the latter, in my opinion/experience.

Consider Node JS is a top server side language, and arm for data centers is coming ( to the extent it's not already here), this makes sense.

Technically someone can just make a better VM engine for JavaScript to execute inside of, but whatever I guess they decided this would be easier.

I'd say JS on the mobile ARM devices is 10.000x more common, and thus important, than the NodeJS on ARM servers.

Wait.

Do you mean JS inside of browsers themselves ? Or JS running in another manner

Amazon has already rolled out their own ARM servers at a very cheap price. A lot of well-funded companies are headed in that same direction. Adding this instruction encourages those designs too (very good from a licensing standpoint).

Reply on news.ycombinator.com