You guys have interesting takes on RISC V and that video. I look at things differently and there are some misconceptions to clear up, so some comments:
Clearly Chris Celio is being a bit playful when he make the claim that ARM is "CISCy". But it's not without merit, the ARM instruction sets (There are many) are huge compared to RISC V. If you want to see how CISCy they are just print out the instruction set references and weigh them!
Clearly those Berkeley researcher know the various instruction sets well. They have been studying them longer than most people have been alive.
I watched the video again, his comments re: micro-ops are sound. They were mostly to do with Intel's string operations. That ARM LDMIAEQ example is also sound, the number of clocks it takes to execute is "1+Nb (+Pa if PC loaded)" according to the manual, clearly there are "micro-ops" going on there.
The use of -O3 is quite fine and to be expected. Same compiler, same version, same options, across all 6 architectures he looks at. If anything that gives RISC V a disadvantage as GCC support is fairly new and there may be further optimizations that have not been realized yet.
If you want other RISC V presentations just type "risc v" into YouTube.
Berkeley RISC and MIPS are in the same bucket in my mind. Both research projects looking at RISC ideas at about the same time. Both inspired by earlier work in reduced instruction sets at IBM. Their respective project leaders, Hennessy and Patterson, were close collaborators and wrote the book
on it together:
https://www.amazon.com/Computer-Organiz ... +Patterson
I think it's very likely that RISC V will displace a lot of ARM in the future. Why would it not? If it's small and low power and equally performant why would anyone choose to pay SoftBank to use ARM? Similar arguments apply all the way up to cloud server and super computer applications, and there are people working on it around the world.
When it comes to status flags, conditional execution etc, I'm going to bet that the likes of Hennessy and Patterson and all their grad students have been looking into such things for decades. Especially with regard how they play with available compiler technology. Seems they have found none of that is of any benefit. They would not toss out an idea lightly.
DavidS has a lot of interesting comments about instruction decoding, barrel shifters, multiple-dispatch, in order vs out of order, execution, memory access, etc. All of that is in the implementation, build it how you like. RISC V is only an instruction set specification.
I suspect the reason thumb mode was not mentioned is that it does not exist on 64 bit ARM. Also GCC will use thumb instructions if advantageous in 32 bit ARM. If I understand correctly.
Yes, there are a lot of optional parts to the RISC V spec. That does not make things non-portable, just recompile and go. Or make use of undefined instruction traps and do the op in software. Also there is concept of the "G" variant which includes all the options one will need for a reasonable general purpose machine running Linux or whatever.
Options are good. It means I can write my own RISC V. It means we can fit them into small spaces. It means companies can add extensions in a clean way for their "secret sauce" hardware.
Yes ARM dominates in some markets. It has not displaced all low end micro-controllers. Now that MCUs are available down to 5 cents a piece, the guys that make them will not want to being paying royalties to SoftBank. Already we are seeing innovative new MCU products coming out that are RISC V based.
Finally, an important point: There will never be a "next version" of RISC V. It's a published standard. It is intended to be fixed in concrete. There will not be a RISC V with redundant features like "proper flags" or conditional execution. Contrary to David's assertion such things have little or no performance benefit and only make implementation more complex.
You are of course free to add extensions to RISC V that have such things. Which would be a good exercise: Implement it in Verilog, getting it working on FPGA and report back any performance gains you have made.
Phew... that was a long ramble...