Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Orthogonal instruction set
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Orthogonality== Orthogonality is the principle that every instruction should be able to use any supported addressing mode. In this example, if the direct addressing version of <code>ADD</code> is available, all the others should be as well. The reason for this design is not aesthetic, the goal is to reduce the total size of a program's [[object code]]. By providing a variety of addressing modes, the ISA allows the programmer to choose the one that precisely matches the need of their program at that point, and thereby reduce the need to use multiple instructions to achieve the same end. This means the total number of instructions is reduced, both saving memory and improving performance. Orthogonality was often described as being highly "bit efficient".<ref name=arch/> Keeping the addressing mode specifier bits separate from the opcode operation bits produces an orthogonal instruction set. As the ultimate end of orthogonal design is simply to allow any instruction to use any type of address, implementing orthogonality is often simply a case of adding more wiring between the parts of the processor. However, it also adds to the complexity of the instruction decoder, the circuitry that reads an instruction from memory at the location pointed to by the [[program counter]] and then decides how to process it.<ref name=arch/> In the example ISA outlined above, the <code>ADD.C</code> instruction using direct encoding already has the data it needs to run the instruction and no further processing is needed, the decoder simply sends the value into the [[arithmetic logic unit]] (ALU). However, if the <code>ADD.A</code> instruction is used, the address has to be read, the value at that memory location read, and then the ALU can continue. This series of events will take much longer to complete and requires more internal steps.<ref name=arch/> As a result, the time needed to complete different variations of an instruction can vary widely, which adds complexity to the overall CPU design. Therefore, orthogonality represents a tradeoff in design; the computer designer can choose to offer more addressing modes to the programmer to improve code density at the cost of making the CPU itself more complex.<ref name=arch/> When memory was small and expensive, especially during the era of [[drum memory]] or [[core memory]], orthogonality was highly desirable. However, the complexity was often beyond what could be achieved using current technology. For this reason, most machines from the 1960s offered only partial orthogonality, as much as the designers could afford. It was in the 1970s that the introduction of [[large scale integration]] significantly reduced the complexity of computer designs and fully orthogonal designs began to emerge. By the 1980s, such designs could be implemented on a single-chip CPU.<ref name=arch/> In the late 1970s, with the first high-powered fully orthogonal designs emerging, the goal widened to become the [[high-level language computer architecture]], or HLLCA for short. Just as orthogonality was desired to improve the bit density of machine language, HLLCA's goal was to improve the bit density of [[high-level language]]s like [[ALGOL 68]]. These languages generally used an [[activation record]], a type of complex [[Call stack|stack]] that stored temporary values, which the ISAs generally did not directly support and had to be implemented using many individual instructions from the underlying ISA. Adding support for these structures would allow the program to be translated more directly into the ISA.<ref name=arch/>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)