That is why Riscv is retarded. It is not even a real ISA. It is a bunch of disjunct ISAs which are not compatible with each other at all. What's the point of this shit when you can just make your own ISA to satisfy your demand? ukposts.info/have/v-deo/hYKkZ2x_ZGuBo4U.html

riscv is just objectively worse than loongarch

Off air I did try really hard to find that instruction, but was unable to. I also played with different architectures, but got a little lost in the options. Thanks for the info!

@@Fill_In_The_Blank_Programmer The problem is that libraries include glibc and libstdc++ are not compiled with mb_zbb thing that means it runs extremely slow for majority of tasks. It is just like -march=native for x86_64 which rarely people would use it.

@@Fill_In_The_Blank_Programmer BTW. It is just a proposal for bit extensions for RISCV. It is not mandatory.

I don't think so. I feel like it was more of a "computer architecture" title

@@Fill_In_The_Blank_Programmer David Patterson

@@Fill_In_The_Blank_Programmer David Patterson

Yup, I figure that out a few minutes into the episode :D

First, modern Superscalar Out-of-Order processors do not check if instructions can strictly be executed in parallel, they check if instructions can be reordered, which is a higher property (If they can be reordered, then they can be run in parallel). _Note: Superscalar In-order processors, which have lower performance, actually strictly check if the instructions can be executed in parallel. But compilers here must target Out-of-Order processors, and my conclusion here is identical for in-order processors._ To determine if instructions can be reordered, we must identify the dependencies between these instructions. For basic arithmetic instructions like ADD/SHIFT there are only register dependencies. There are 4 types of register dependencies: WAW: Write After Write, a register is written after another instruction has written this register; WAR: Write After Read, a register is written after another instruction has read this register; RAW: Write After Read, a register is read after another instruction has written this register; RAR: Read After Read, a register is read after another instruction has read this register. Among these dependencies there are false-dependencies. First, it's obvious that the RAR dependency is a false-dependency. Instructions that read the same register can be reordered (and executed in parallel). But, less obvious, WAR and WAW dependencies are also false-dependencies: they could have been avoided by using another register for the last register write (the destination register). They are naming-dependencies. To get rid of these dependencies we can rename the destination register and reorder the instructions. That's the register-renaming job in modern processors. Example: (1) addiw a1, a1, 42 (2) addiw a1, a2, 33 instruction (2) write register 'a1' after instruction (1) both read (WAR dependency) and write (WAW dependency) this register. This prevents to reorder instruction (2) before instruction (1) so you must be careful. By renaming the destination registers the problem disappears and it is semantically equivalent (as long as you know that p2 corresponds to the new a1 register): (1) addiw p1, a1, 42 (2) addiw p2, a2, 33 When renamed, it's safe to reorder them. The last dependency is the RAW dependency, this dependency is the only true register dependency that prevent reordering and parallel execution. You can't reorder two instructions if the second instruction depends on the result of the first one. @18:52 both GCC and CLANG output instructions that have RAW dependencies. Because the destination register of each instruction is always read in the following instruction. It is therefore impossible to reorder them. But we can rewrite the code to expose parallelism: (1) slliw a0, a0, 3 (2) addiw a1, a1, 44 (3) addu a0, a0, a1 Here instructions (1) and (2) are independent, but instruction (3) depends on (1) and (2). However, there is a subtlety here that prevents the compiler from doing this re-write/re-ordering.

@@Arthur-qv8np - That was very educational. Thank you!

@@Arthur-qv8npThey are talking about macro-op fusion, not parallel execution.

​@@NoX-512 Not sure who you are referring to with "they". The message I'm responding to mention: "doing the add and shift at the same time in different ALU units" That's parallel execution. And macro-op fusion has nothing to do with execution things in parallel on different units. In fact it's quite the opposite, fused operations usually remain so, except for load/store operation but they do not split with respect to the original macro-ops. Macro-op fusion is kind of more about doing several operations on the same unit (e.g. div/rem)

​@@NoX-512 Oh I think you are talking about the code example in the video at the timecode. Yes macro-op fusion could be relevant here. But I doubt this is a macro-op fusion pattern that exists in the current riscv processors

You can check that int corresponds to 4 bytes (aka 32 bits) in this situation. Just open the compiler explorer and write: int sizeof_int() { return sizeof(int); } All functions will return 4, so int is 4 byte here.

Try "ARM64 is much better ISA. x86 is old garbage. Deep dive ISA comparison and future outlook."

"Still don't understand why ARM is efficient." Because procesor are build like for mobile, not desktop. Efficient not depends on ISA.

@@miroslavbrabec94 "ARM64 is much better ISA. x86 is old garbage." Generally yes, but it isn't matter. E.g. x86 CPU are faster and more efficient than RISC processor like IBM POWER. POWER ISA is more modern than ARM.

I can only read the abstract. How can I read the entire document?

It seems like the Chinese would be very eager to adopt something like the Risc-V ISA for their CPU designs going forward; and subsequently, abandon Intel and ARM to: 1) start from a clean slate, 2) avoid paying the exorbitant prices that Intel and ARM demand. In conjunction with this, they have no need to observe Western intellectual property rights laws with respect to any "magnificent eight" set of features that may or may not be incorporated into an actual silicon implementation of Risc-V.

@@markteague8889 They already did just that.