So does x86. The difference is license. Just like how Intel and AMD have a VERY different design (implementation) as of now, so does RISC-V. Any vendor can implement it however they want, but they won't have to pay anyone for using RISC-V ISA

No, it was about the prediction engines that contain security vulnerabilities. Problem is that software has no control over that, because hardware does future predictions for performance optimization.

I mean, that's all chip architectures are, so yes.

Sorry, AAA games. I was swiping on my keyboard and didn't see the mistake.

I understand some instruction expansions today are used to good effect in x86, but that there are also a sizeable number of instructions that are rarely utilized by compilers and are mostly only continuing to exist for backwards compatibility. That does not really make me think "more instructions are usually better". It makes me think "CISC ISAs are usually bloated with unused instructions".

My whole understanding is that while more specific instruction options do provide benefits, the use-cases of these instructions make up a small amount of code and often sacrifice single-cycle completion. The most commonly cited benefit for RISC is that RISC can complete more work (measured in 'clockcycles per program' over 'clockrate') in a shorter cyclecount, and it's often argued that it does so at a lower energy cost.

I imagine that RISC-V will introduce other standards in the future (hopefully after it's finalized the ones already waiting), hopefully with thoroughly thought out instructions that will actually find regular use.

I do see RISC-V proponents running simulated benchmarks showing RISC-V is more effective. I have not seen anything similar from x86 proponents, who usually either make general arguments, or worse , just point at the modern x86 chips that have decades of research, funding, and design behind them.

Overall, I see alot of doubt that ISAs even matter to performance in any significant fashion, and I believe it for performance at the GHz/s level of speed.

I don't know, if your platform doesn't have a jre... Is it really a platform?

It sounds like you're just reinventing either the JVM (runtime instruction translation), compilers (LLVM IR), or something in between (JIT interpreters).

The problem is that it's a hard problem to solve generally without expensive tradeoffs:

• interpreter like JVM - will always have performance overhead and can't easily target arch-specific optimizations like SIMD
• compiler - need a separate binary per arch, or have large binaries that can do multiple
• JIT - runtime cost to compiling optimizations

Each is fine and has a use case, but I really don't think we need a hardware agnostic layer, we just need languages that help alleviate issues with different architectures. For example, Rust's ownership model may help prevent bugs that out of order execution may expose. It could also allow programmers to specify more strict limits on types (e.g. non-zero numbers, for example), which could aid arch-specific optimizations).