0
$\begingroup$

I have two opposing ideas. I think that all the instructions in a RISC take the same time what makes me believe RISC is associated with synchronous.

At the same time i think that CISC should be synchronous and RISC should be asynchronous.

Can you tell me if RISC is associated with asynchronous and CISC is associated with synchronous? Why?

$\endgroup$
3
  • 1
    $\begingroup$ Can't answer this question if you don't specify which "synchronous/asynchronous" concept it is about (these are broad terms). Please narrow the definition. $\endgroup$ Oct 21 '15 at 6:44
  • $\begingroup$ @YvesDaoust it's clock synchronous $\endgroup$
    – DDDD
    Oct 21 '15 at 13:10
  • $\begingroup$ Then RISC/CISC really have nothing to do with that, but with general processor architecture and instruction set structure. $\endgroup$ Oct 21 '15 at 13:44
4
$\begingroup$

I think that all the instructions in a RISC take the same time what makes me believe RISC is associated with synchronous.

It's not true that all instructions in a RISC CPU take the same time. Even in the classic RISC pipeline, the pipeline will stall in some circumstances. Pipeline interlocks and control hazards are the ones that Hennessy and Patterson go into some detail about, but they also mentioned data cache misses.

Even if you ignore those complications, it's unrealistic to design a general-purpose CPU where every instruction takes the same time these days. Programmers want floating point, and SIMD operations, and so on.

Can you tell me if RISC is associated with asynchronous and CISC is associated with synchronous?

On, that's easy: They're not.

Truly asynchronous CPUs are rare, for a few reasons. One of them is that you can't (currently) prototype asynchronous logic on an FPGA, and it's much harder to express in Verilog or VHDL than synchronous logic.

Having said that, it is easier to implement a RISC pipeline in asynchronous logic than a CISC pipeline (e.g. Sproull's Counterflow Pipeline). However, even this is a bit misleading because the boundary between RISC and CISC is quite fuzzy these days. Most modern CISC CPUs use RISC cores internally, and dynamically translate the CISC instruction stream into RISC code. The main reason for this is that the same features which make RISC attractive (e.g. fixed-size instructions which can be buffered) are also the ones which make superscalar execution work.

So to the extent that asynchronous logic works, modern CISC CPUs can benefit almost as much as RISC CPUs can.

$\endgroup$
2
  • $\begingroup$ I am taking a first aprouch to computer science in a subject about embedded systems, so i don't know some concepts. In a teacher question he asks to stablish the nexus between CISC/RISC and clock synchronicity/asynchronicity of data transfer. What should i have answered? $\endgroup$
    – DDDD
    Oct 21 '15 at 13:31
  • $\begingroup$ I'd have to see the exact question, but the two questions seem only tangentially related to me. $\endgroup$
    – Pseudonym
    Oct 22 '15 at 1:34
2
$\begingroup$

Actually, instructions don't all take the same time in RISC. They are forced to all take a fixed number of cycles, but the latencies will vary, and even within the same instruction. For instance, adding 1 to 0x01111111 is harder than adding 1 to any even number.

And you can do RISC or CISC regardless of the strategy used to obtain such an architecture. It isn't the number of instructions needed to produce a result that is the concern here, but more the variability of the lowest-level instructions.

Consider the clock rate, that is just the time it takes for the worst-case instruction (RISC) or instruction part (CISC) to consistently run reliably. It is the lowest common denominator and is applied to all instructions, even those with significantly lower latency. However, if you can run each instruction the precise amount it needs at a given time, you could improve performance.

So the above considerations affect your build philosophy. For a clocked system, you'd be racking your mind trying to figure out how to eliminate certain bottlenecks that are holding back your clock rate. For a clockless implementation, you'd be more concerned with improving the performance of nominal/average values and operations.

Clocked Approach

If you are designing a 6502-similar CPU using the synchronous approach, you'd be trying to figure out how to do BCD math faster to not slow the critical path for the rest. So maybe you'd use a carry-skip adder arrangement or break down your BCD instructions internally to require 2 or more cycles. You would figure that it isn't fair to hold back the other instructions because BCD is slower than binary math, and that making the BCD instructions require more cycles to complete by breaking them into smaller micro-ops would be worth it for a faster clock rate overall.

Asynchronous Approach

Designing the same type of CPU above, you wouldn't be as concerned with edge cases that take longer as they will be allowed to take what time they need when necessary. While you could do a carry-skip or CLA adder arrangement, you won't feel as compelled since the edge cases won't cut into the critical path in every instance.

Interestingly, this approach could even help slower operations. Consider an instruction that takes 1.6 times the usually-allowed latency. On a clocked system, you'd need to break that up into 2 instructions or micro-ops. On a clockless system, you can give it the exact extra time that it needs.

Back to the RISC part of the question.

It is easier to think of RISC in terms of fixed cycles, but it is more about the size of the building blocks you use. It is more about using instructions that just do one task (though that can be a group of things that happen coincidentally or in parallel) as opposed to using larger instructions that require a number of sub-tasks performed in series. This distinction can be blurry at times. For instance, the Gigatron TTL computer is a RISC machine on the native Harvard side, but there are a few instructions that do up to 3 things at the same time (OR/AND during a memory read and route that to the port while incrementing the index register). Now, instructions such as that are used to make the vCPU interpreter that allows user code to run, and that is like microcode in that it builds more complex instructions.

So once you take the clock off the table, then you'd still have a RISC machine. It would be harder to quantify as such, but that won't change. What will change are the latencies per instruction (and even within the same instruction ran at different times such as math operations). Clocks are just arbitrary time units designed to take the worst cases into account. But you could otherwise use a RISC model. The clock thing is about a different type of granularity than what is commonly thought of in RISC v. CISC.

$\endgroup$
1
$\begingroup$

A purely asynchronous CPU would not need a clock, so based on that point alone, it is clear that RISC and CISC are both synchronous as both have their operations granulated into clock bins. However, both RISC and CISC processors can have asynchronous logic blocks nestled between clocked components to achieve particular logic functions.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.