Computer Architecture and Assembly Language Programming Course Announcement Back

Question

Companies opt for a hardware technology that meets its objectives. Suppose, an e-marketing firm wants to have an architecture that responds quickly to interrupts with less spilling of registers and higher processor performance. You are required to pick either a stack based machine or a register based machine in the given scenario.

The selection of either architecture must be supported by logical reasons.

Answer 1

For better processor performance and fast interrupt responses, the e-marking firm in this problem would want to opt for a register-based hardware machine.

Let's first start with what a register based machine and a stack based machine look like. A register based machine uses a large number of registers alongside global memory that's typically DRAM (Dynamic Random Access Memory). To compute something - that something is usually an "instruction" that's defined by the instruction set architecture (like x86, MIPs, ARM, and more recently, RISC-V) - we'll load data from our global memory into registers if need be, do the computation within registers, and then write our result back to another register.

Let's say we want to do the following:

C = A + B

With a register based machine, you would do something like this:

1. Load A to a register from memory
2. Load B to a register from memory
3. Add A and B and save that in another register (NOT directly to memory)

A stack based machine would do that differently. Instead, it maintains a stack in global memory, and repeatedly sends and loads data to and from. However, it also has registers like the register based approach to perform the computation. The difference is in the number of registers - it has nowhere near as many as the former approach.

With a stack based machine, you would:

1. Load A from memory
2. Load B from memory
3. Add A + B
4. Write A and B back to memory

Most CPUs - stack based or register based - like to track each tick (in each tick, we do a computation) in terms of something called clock cycles. Here's some numbers to think about:

1. Reading and writing to a register make take something around 20-30 clock cycles. This is a general estimate, and really depends on your CPU.
2. Reading and writing to memory can take 800-900 clock cycles. You can think of the underlying reason for this as that DRAMs end up using capacitors, unlike registers, which take wayyy longer to fetch data from.

Stack-based architectures are forced to read and write from memory more often than registers, since their instructions involve reading to and from the stack. That means they have to wait that 800 cycle timeframe a lot more often! So it's slower overall just because we are forced to depend on memory.

Comparatively, register based architectures face problems like this only when there's not enough registers, leading to a spillover (at which point both architectures are forced to do the wait of shame for memory). But these architectures usually have a LOT of registers, so it's more likely that the interrupt-based program takes less time on the register based architecture, especially if there's not a lot of intensive other processes running.

Recap:

1. For the e-commerce firm, we want a register based architecture to avoid too many trips to DRAM memory.

Some things to consider:

1. How many programs are running, and are they the kinds that use up lots of registers? Generally those programs involve a lot of heavy computation. Think matrix multiplications. If the other programs use up all the registers, you'll have to pay a similar price when it comes to memory. But more modern processors / CPUs don't really face that problem.
2. What if cost came into question? Adding registers is much more costly than adding more memory. As a computer architect, we try to find a healthy balance that's the best of both worlds. Not too expensive, but enough registers to be useful. But if cost becomes a concern, one may have to think about architectures that are stack based.