why not use one Instruction set?

[@celikkoseoglu]

Great explanation. Please make more videos like this!

[@Muratcharms]

If i remember correctly those x86-64 type of instructions (CISC?) decoded to RISC type instructions in current desktop cpus to execute them actually faster. But if this decode phase is eliminated by changing softwares to native risc then there could be huge increase in performance and efficiency gain.. so x86-64 is already not natively used in cpus? Why software vendors insist on it? Correct me if im wrong please..

[@bassbatterer]

Yeh you've pretty much got it there, When the x86 is decoded (Or any other instructions) it's decoded into binary words where the parts of the word are explicit instructions to individual components within the CPU as to set the state of that hardware (EG tell an adder that it's next instruction will be an unsigned 32b int), that's called the micro-ops. Technically you could remove the x86 and just make you're programs in micro-ops but for one; no CPU vendor published their micro-op codes and also it's very CPU-dependant, kabylake probably has different micro-ops than skylake and those different from coffee lake even though they're from the same architecture. Not only that but for IO instructions Intel changed the micro-ops to prevent speculative execution (remember micro-ops set the state of the hardware in the cpu, including the speculative execution engine) in order to counter spectre/meltdown so any code you wrote before wouldn't work after the spectre/meltdown patches. Lastly you've kind of answered you're own question yourself, Why have CISC when we have RISC? Well we have ARM which is RISC so why not just everyone switch over to using ARM? It's more efficient because as you understand, it's easier to decode, well the answer is something only the market can decide. But at the end of the day use whatever you want to use, x86 is powerfull but power-hungy, not many of you're programs run on ARM and hell if you're going to the trouble, why not use something different from them too? ;)

[@PajakTheBlind]

It does mean that to some extent the CISC x86 provides an abstraction over underlying RISC shenanigans that Intel/AMD/Via can do on their own?

[@antonnym214]

I believe in a very small instruction set and then giving the programmer a nice library to make his job easier. I designed an instruction set of 16 general purpose instructions, and it appears to be really efficient. Nice video! all good wishes.

[@aonodensetsu]

the thing with libraries is that someone has to first write them and the more limited they are the harder that task is, it is easier to design a processor with more instructions that eases the strain on humans than to use humans to do the hard work of implementing funcionality on a small instruction set. The program sizes skyrockets the more limited you are by instruction sets (look up Movfuscator - a 1 instruction complier [not exactly the same thing as talked about here, but I think it demonstrates the problem with small instruction sets quite well])

[@NIKINUKI_]

Very informative and interesting video, thank you!

[@BruceHoult]

Sadly I found this going into confusing details irrelevant to beginners, and also with a lot of inaccuracies. For example saying it doesn't make sense to have a memory bus narrower or winder than the register size is not correct. In the early 80s both the 16 bit 8086 and the 32 bit 68000 came in versions with a 8 bit bus width. The 68008 was not popular but the 8088 was much more common than the 8086. In the mid to late 90s the ability of the 32 bit ARM7TDMI to run efficiently on a 16 bit bus (especially when running Thumb instruction set code) was probably what allowed ARM to take over mobile. Nowadays, memory bus widths are wider than the register width because entire cache lines are filled in parallel. Moving on, GPUs are SIMT not SIMD. In SIMT the code the programmer writes looks like normal scalar (SISD) code, but the CPU runs typically 32 threads in parallel, executing the same instructions in each thread but enabling and disabling threads depending on IF and LOOP conditions. Ok, I'm only at 3:30 .. watching on.

[@ChannelSho]

The funny thing is ARM also has certain complexities like x86. It has ISA extensions (e.g., NEON) and it has variable length instructions (ARM32 includes THUMB2). ARM is simpler to decode sure, but an ARMv8 compatible CPU isn't exactly simple either. While I imagine the RISC-V project aims to avoid these, I also can't see us returning to the old implementation of hard wiring the decoder again. There's also the thought that most x86 compilers use a handful of instructions, since not every program needs the entire featureset.

[@wChris_]

the x86 instruction set is backwards compatible to the i386 and with some magic (Real mode) to the 8086. ARM is not that limiting. that will also be the downfall of x86 CPUs which will never in their life need to run actually in 8086 mode.

[@marian3153]

Good work man, keep it up 👍

[@vyor8837]

Zen cores at desktop clocks only take like 10w of power on 14nm. They take like 2-3w of power at server clockspeeds(same as phone SOCs). Whoever told you that x86 couldn't be efficient has no idea what they're talking about. ARM has to decode instructions too.

[@RadoVod]

Tricky question: what does super-SIMD classify as?

[@FerventDissent]

great!

[@stefanogrillo6040]

'looses' loses

[@ProjectHana]

speak clearer would be better