|
|
|
|
Hi all,
What are the advantages/disadvantages between RISC and CISC?
Also, which one of the two is our HACK architecture?
Thank you!
|
|
Administrator
|
That question is best answered by spending some time perusing the Internet. There is a TON of information about this out there for the asking.
The short answer is that RISC means an instruction set that has a relatively small handful of simple instructions that, as a result, can be run at much higher speed. CISC is the opposite in that you have a relatively large number of complex instructions that, individually, get a lot done. But, as a result, you can't run the processor as fast.
With RISC the same program usually requires a lot more instructions to accomplish the same thing, but you can execute most instructions per second. There's no fundamental reason why a program running on a RISC machine will finished sooner or later than the same program running on a CISC machine. Some will run faster, some will run slower.
With the current technologies, RISC has the preponderance of advantages, but that wasn't always the case and it may not be the case twenty years from now.
With that level of understanding, do think the Hack is RISC or CISC?
|
|
|
So are you saying that if a CPU/ISA is RISC or CISC is in the eye of the beholder?
|
|
Administrator
|
To some degree. As with many things, there's a spectrum involved. Some architectures are so RISC that no one could defend calling them CISC and vice versa. But there's a big band in between where some would call it RISC, some would call it CISC, and some would call it a hybrid. Each group could probably make a strong case for their categorization by focusing on different things.
|
|
|
Then I would say CISC more than RISC, since C commands can load, compute, store and branch at the same time, and in multiple destinations. Compared to the little I know about other ISAs, this is a lot. I am used to having a command either load, compute or store, or branch...
|
|
Administrator
|
I suspect most people would argue that Hack is pretty RISC-like. True, it has some seldom seen features, such as writing to multiple destinations and combining ALU operations and branching (and writing) in each C-type instruction, but each of these is very, very basic. The kinds of things that would move it toward the CISC side would be if there were instructions that did looping or that dereferenced arrays directly or that cleared segments of memory or copied segments of memory to another area of memory or had instructions specific to various data types and/or structures.
|
|
|
In their book, Computer Architecture: A Quantitative Approach, Appendix C.1 Introduction, authors John L. Hennessy and David A. Patterson characterize the key properties of a RISC architecture as follows:
1. All operations on data apply to data in registers and typically change the
entire register (32 or 64 bits per register).
2. The only operations that affect memory are load and store operations that
move data from memory to a register or to memory from a register, respectively.
Load and store operations that load or store less than a full register
(e.g., a byte, 16 bits, or 32 bits) are often available.
3. The instruction formats are few in number, with all instructions typically
being one size. (Highlighting is mine.)
Hennessy and Patterson played a substantial role in the development of the RISC architecture, so their pronouncements on the subject should be taken as authoritative. This small set of restrictions allow for substantial hardware optimization techniques, such as instruction execution pipelining, that can improve the overall instruction execution rates (instructions per second) versus CISC architectures. Because of this the execution of a program expressed in a RISC instruction set can often outperform the same program written in a CISC instruction set.
Notice that this says nothing about the number of instructions contained in the instructions set. The adjective "reduced" refers to the fact that the instructions should all be the same size: say 4 byes. CISC ISA typically have instruction sets of varying length. While the number of instructions in many RISC ISAs is small, there are some (PowerPC, for example) that have a large number of instructions.
Based on these criteria, the Hack ISA fails to qualify as pure RISC, since requirements 1 and 2 are clearly violated. The third requirement is satisfied (in the extreme), however.
I would agree with your assessment that the Hack ISA is more CISC than RISC, but for different reasons. I also agree with WBahn that there is a "spectrum" of ISA architectures in which RISC and CISC (whatever that is), are somewhat widely separated. The Hack ISA is somewhere between RISC and CISC.
Presently, RISC seems to be winning the "holy war" of best architecture, in terms of devices implemented in actual computing systems. I think virtually every cell phone these days uses a RISC processor. Also, most embedded CPUs in commodity products tend to be RISC.
|
|
|
Thanks. I am happy to see I wasn't so far off as I thought.
I am a bit confused though, because you say you agree with me but not for the same reasons. If I understood your reasons correctly, they are the clear violations of requirements 1 and 2, and they (the requirements) seem to formalize my previous message. Am I missing something?
I wrote:
yhirshhorn wrote
Then I would say CISC more than RISC, since C commands can load, compute, store and branch at the same time, and in multiple destinations. Compared to the little I know about other ISAs, this is a lot. I am used to having a command either load, compute or store, or branch...
Is this essentially different from requirements 1 and 2?
|
|
Administrator
|
While I agree that Patterson and Hennessy are authorative voices in this area, I think that the context of their criteria need to be considered as well. They were trying to distinguish between real-world approaches to practical implementations of real-world architectures. So I don't know to what degree their criteria can be blindly applied to something like the Hack which is far from real-world or practical -- or arguably even complete as far as having something that you could drop into a physical design as is.
I think part of the context for their first two criteria was to contrast it with the CISC norm where you had a variety of instructions that all did the same basic operation but where one of them operated between two registers, while another operated between a register and memory, and so on and so forth. So I don't know that the underlying concept is really that RISC instructions must operate only on registers as it is that the architecture should strive for a single instruction for each operation.
Because of real-world practical considerations, the division of the world between registers and memory makes a lot of sense and having operations work only on one side of that divide and load/store instructions be the sole instructions that bridge the divide between registers and memory also makes a lot of sense in terms of simplifying architecture design. But I don't know how applicable that division is for the Hack since the architecture is able to ignore those real world practicalities and largely treat memory as nothing more than a big register space.
It would be very interesting to know what Patterson and/or Hennessy would have to say about where the Hack should sit on the RISC/CISC spectrum -- and their reasoning and to what degree they agreed with each other, for that matter. I suspect they would have a few observations that would be anything but obvious to the rest of us.
|
|
|
When you referred to "C commands", I assumed you were referring to statements written in the C programming language. The implementation of the C language on a particular computing system has nothing necessarily to do with whether that system's CPU is RISC or CISC. Computers having CPUs using both RISC and CISC ISAs have successfully hosted C compilers. I have a C compiler available on my Dell laptop that has an Intel i7 CISC CPU, and I also have a C compiler on my Raspberry Pi Model 4 which has a Broadcom BCM2711 system on a chip with an ARM Cortex-A72 RISC processor.
So, to answer your question: Yes, this is essentially different from requirements 1 and 2.
Not every CPU ISA satisfies requirements 1 & 2 (for example, the ARM does, the i7 does not), but CPUs of both the RISC and CISC paradigm are capable of running C compilers which "can load, compute, store and branch..."; that is, both RISC and CISC-based computers have instructions "load, compute, store and branch". The way the instructions work to do these things in hardware is, of course, quite different for RISC versus CISC devices.
|
|
|
I see. I was referring to the HACK ISA's c-command, meaning commands with an op-code of 1xx instead of 0xx. For example:
ADM=D-M;JLT
Is a legal command (even if it is not encouraged to store and branch at the same time).
But even a more common command:
M=M+D
Does loading (from memory), computing and storing (in memory) at the same time, which is - if I read correctly, a violation of both first requirements.
|
|
|
Ahh, C-instructions, I see. Sorry I missed that. I apologize.
So, you are kind of right about the way memory is used in RISC versus CISC ISAs. All ISAs, both RISC and CISC, have instructions that load and store data into the CPUs internal registers. All ISAs have instructions that cause the ALU to perform computations to produce a result. All ISAs have instructions to perform some kind of branching operations. A key difference between RISC and CISC has to do with "in multiple destinations".
Requirement 1, I believe, indicates that the operands required for any computation performed by the ALU be located in CPU registers. Furthermore, the result of a computation always appears in a register. By register, I mean a storage unit built into the CPU and not a storage unit in main memory (RAM). In the Hack architecture, the D-register is such a register memory unit.
Requirement 2 says that the only way to read or alter main memory is by specific "load" and "store" instructions that only move program data between a register and a RAM location.
Taken together then, these two requirements mean a single RISC ISA instruction may not use a main memory location directly as an ALU operand or directly as the target storage location of a computation result. The Hack computer allows these kinds of operations, so it's not RISC. You may use a RAM location directly as the source of a ALU operand and save the result of a ALU computation directly in RAM. These are the violations to which I was referring. It really has nothing to do, at least directly. with performing both of these operations "at the same time", although the "in multiple destinations" seems absolutely correct.
The Hack computer seems to have the interesting capability of being able to perform a computation and store the result in RAM in a single clock cycle ("at the same time"?). I'm skeptical that any real computer can actually do this.
As I mentioned before, one of the drivers for the RISC architecture was to support the implementation of instruction execution pipelining to improve instruction execution rate in real-world CPUs. There may be other ways to do this, but the RISC idea seems quite effective in achieving this end.
Since all Hack computer instructions execute completely in a single clock cycle (unlike real-world computers), the need for instruction pipelining unnecessary. Designing the Hack computer as a RISC machine would seem to hinder its overall speed to execute a program. I think WBahn had alluded to this in an earlier post of this thread. I also very much like his idea of thinking of RAM as one big register file. Again, because all instructions execute in a single clock cycle, this makes excellent sense. I think it also clearly illustrates his idea of a CISC-RISC "spectrum".
I never know at what technical level to frame responses to a specific question here because I don't know the level of the person posing the question. If the level of this response is below where you are, I apologize also for this. I always try to include detail to the best of my ability because I think others reading the thread, who are perhaps at a lower level, may benefit. Certainly, there are people posting on this site whose level is way above mine, and I am grateful when they correct my misunderstanding of an issue.
|
|
|
I understand, and no offence taken. I have a B.Sc. in computer science, and the course in coputer architecture is basically all I have in this area.
Anyways I think I used a bad phrasing when I said "at the same time". I meant "in the same instruction". That was what I was teying to illustrate with the commands I posted.
|
|
Locked
