We have finally come to the end of this series of articles focusing on the evergreen and never tame
CISCs debate. I list the previous articles below, so as to make them easier to retrieve:
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),
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
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
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.
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
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,
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…