Cycle Computer Instructions

[Barb Frison]

In computer organization, an instruction cycle, also known as a fetch-decode-execute cycle, is the basic operation performed by a central processing unit (CPU) to execute an instruction. The instruction cycle consists of several steps, each of which performs a specific function in the execution of the instruction. The major steps in the instruction cycle are:

Each phase of Instruction Cycle can be decomposed into a sequence of elementary micro-operations. In the above examples, there is one sequence each for the Fetch, Indirect, Execute and Interrupt Cycles.

At the end of the each cycles, the ICC is set appropriately. The above flowchart of Instruction Cycle describes the complete sequence of micro-operations, depending only on the instruction sequence and the interrupt pattern(this is a simplified example). The operation of the processor is described as the performance of a sequence of micro-operation.

• The Execute Cycle The other three cycles(Fetch, Indirect and Interrupt) are simple and predictable. Each of them requires simple, small and fixed sequence of micro-operation. In each case same micro-operation are repeated each time around.
  Execute Cycle is different from them. Like, for a machine with N different opcodes there are N different sequence of micro-operations that can occur.
  Lets take an hypothetical example :-
  consider an add instruction:

• The Interrupt Cycle:
  At the completion of the Execute Cycle, a test is made to determine whether any enabled interrupt has occurred or not. If an enabled interrupt has occurred then Interrupt Cycle occurs. The nature of this cycle varies greatly from one machine to another.
  Lets take a sequence of micro-operation:-

Note: In step 2, two actions are implemented as one micro-operation. However, most processor provide multiple types of interrupts, it may take one or more micro-operation to obtain the save_address and the routine_address before they are transferred to the MAR and PC respectively. Uses of Different Instruction Cycles :

The advantages and disadvantages of the instruction cycle depend on various factors, such as the specific CPU architecture and the instruction set used. However, here are some general advantages and disadvantages of the instruction cycle:

In simpler CPUs, the instruction cycle is executed sequentially, each instruction being processed before the next one is started. In most modern CPUs, the instruction cycles are instead executed concurrently, and often in parallel, through an instruction pipeline: the next instruction starts being processed before the previous instruction has finished, which is possible because the cycle is broken up into separate steps.[1]

The program counter (PC) is a special register that holds the memory address of the next instruction to be executed. During the fetch stage, the address stored in the PC is copied into the memory address register (MAR) and then the PC is incremented in order to "point" to the memory address of the next instruction to be executed. The CPU then takes the instruction at the memory address described by the MAR and copies it into the memory data register (MDR). The MDR also acts as a two-way register that holds data fetched from memory or data waiting to be stored in memory (it is also known as the memory buffer register (MBR) because of this). Eventually, the instruction in the MDR is copied into the current instruction register (CIR) which acts as a temporary holding ground for the instruction that has just been fetched from memory.

In addition, on most processors interrupts can occur. This will cause the CPU to jump to an interrupt service routine, execute that and then return. In some cases an instruction can be interrupted in the middle, the instruction will have no effect, but will be re-executed after return from the interrupt.

The first instruction cycle begins as soon as power is applied to the system, with an initial PC value that is predefined by the system's architecture (for instance, in Intel IA-32 CPUs, the predefined PC value is 0xfffffff0). Typically, this address points to a set of instructions in read-only memory (ROM), which begins the process of loading (or booting) the operating system.[2]

The decoding process allows the processor to determine what instruction is to be performed so that the CPU can tell how many operands it needs to fetch in order to perform the instruction. The opcode fetched from the memory is decoded for the next steps and moved to the appropriate registers. The decoding is typically performed by binary decoders in the CPU's control unit.

This step evaluates which type of operation is to be performed, and if it is a memory operation, the computer determines the effective memory address to be used in the following Execute stage. There are various possible ways that a computer architecture can specify for determining the address, usually called the addressing modes.

The CPU sends the decoded instruction as a set of control signals to the corresponding computer components. If the instruction involves arithmetic or logic, the ALU is utilized. This is the only stage of the instruction cycle that is useful from the perspective of the end-user. Everything else is overhead required to make the execute step happen.

Increasing either instruction per cycle or increase cycle count both are valid design choice for processor manufactures. I understand theory, but it would be much clearer if I had some real life example.

So, can anyone give me some example that can benefit both of this design choice? Like which application / type of application/process takes advantage of higher IPC count and which takes advantage of higher cycle count.

It takes much more engineering effort to increase IPC, than simply increasing the clock frequency. E.g. pipelineing, caches, multiple cores--altogether introduced to increase IPC--get very complex and require many transistors.

Although the maximum clock frequency is restricted by the length of the critical path of a given design, if you're lucky, you can increase the clock frequency without any refactoring. And even if you have to reduce path lengths, the changes are not as profound as those the techniques mentioned above require.

From the programmer's point of view, it's in so far an issue, as he has to adjust his programming style to the new systems computer architects create. E.g. concurrent programming will become more and more inevitable in order to take advantage of the high IPC values.

To increase the instuctions per cycle (or, more likely, reduce the cycles per instruction) you generally have to "throw hardware" at the problem -- add more gates and latches and multiplexers. Beyond a certain point (which was passed about a decade ago) you must "pipeline" and be working on several instructions at once. This increase in complexity not only drives up basic costs (since the cost of a chip is related to the area it occupies), it also increases the likelihood that a bug will make it through the initial design review and result in a bad chip that must be "respun" -- a major cost and schedule hit. In addition, the increase in complexity increases loads such that, absent even more hardware, the length of a cycle actually increases. You could possibly encounter the situation where adding hardware slowed things down. (In fact, I saw this happen in one case.)

Additionally, "pipelining" can encounter conditions where the pipeline is "broken" because of frequent (and unanticipated) branches and other such problems, causing the processor to slow to a crawl. So there's a limit to how much of this can be done productively.

I've gotten my self my first mountain bike, along with a Bike computer. This needs to be setup, but im really not sure how i do this. The wheel size of the bike is a 27,5 inches. The bike computer is a Bontrager Trip 100, that comes with the following wheel settings:

One thing is what setting to enter on the computer, but im also unsure about where i should place the sensor and receiver on the wheel. I believe it must matter if i place the sensor and receiver near the center of the wheel, or if i place it need the edge.

Look at page 23 and 24 of the manual and follow the directions for measuring tire rollout. Measure your front tire and select the wheel size on the chart that has the closest measurement to your tire. There can be a big difference in the circumference of different brand/model tires even if the stated size is the same. Measurement of the actual tire circumference will give you the most accurate readings. As far as placement it makes no difference. As long as the magnet on the spoke triggers the pick-up it will count revolutions. The computer does the calculations to convert the data to mph, distance etc. My preference is to mount it as close to the axle as possible. On a mountain bike this keeps it out of the mud and away from branches.

As for placing the sensor, the manual(*) for the trip 100 says that the magnet needs to come within 3-5 mm of the sensor. This is typically done closer to the brakes than closer to the hub on a road bike, but you may need to go further down in order to get the magnet to get within that range on a mountain bike (most 650b bikes sold these days, esp. ones marketed as 27.5" are mountain bikes, as 650b road bikes are often marketed as 650b, so I'm assuming you have a mountain bike). If you're within this range, the sensor mount is good. If it isn't, move it to that range. See the manual for pictures.

Use a roll out method ie measure circumference with a mark on the tyre and roll forward one exact revolution measure with a tape measure the distance covered preferably sat on bike, then put dimension into the custom setting for wheel size, youtube shows a good example.

According to the manual linked to by @Batman, it looks like you can enter a custom wheel size after you have clicked through all the predefined wheel sizes. Based on the fact that it's 4 digits, the custom wheel size is most likely in mm.

c80f0f1006