The final RISCs vs. CISCs – 6: Conclusions

We have finally come to the end of this series of articles focusing on the evergreen and never tame RISCs and CISCs debate. I list the previous articles below, so as to make them easier to retrieve:

The final RISCs vs. CISCs – 1: Abstraction levels vs. benchmarks

The final RISCs vs. CISCs – 2: Definitions

The final RISCs vs. CISCs – 3: The (anti-CISC) propaganda

The final RISCs vs. CISCs – 4: How RISCs became CISCs

The final RISCs vs. CISCs – 5: How CISCs… remained CISCs!

I don’t think there should be any more doubt as to what a RISC is and, consequently, what a CISC is. Nor, above all, the fact that there have basically been no RISC processors for quite some time now and that those that are passed off as such are, in reality (definitions in hand), CISCs.

The (new) L/S (or LS) macro-family: Load/Store

At this point, and in my opinion, it no longer makes any sense to continue talking about RISCs, when the processors that bear this title have seen almost all the pillars on which they were based fall. Except one: the constraint of accessing memory exclusively via so-called load/store instructions.

To be clearer, one should not change the meaning of RISC processor, as this term is well defined (and valid) and all four pillars on which it is based are still echoed and even touted today.

Instead, one should simply use a new term instead of RISC: L/S or LS, to identify the macrofamily of processors that have in common the use of the aforementioned load/store as the only instructions which can access memory. Obviously RISCs (the old ones falling under this definition. The new ones are CISCs, as already proved) would, by definition, be a (narrow) subset.

History must not be rewritten

To (silently) redefine the meaning of RISC to suit the (changed) needs of a few lecturers would, on the other hand, only demonstrate a wilful lack of intellectual honesty.

This is because history is important and facts should be verified instead of blindly drawing on the fruits of propaganda, however well packaged and sold as a delicious delicacy. Above all, one should not fall into its trap: the project to rewrite it in order to pander to new agendas and do away with previous stances.

George Orwell recalls this again very well when, in his other very famous novel, 1984, he describes the maniacal operation of systematically rewriting history according to the decisions and new directions taken by the ruling Intelligencija. But, above all, we can certainly see how the ‘doublethink‘ is absolutely central to the propaganda of the proponents of RISCs: ‘the lie passed into history and became truth and ‘Who controls the past controls the future. Who controls the present controls the past‘.

Orwell, in short, was again prophetic in his writings, and anyone who has read them and is also familiar with the history of processors and their architectures should have no difficulty in seeing that what they describe applies faithfully to the RISC and CISC macro-families.

In the beginning…

Finally, I want to express my opinion on a few topics related to this atavistic diatribe.

Another thing that I personally find ridiculous is the claim to judge old processors with current lenses, completely ignoring the historical context and requirements of the time.

Let us take again the vituperated 8086: the use of the infamous prefixes made it possible to control/manipulate the instructions executed in a very simple, efficient and economical way. The processor design was not complicated, used few transistors and achieved excellent code density. What else was needed at the time (1978)?

Nobody could imagine that this would create problems in the future, as we would learn about it much, much later. However, talking about this now and pointing the finger at the processor for those decisions… I must say that it leaves a lot to be desired, to say the least.

In my opinion, using prefixes to extend the 32-bit architecture was still an acceptable idea even when the 80386 was marketed, taking into account the inherited ISA, the goals and technology of the time. One cannot, as already mentioned, ignore history and the specific context in which certain products arrived.

Therefore, to point the finger at the architectures of the past on the basis of experiences as well as technological advances after the time in which certain decisions were made I find demented to say the least, if not insulting to intelligence.

…and hindsight

Quite the opposite can be said, however, of its 64-bit extension, x86-64: the time (it arrived in 2003) was ripe enough to realise that this legacy was now having too much of an impact on architecture implementations. So a better idea would have been to propose a redesigned ISA, at least in the new 64-bit mode.

Which is exactly what ARM did some time ago for its AArch64 AKA ARMv8: a brand new architecture that was designed by eliminating the bottlenecks and burdens of the 32-bit one, while also extending the ISA.

It was a fine piece of rewriting and rethinking that certainly could have been done for x86-64 as well, instead of applying another horrible patch on x86 and further complicating the ISA, as already extensively discussed on these pages (in particular in the concluding article on Intel’s new architecture, APX).

In any case, certain choices have now been made and going back is not possible (too much software has accumulated). What remains is the disappointment arising from the knowledge of what could have been done and what, unfortunately, was not done (which I will probably talk about in another series, later).

A better future

For certainly better would have been possible, if other decisions had been taken. In fact, designing CISC processors, even modern ones, does not necessarily imply that they have to be bad / ‘ugly’ by definition as well as harbingers of problems: it depends entirely on how they are designed!

Obviously, the best could be achieved by having a ‘blank sheet of paper’ at one’s disposal, where one could freely draw one’s own ideas, without constraints and legacies to carry around: this could lead to very interesting solutions to common problems.

This concludes the series, which I hope has helped, if not to clarify the controversy (I understand that it is difficult to remove preconceptions that are now welded in the mind), at least to instil doubt about what has now been brazenly propagated for more than 40 years…

Press ESC to close