Hi from SiFive :-) In CISC processors, branch prediction started with the 80486 and 68040, and heated up a bit in original Pentium and PowerPC, but really wasn't very good then -- maybe something like a 20% or 30% misprediction rate. Intel cracked the problem with the Pentium MMX and Pentium Pro (SUPER SECRET SAUCE back then) with essentially what we use today with 2% or 3% misprediction rate.

SH had branch registers, you could manually load your branch destination in advance before jumping to it. Giving you some of the advantages of a delay slot and much shorter encodings (less duplication) for conditional branches.

@Dr ROLFCOPTER! Knowing about branch delay slots is rather arcane knowledge, given that it only existed on some RISC architectures and definitely isn't how modern processors work. The majority of my ARM knowledge was for AArch64, not 90s era technology. Anyway, on second viewing, the concept does sound familiar, though I think what I am remembering is possibly the (closely related) concept of load delay slots. At Arm I was a verification engineer and I had to possess a detailed understanding of the architecture, including concepts like virtualization, multiple stages of address translation, exception handling, and about a thousand other things specified in a architectural reference manual that was over 7,000 pages not to mention the extensions. I had to understand how all these features interact and to design tests that worked across a variety of implementations in order to stress the microarchitectural features including branch prediction, speculative execution, caching, etc. I had to carry around a lot of knowledge in my head, so I guess a few details like load delay slots that haven't been used for decades slipped my mind. And the reason I'm speaking in the past tense about ARM Is because I decided to accept an offer at SiFive, and am now working on learning the ins and outs of yet another architecture.

@@paulk314 Nice one Paul, and extremely well done getting a job at SiFive - an incredibly innovative company that's, quite literally, "Leading the RISC-V revolution".

I programmed a TI DSP C30. It had delayed branches where up to instructions could be placed after a jump. This could get tricky if the jump was conditional. In some ways it was like the conditional execution part of the ARM machine codes. The C30 could use 3 registers in an instruction. For a CISC type of DSP I think it was pretty good for its time.

@Z3U5 Off-topic but I feel like I've seen you on Quora XD

Same

@Z3U5 that's sad, but common. It's because the students dream of leaving academia (thus the brightest aren't teaching). It may have been part of why I studied Mathematics, the students passion about the subject is reflected brighter in the instructors (at least when you get higher up, pro tip kids going to a community College first them to Uni you end up with very few Student Teachers.)

Microcode and nanocode have been used since the beginning, and that's not what was introduced with the Pentium Pro or Pentium M. What's changed in modern processors is the idea that nanocode can be reordered and cached independently of the main ISA, so the processor is effectively translating the main ISA into a new ISA before execution. It's way more advanced than what any RISC processor is doing, and the idea was probably inspired by (or stolen from) the now defunct Transmeta line of processors.

Vector instructions aren't necessarily CISC though. If it has to be divided into individual instructions (fetch, op, store etc.) it is not really CISC. SIMD is RISC compatible.

Most instruction extensions are primarily intended to expand the advertised feature sets which sell more processors ... they might technically be categorized as RISC (or RISC-based or RISC-compatible, whatever) ... but their use in non-synthetic applications is infrequent and specialized enough that most of the time they're little more than inert silicon and inflated transistor counts ... which basically undermines all the advantages offered by RISC philosophy.

@@nextlifeonearth yup.. vector operations make the CPU GPU-like, not CISC-like. And no-one going to call GPU's outdated, or inefficient, quite the opposite. Vecorisation of instructions is great.. for parralelisable operations. "Parralelisable" is just the same benefit multi core CPUs have, but this is even more efficient, it's just a x4 or x8 of floating point or integer units, to be better (faster/more efficient) at processing larger numbers. If anything it's somewhat more RISC-like than Intel's "just make one core faster no matter the power needed" approach.

but doing both everyone gonna for....intel cores are wider for full set while AMD is not wide to do any RISC instruction in one clock cycle...but it can do in 2 clock cycle per core ...thats gonna hurt amd future when times comes when AR and next gen windows came about 2021....that be end of AMD dominance on x86 again...due to INTEL PLAYED THIS RIGHT FROM BEGINNING ....BY MAKING SURE RISC INSTRUCTION IS WAY TO GO FORWARD WITH ARM COMPETING HUGE WITH INTEL WILL END UP WINNING THE WAR FROM BOTH SIDES....WHILE AMD BE THE VICTIM OF ITSELF FOR SELFISH SMALL MISTAKE...128BIT IS VERY IMPORTANT NOT THE MEMORY BUT PROGRAMS IS NEEDED FOR FUTURE NSTRUCTIONS IS NO LONGER DEPENDING ON GPU ANYMORE...THATS WHEN NVIDIA GONNA SEE THIS A HUGE THREAT

just like Gary

Why? Everything he said is still pretty relevant. The RISC vs CISC battle will continue for decades

@@jcdentonunatco Well, that is precisely what “aged like wine” means. = good became better. The other expression would be “aged like milk”.

@@Sunshrine2 lol sorry thought you were being sarcastic

@@jcdentonunatco No, no, I insert the needed /s if I do that on the internet :D

Yes, but with SIMD extensions, NEON, virtualization instructions, the new execution level, MMU, LSE, VFP, etc, etc, can ARM really be called RISC anymore? Of course still pisses me off they keep adding all that stuff, but still won't provide a simple flipping set of string operations. 12 clocks even with NEON to move 32 bits from one memory address to another, or 18 clocks just to send from memory to a port (when looping) is ridiculous, hence something like a 180mhz M4 being barely on par with a DX2/66 on actual delivered computing power unless you sit there clock counting at the ASM level. (don't expect GCC to produce anything worth a damn...) Just like how a 1ghz A7 is about on par with a 450mhz P2 in compute per clock. Wouldn't even be useful if it didn't run circles around CISC in computer per watt... though that is the real point of it. But what's the old joke? RISC is for people who write compilers, CISC is for people who write programs...

PowerPC was a major disappointment, and is what really sealed the fate of RISC on the desktop. It wasn't nearly as fast as promised, IBM and Motorola kept fighting each other with incompatible extensions, and I remember just how damn HOT they ran, too. ARM is okay for mobile stuff, but not really competitive on the desktop (and by that, I mean workstation). There's a reason why ARM has helped to take the "computer" out of computer. But, hey, ARM can do what they always do... make a new alternate ISA and continue to make their processors even more complicated and less RISC-y.

@@Waccoon the distinctions you’re using are 20+ years out of date. RISC v CISC is a meaningless phrase today. Read the Arstechnica article on this from 1999.

@@lookoutforchris It's not meaningless. The differences between RISC and CISC are almost entirely related to instruction encoding, not microarchitecture, so at the low level most RISC and CISC processors are designed and perform much the same way these days. However, the differences do matter, as the way compilers generate code for each design has to be fundamentally different if you want good performance and efficient use of the caches. I've read whitepapers and studied ISA encodings for more than 20 CPUs, so trust me, I'm not going to learn anything new from some watered-down article from 20 years ago.

People from the Macintosh/IBM compactible era should still know the differences...or atleast aware there is that difference.

Glad you enjoyed it!

ARM processors (which are RISC ISA) also use micro ops. micro-ops is not related to RISC vs CISC ISA but to superscalar architecture or not.

@@Arthur-qv8np IIRC, the only microcode that ARM processors have is related to THUMB instructions. And yeah, I was talking about micro codes :x

Interesting. Well, if RISC processors will start including microcodes to "simplify" instructions, wouldn't that make them the same as CISC ones? Anyways, I hope it doesn't happen. Compilers can do amazing stuff and the lesser the instruction set is, the easier it is for the compiler to optimize, or so I think how it should be.

@@thekakan From my point of view, RISC and CISC only define the philosophy of the instruction set. This does not define the characteristics of the architecture. Obviously, the instruction set and the architecture are closely related, but it's orthogonal. You can design both CISC or RISC processor with the same kind of architecture. For example with Out of Order, speculative execution, branch prediction, register renaming, simultaneous multithreading, vector instructions, micro ops, microcoded cpu, pipelined cpu, ..

CISC programmes have fewer instruction fetches but require extra logic to parse them as they have variable length. Plus, these variable length instructions are split into multiple instruction and there is no optimal way of doing it except brute force, this requires even more extra logic. This makes CISC machines spend time on doing something which is not calculation. This makes them more power hungry and less efficient. At this point, I really cant see any benefit to x86 except compatibility. I wonder how ARM processors became so fast in the last couple of years. Perhaps, its because the hardware limitations for which RISC was designed are no longer there.

If CISC will win out in the end then why are no new CPU designs CISC? Why is RISC taking over super computers, server and now entering the desktop market. It seems to me CISC is gradually painting itself into a corner. > CISC programs can be shorter because the instructions can more closely express the programmer's (or at least the compiler's) intentions. That's valuable information. The experience seems to be the opposite. One of the reasons RISC began to rise was that they discovered compiler writers where not very good at picking and utilizing these more complex instructions. Meanwhile juggling registers of which the RISC CPUs have many is something compilers have gotten a lot better at. Contrary to your representation of reality, CISC was to a larger degree made to facilitate people hand writing assembly code. RISC OTOH is designed with the assumption that code will be compiled. > RISC represents a premature optimization technique. I would say it is the opposite. CISC prematurely optimizes instructions in hardware. An area not easily or quickly changed. RISC programs in contrast can be optimized simply by getting better compilers that arrange the instructions in a more optimal fashion. > A shorter program also means fewer instruction fetches from memory, so less load on the memory bandwidth. RISC has tricks to get around this. E.g. ARM uses the Thumb format which makes most common 32 bit instructions take 16 bits. That means you double the number of instructions you can fit in memory. In addition the large number of registers in RISC processor allow them to reduce the number of load and store instructions further reducing required memory for instructions. > In other words, CISC programs have more dense and less distorted information content than RISC. Very odd way of putting it. RISC instructions are not distorted information. They tend to be simple instructions orthogonal instructions. CISC introduce the bloat by creating complex instructions requiring complex silicon to decode. For a compiler writer it is easier to compose things out of simple building blocks than trying to hunt down specialized instructions. I think the CISC approach really only benefits people doing compilation by hand, not for real compilers. If I was writing assembly code by hand I would likely prefer CISC. Having played with different assembly code, I would say Motorola 68 000 was hands down the easiest one for me to ever use. I kind of like AVR but being RISC is of course a bit cumbersome having to do so many things with multiple instructions. But there is a certain beauty in knowing every single instruction takes 1 cycle. I can easily count how long time a particular segment of code will take to execute. No such luck with CISC. For real time systems that is pretty nice.

The way you say "in fact" makes me wonder if you watched the video because I talk about this subject in the video.

Dear Gary, you are right, just before the end of the Video you told about the micro Ops of Intel CPUs and that was just after I sent the comment.

Actually... Intel was... sort of.. they purchased this technology from Digital Equipment which was used on the DEC Alpha chips. This was introduced into the 2nd generation of Pentium Processors which outperformed the P52C in so many ways. So there is the history... long before AMD there was DEC Alpha... which is now owned by Intel.

.. and they still have CISC instructions going into them. If they have a RISC-like inner core, surrounded with a (pointless?) CISC to RISC converter, then that just changed the definition of what a modern CISC architecture does with CISC instructions, redefining what CISC architectures.. are. ... But it's still a CISC architecture. And all that stuff surrounding the RISC-like core - that's why iPads are so damn capable and smooth at such low power.

@@gazlink1 CISC instructions are far more packed and lower power compared to RISC instructions... plus with CISC you get a much higher dispatch rate of instructions achieving higher parallelism and usage of independent functional units within a CPU.

Machines with 16 registers were the norm for CISC machines even before RISC was invented. Even machines that didn't have a 32-bit word size still usually had 16 general purpose registers of whatever word size they did have (though register 0 was often hardwired to hold a 0 value). The register-poor x86 architecture was the exception, not the rule.

@@dlwatib Being doing a bit of google research. Probably the most common 16 register processor was the 68000. Also the IBM 360, VAX and NS32016. I've only worked as a programmer on 68000 and x86 machines. Any other CISC processor types with 16 registers I've missed? I would argue 'the norm' for most people was an x86 machine or an 8 bit micro at the time of RISC's introduction. Having a little trouble finding processor production numbers to justify my assumption. Any graph of number of processors built would skew to 8 bit types because of the huge number of embedded processors. By the time of the Macintosh, Amiga and Atari ST had popularised the 68000 the PC was dominant. A list of CISC processor types might show many 16 register types, but in actual computers people used 9 out of 10 would be register poor x86, Z80 and 6502.

IA64-itanium might be more common than powerPC(now), i know many banks, financial institutions, and even EDU(where i work) used those even though the only thing they would support was a special version of server08 and then some specially kerneled verions of linux/bsd, it isnt directly related to CISC or RISC, and during develompent was thought to eventually displace both RISC and CISC for servers, workstations and desktops. The main feature for this ISA was that it could execute multiple instructions per cycle, per thread. From what i understand the intel-HP EPIC/IA64/Itanium/VLIW was sort of like hyperthreading, on top of hyperthreading, which is what started in the itanium 9500 series and later, where the processors came with hyperthreading so up to 4 instructions could be run on each core in a single cycle, and in theory you could have even more istructions per thread. Immagine this arcetecture being used on that demostration purposes intel processor that had, what was it 8 threads per core on a 4 core daughter board, i think they canned it around the time xeon phi started getting into the 50 core mark probably a year or two before the launch of the x100 series because more cores is always going to outperform more threads per core

@@denvera1g1 Yes. A cpu core needs to dump what ever is being done by the other threads when it executes a jmp. So unless your code is highly optimized it'll mean that 2 or how ever many threads need to be stopped and restarted (as I understand hyperthreading) every time a jmp needs to happen. This is why jump prediction etc has been so heavily worked on by intel and amd over the last few decades. I wonder how much the neural network thing amd use now really helps?

two of the top 3 super computers are POWER. And x86 only just makes it into the top 5 of super computers. I think x86's dominance in the server market doesn't translate to dominance in all markets. Especially if the requirements become very specialized, like a supercomputer or an mobile device. Ultimately it's not the architecture of x86 that drives this, it's the licensing and available software. Building an x86 server means you can optionally sell Windows license with it, have a broader market, and make more profit. It's hard for a company to make a modern x86 without stepping on patents and there is no way to license it from Intel (or AMD). ARM can be licensed by anyone and adapted to the special needs of a product. And IBM works very closely with vendors to adapt their POWER chips to meet the specialized requirements of supercomputers.

Are you responding to 7:07 ? His point was that it was silly to even base "CISC won the war vs RISC" on the server market. So, you are defending this in spite of it just being an indicator of an ignorent viewpoint? Are you trying to confirm this: "I really was making a really dumb argument but I was right about that particular point?" Is that what you're trying to say?

@@denvera1g1 also many years ago PowerPC dominated the automobile computer market. And that's several chips per auto. I learned this at the time Apple was leaving PowerPC for Intel, and they may still be dominant in autos. If your argument (whatever is being argued!) doesn't include cars, trucks, airplanes, large appliances, etc. you're not making a good argument about the CPU "multiprocessor" market.

You're welcome! 👍

Interesting take but based on my reading this also seems a bit pedantic. E.g. Thumb follows a very RISC like philosophy in reducing cache usage. Rather than adding complex instructions to reduce memory usage, they came up with Thumb, which is just a compressed version of a subset of their 32 bit instruction set. It is not a new instruction set as such. As far as I understand RISC is based on the 80/20 kind of rule, that 20% of the instructions are used 80% of the time. Hence they try to keep these 20% instructions equal in length and execution time to make the pipelines work effectively. Maybe I am wrong about this, but I would bet that the specialized longer clock cycle ARM instructions are used in special contexts, where one might use a lot of them. As far as I understand, you want to keep feeding as many equal sized instructions in a row as possible. They may pull that off still even with variable length instructions if these instructions are not usually mingled a lot with other instructions. Obviously there must be something very RISC like about a lot of the ARM instruction sets when their ARM Cortex-M0 can be implemented in a mere 12 000 transistors which is HALF of that of a Intel 8086, despite being a 32 bit processor with way higher clock frequency.

@@erikengheim1106 The quote I pasted was talking about how ARM really isn't RISC anymore. It once was, but it has bloated a lot in the past decade.

@@DemiImp Let me rephrase my point since I don't think it got across. If you add a bunch of functional programming constructs to an object-oriented programming language, does that language then become functional? Or if you add a bunch of object-oriented features to a functional programming language, does it become object-oriented? There are many way of answering such a question. You have the pedantic who operate on one-drop rules. E.g. if there is only a hint of object-oriented features, the whole thing must be categorized as object oriented. Then there are the pedantic that go say, now both languages are multi-paradigm. The OOP and functional divide no longer makes sense! Yet at this point the pedantic has lot track of why humans engage in taxonomy in the first place. If you end up categorizing every single programming language as say multi-paradigm, then your categorizing criteria are worthless. Your taxonomy adds no value to people looking at a landscape of different technologies and try to reason about them. Hence I believe taxonomies should be pragmatic. They should be based on heuristics rather than hard rules. Just because you add a bunch of non-RISC like instructions doesn't mean that the core of the instruction set wasn't design around the RISC philosophy. It is kind of like adding OO features to a functional language. It does not change the fact that the core has been centered around functional thinking.

@@erikengheim1106 I would disagree. C++ is C but with more OO design. Are you suggesting that C++ is not actually an OO language? The defining characteristic of a RISC architecture is that it has close to the minimum set of instructions to be Turing complete. The moment you start adding in more instructions, the less RISC it becomes and the more CISC it is. Modern ARM ISAs are not very RISC-y.

DemiImp Definitions should be useful. Defining RISC as being about as few instructions as possible isn’t a useful definition. PowerPC G3 had more instructions than pentium pro e.g. Yet it was a very RISC like architecture because it used instructions of equal size, requiring same number of clock cycles etc. All to make pipelining easier. It was designed around reducing load and store instructions by using many registers. This is a very RISC like philosophy.

At the moment the majority of Arm based processors are designed for smartphones. This is just the beginning of a shift towards laptops, desktops and servers. You can't compare the performance of a smartphone processor running from a battery with passive cooling to a desktop processor running from mains power with a huge fan on it. Probably the best example we have at the moment is Amazon's Graviton 2 processor. It has show better perf/watt than many Intel chips.

I'm pretty sure most of 17,000,000 transistors are used for cache of various levels. But instruction decode tax exists nonetheless, just not as huge as one could think :)

@@allmycircuits8850 no,. 17 million is just the core. Including cache etc the Silverthorne CPUs had 47 million and Lincroft 140 million after GPU and DDR controller were moved on-die.

ARM also suffers from these processor security issues. It's just that only their very high end processors are affected, because only those processors match a typical x86 processor in complexity and performance. So in a sense, it's the complexity and performance optimizations that led to the security issues, not ARM vs x86 (or RISC vs CISC).

"This is probably part of the reason that Intel (and AMD to some extent) suffers from so many security leaks in regard to their branch prediction and speculative execution - its a much more complex job to implement than with RISC architectures. " Not really, seculative & out of order execution and branch preduction are performed on the microops (who are in the Out of Order world). CISC instruction are issued In Order. And ARM is also affected by vulnerabilities that exploit speculative and out of order execution.

The vulnerability that this thread is referring to is the lack of housekeeping on abandoned register and cache data; An error in thinking that hidden or obscure is the same as secure. The patches applied to this problem are at the software level. The insecurity has been built into the hardware for years...

@@Arthur-qv8np I think you may have written that without reading the comment above. They're probably vulnerable at the level of smartphones and some Chromebooks, but not much else. Really, it seems like any of this wouldn't be an issue today except Intel has so much IP built on old decisions about CISC vs RISC "approaches". And ARM vice versa.

@@squirlmy I wrote this comment a while ago, and I haven't developed it much. These vulnerabilities (like spectrum/Meltdown) are really not a problem of CISC vs RISC, it's a problem in the concept of superscalar processors (processors that read a scalar instruction flow but manage to execute these instructions in parallel by exploiting Instruction level parallelism (ILP)). The problem is that this sort of processor, which uses OoO & speculative execution, make the isolation between threads more complex than we thought. All superscalar processors have been affected to some degree, depending on their microarchitecture design. The parts of the micro-architecture that are responsible for the issues are not in the instruction decoder or even in the execution units of the processor, but rather in the memory system (in a very large meaning) and how the transient instructions will affect this memory system. So it's really not because of the CISC. The CISC only makes the instruction decoder more complex, not the rest of the micro-architecture. The more optimization the processor contains in this memory system, the more it is exposed to potential vulnerabilities. Intel processors contained a lot of this optimization (especially bypasses to access data faster). We can blame Intel's security section for not figuring out these problems, but we can't really blame the designers who created these optimizations for not having thought of security flaws that didn't exist in the first place (the meltdown flaw actually exploits a behavior described in an Intel patent). Superscalar processors from ARM, IBM or AMD are much less advanced in this type of optimization and have therefore been less affected. The processors have been affected at their "optimization" level. (can we still talk about optimization when we talk about a behavior that adds a flaw?) For these reasons Intel's CISC ISA is not involved, a RISC ISA would have caused the same problem to Intel. It is important to understand that ISA is only a very small part of a processor, its memory system is much larger and causes much more problems (processors have a computing power limited by the memory system - memory is the bottleneck).

That is in my opinion the real reason that RISC was so successful, it was in some way implementing a cache with very few logic elements! And implementing a cache algorithm in hardware is difficult, here the cache is actually implemented by the compiler and it can be optimized in a better way and might analyze how the program will most likely run. Today with billions of transistors and a cache in three layers that might be not so important, but still, giving the compiler a lot of control is a good idea.

"does not actually have more compact code than modern RISC such as ARM Thumb or RISC-V" you mean "RISC-V C extension", right?

@@Arthur-qv8np Yes. It's pretty much only student projects or tiny FPGA cores that don't implement the C extension. Once you get to even a couple of KB of code you get an overall savings in implementing C.

Bruce what is the average length of executed x86 instructions though? I have been trying to understand how much thumb matters. But it is hard to assess without knowing the length of the typical x86-64 instruction. And also how much does a 15 byte long instruction matter if it does the job of 30 RISC instructions? I am a RISC fan, but I want to make sure I understand the tradeoffs properly.

@@erikengheim1106 this talk (and referenced paper) discusses this ukposts.info/have/v-deo/gZmQpHuPgoGKtps.html

@@BruceHoult Thanks, interesting video. From what I could gather x86 would have 3.7 bytes per instruction on average. Their RISC-V compressed instruction set got down to 3 bytes per instruction on average.

People forget though that ARM don't manufacture the processors. They design the specifications for other companies to make and implement as they see fit. Intel have in the past produced ARM CPUs, all HP PocketPC from around 2003 for example shipped with an ARM5te which was an Intel chip (The Intel XScale) using the ARM Licensed Specifications.

soon as apple get their laptops / desktops on ARM processors and windows 10 support for ARM improves... x64 will be a dying breed.

Since you mentioned it I went looking and foudn this: www.tomshardware.com/reviews/atom-z2760-power-consumption-arm,3387.html from 2012, I would take such a report with about 3 metric tons of salt.

Yes I agree, a smartphone has a processor with not only a RISC CPU, but there is the FPU, SIMD, Cryptography extensions, a DSP, an NPU plus the GPU. But there is also seperate video processor (decoder) and a separate display processor!

The Samsung A Quantum isn't a smartphone with a quantum computer, it just has a built-in hardware based random number generator: www.androidauthority.com/samsung-galaxy-a-quantum-1118992/

Yes, I plan to cover RISC-V soon.

In a conventional CPU: Transistors are fixed and their interconnections are also fixed in a classic CPU. In contrast, in an FPGA: you can configure the connection between logical blocks, called Look Up Table (LUT). But once configured, it's set for the run.

@@Arthur-qv8np thx for your answer. What does fixed in their interconnection mean? That they are printed together as logic gates?

@@centuriomacro9787 Exactly :p

MARK!!!

MARK!

Gary!!! Mark!!! Zaman!!!

@@ZamanSiddiqui *ZAMAN SIDIQUI!*

@@KaushalNiraula *KAUSHAL NIRAULA!*

Microcode and nanocode have been around forever. Modern CISC can re-order the nanocode before caching and execution, while RISC tends to still be hard-coded. Ultimately, RISC vs CISC is a checklist of design features, and there's no hard line of separation between the two. Hence, why there's so much confusion. Both styles of chips have huge amounts of redundancy and parallelism. The only "real" difference between CISC and RISC these days is that CISC can combine memory access with a computation (orthogonal instructions), while RISC strictly separates the two (load/store instructions).

"running several processes per instruction has a distinct" I think you're discussing about superscalar architecture, not CISC ISA. Some ARM processor are superscalar too. (with a RISC ISA)

Moore's Law was always a result of industry advances, not a cause. The current emphasis on core count and parallel processing is a reflection of the difficulty in fabricating smaller features in silicon ie yield vs scrap.

@@avid0g thanks David.

VLIW (for Very Long Instruction Word) just graps together a fixed number of "small" instructions into a "big" one (a "very long" one) also called a bundle. When you execute that "big" instruction: you execute in parallel all the "small" instructions, each of them is assigned to a different compute unit. The unit assignment must be done at compile time this process is called "static scheduling". That's the opposite of "dynamic scheduling" where the units are assigned at runtime within the CPU, which is what we call a superscalar processor (like x86 CPUs, ARM, RISC-V, ..). "static scheduling" reduces CPU complexity by giving the compiler the workload of scheduling. But building an efficient compiler for static scheduling is really challenging for general purpose processor (like the one you use to navigate on youtube). This is why most general purpose processors are superscalar and not VLIW. But the VLIW architecture is still used in DSPs (Digital Signal Processor) for example.

Yep, pretty much no such thing as a pure RISC or pure CISC architecture. When did they redefine what a minicomputer is? I am aware of a lot of idiots that call things which are smaller than microcomputers minicomputers, but in the field 1) minicomputer was a term only used by part of the field even in the days of say the PDP-11 and 2) has essentially been abandoned.

@@AlexEvans1 well now minicomputers is meant more between mainframe and micro, but in the past, a mini-computer was a computer with minimal features. The closest thing to the old definition of mini-computer is probably MISC, however it's not a perfect replacement because apparently MISC ISA can't have microcode. DEC's PDP-8, a mini-computer with like 8 instructions isn't MISC because it has microcode.

@@23wjam That seems a difference that isn't a difference since you are talking about a time when there simply weren't microcomputers. A definition that *may* have existed before 1970. Most of DECs PDP series (particularly not the PDP-10) were considered minicomputers when they came out. I know of RISC and CISC implementations that didn't use microcode.

@@AlexEvans1 the difference is that they aren't minimal anymore, previously a fundamental facet for the former criteria. I guess the issue is, and obviously how and why it changed, is probably due to it being more of a marketing term. (maybe? I'm not sure because it was before my time) As regards the no microcode, there are obviously other criteria involved, but in my example the PDP-8 is disqualified from the MISC classification due to microcode, which is idiotic as its definitely MISC in spirit.

@@23wjam that and MISC is a term that wasn't in use at the time. Just like CISC architectures weren't referred to that way until the introduction of the term RISC. MISC has generally referred to certain academic architectures like the one instruction architectures (for example subtract and branch if not zero). In any case RISC and CISC are really abstract notions that few computers fit perfectly.

I cover Von Neuman here: ukposts.info/have/v-deo/qp-WjqlknIJezas.html

You've come away light years in presentation style since that video!!!! Great job and love your work sir!!! Thank you for all the insights and the SoC fights of course :)

@@chigga76 Thx :-)

I am not clear on exactly what you are asking? The problem of fetching instructions from memory and the use of caches is the same for RISC and CISC, but there is a disadvantage to system that use variable length instructions.

@@GaryExplains I meant multiple instructions for risc instead of using one...

So the idea is this. On RISC the instructions are guaranteed to be of a certain size, which means the fetch and decode phase is simpler compared to variable instruction lengths which means tat the first part has to be fetch and partially decoded to see if more needs to be fetched. As for execution time (in cycles) vs time to fetch next instruction, these mechanisms are basically decoupled nowadays on both CISC and RISC due to caching, wide pipelines, and instruction level parallelism, etc.

@@GaryExplains instead of running code line by line we should use multiple fpga and cpu's to decode instructions and run basic OS Files, we got maturity in hardware and software, we have to implement common OS system files inside the chip...problem is it heats up

I don't really know what you mean by "instead of running code line by line" or what you mean by using multiple cpus to decode instructions. Of course, heat (which equals energy spent) is the THE problem.

ARM is designed by......ARM. Apple only customizes it like Qualcomm, Huwawei, and Samsung. Qualcomm and Huawei have closed the gap since they build also on 7nm like Apple already did.

@@hermanstokbrood lol Huawei did not customize their are cpu...

@@wanmaziah9835 ROFL Yes they are. ARM delivers the building blocks. They all do their own stuff with it.

@@hermanstokbrood what did you means by ROFL ?

@@hermanstokbrood what is different between semi custom and full custom.... as we can see in Qualcomm chip in sd 835 rather than sd 820 / 821 because Qualcomm modified full custom core..... in sd 820 and 821.. and I think Monggose also did full custom core not semi like Samsung do... Is that true.. ??🤔🤔

early versions of SPARC also did this. They multiplied using the mulscc instruction. For a 32 x n multiply, you would execute the instruction n times.