Yeah, but isn't the whole point of ARM to be a reduced instruction set? How reduced are we, really, if we're dedicating transistors to the quirks of a single language?
RISC is a misleading name, the concepts of its design are not really based around the idea of a "Reduced Instruction Set" as in "small" per se, nor are CISC machines necessarily a large size instruction set.
It is much more about the design of the instructions, generally RISC instructions take a small, fixed amount of time and conceptually are based on a sort of minimum unit of processing, with a weak to very weak memory model (with delay slots, pipeline data hazards, required alignment of data etc) with the compiler/programmer combining them into usable higher level operations.
CISC designs on the other hand happily encode large, arbitrarily complex operations that take unbounded amounts of time, and have very strong memory models (x86 in particular is infamous here, you can pretty much safely access memory, without any alignment, at any time, even thought often the result will be slow, it wont crash)
As an example, the PDP-8 has fewer than 30 instructions, but is still definitely a CISC architecture, some ARM variants have over 1000 instructions but are still definitely RISC.
RISC is about making building processors simpler, not about making instruction sets and programming with them necessarily simpler.
Well, it's not like x86 unaligned access was some cute thing they did just to make it extra complex. It made complete sense in 1976 when designing an ISA that might support implementations with an 8 bit memory bus and no cache. Why eat more bus cycles than you need?
Fast forward a decade or so and all processors had cache and multi-byte memory bus so the unaligned access and compact instruction streams are no longer necessary.
But processors these days are complex multi core beasts with IEEE fpu, simd units, mmu, memory controller, cache controller, pci-e northbridge, all kinds of voltage/thermal interplay, and even iGPU. ISA is over emphasized.
when the concerned ARM instruction is doing something perfectly capable by the software to just score 1-2% performance improvements, it is definitely CISC based on the definitions you listed above.
This Javascript related instruction is complex in terms of a bitwise operator on a single value, however complex it is still a simple operation; CISC-ness generally relates more to accessing memory or interacting with the hardware in complex ways.
From the definition given:
CISC designs on the other hand happily encode large, arbitrarily complex operations that take unbounded amounts of time, and have very strong memory models
The operation it accelerates is very simple, its just not really required much outside of javascript. It is already identical to an existing instruction, just with slightly different overflow behavior that javascript relies on.
I'd argue at this point ARM serves more value as an instruction set which isn't encumbered by the mass of x86 patents and historical legal baggage, thus meaning it's something that can reasonably be implemented by more than just two companies on the planet.
It is much more about the design of the instructions, generally RISC instructions take a small, fixed amount of time and conceptually are based on a sort of minimum unit of processing, with a weak to very weak memory model (with delay slots, pipeline data hazards, required alignment of data etc) with the compiler/programmer combining them into usable higher level operations.
CISC designs on the other hand happily encode large, arbitrarily complex operations that take unbounded amounts of time, and have very strong memory models (x86 in particular is infamous here, you can pretty much safely access memory, without any alignment, at any time, even thought often the result will be slow, it wont crash)
As an example, the PDP-8 has fewer than 30 instructions, but is still definitely a CISC architecture, some ARM variants have over 1000 instructions but are still definitely RISC.
RISC is about making building processors simpler, not about making instruction sets and programming with them necessarily simpler.