NOOOOOOOO

4 Js-core @ 2.00 GHz

I'll take 10. Here is a picture of a goldfish as payment.

I love the idea that we could need a dedicated chip to parse web pages 😂

We did it!

Answer: there'd be far less software in the world, it would all be more archaic and less useful, and our phones and laptops would just sit at 2% utilization most of the time.

There's an opportunity cost to everything, including fussing over whether that value can be stored as an int instead of a double to save 8 bits of space. High level languages let developers express their feature and business logic faster, with fewer bugs, and much lower ongoing maintenance costs.

Even if our apps used resources better the adware will just use the free space.

I fully concur. There's tons of really inefficient software out there that wastes resources just because for a long time, available resources grew fast enough to just keep using more of them without the net speed of an application slowing down. If we didn't have so many lazy SW devs, I suspect the reduction in needed CPU cycles would have a measurable positive effect on climate change.

The website title says "Arm Developer", not "ARM Developer", in a clearly non-acronym way so it's a guide for making prosthetic hardware. Of course you want a cyborg arm to parse JS natively, why else even get one?

Lie starts with L, dummy

Nope it's still a register-register op, that's very much load-store architecture.

It's reduced, not minimalist, otherwise every RISC CPU out there would only have one instruction like decrement and branch if nonzero. RISC-V would not have an extension mechanism. The instruction exists because it makes things faster because you don't have to do manual bit-fiddling over 10 instructions to achieve a thing already-existing ALU logic can do in a single cycle. A thing that isn't even javascript-specific (or terribly relevant to json), it's a specific float to int cast with specific rounding and overflow mode. Would it more palatable to your tastes if the CPU were to do macro-op fusion on 10(!) instructions to get the same result?

No, that's not what RISC is about. There was some early attempts to keep the number of instructions low--originally, ARM didn't have a multiply instruction, and there's still a bunch of microcontrollers you can buy that don't have a divide instruction--but it was quickly abandoned as it's just not that useful. It only holds back instructions that optimize common cases. Your compiler can implement multiplication by doing addition in a loop, but that's not very efficient.

What really worked about it was keeping a separation between how memory is accessed. You don't have an ADD instruction that can fetch from both registers or main memory. You have a MOV instruction that can fetch from memory into a register, and you have an ADD instruction that can work on registers.

ARM still does this just fine.