The IBM System - Assembly Lang Programming 1 | CPSC 3121, Study notes of Programming Languages

Download The IBM System - Assembly Lang Programming 1 | CPSC 3121 and more Study notes Programming Languages in PDF only on Docsity!

Overview of

Computer Architecture

The IBM System/

Edward L. Bosworth, Ph.D.

TSYS Department of Computer Science

Columbus State University

Columbus, GA

[email protected]

The Term “Architecture”

The introduction of the IBM System/360 produced the creation and

definition of the term “ computer architecture ”.

According to IBM [R10]

“The term architecture is used here to describe the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation.”

The IBM engineers realized that “logical structure (as seen by the programmer)

and physical structure (as seen by the engineer) are quite different. Thus, each

may see registers, counters, etc., that to the other are not at all real entities.”

In more modern terms, we speak of the “Instruction Set Architecture” , or

ISA , of a family of computers. This isolates the logical structure of a CPU

in the family from its physical implementation.

In other words, it makes sense to speak of “programming an IBM S/370”

without specifying the model number.

Strict Program Compatibility

This was the driving goal of the common architecture for the IBM S/360 family.

IBM issued a precise definition for its goal that all models in the S/360 family

be “strictly program compatible”; i.e., that they implement the same

architecture. [R10, page 19].

A family of computers is defined to be strictly program compatible if and

only if a valid program that runs on one model will run on any model.

There are a few restrictions on this definition.

1. The program must be valid. “Invalid programs, i.e., those which

violate the programming manual, are not constrained to yield

the same results on all models”.

2. The program cannot require more primary memory storage or types of

I/O devices not available on the target model.

3. The logic of the program cannot depend on the time it takes to execute,

unless the program explicitly tests for event completion.

The smaller models are slower than the bigger models in the family.

More Design Goals

Here are more goals for the S/360 architecture, taken from [R_10].

1. Since computers develop into families, any proposed design would

have to lend itself to growth and to successor machines.

2. Storage capacities of more than the commonly available

32,000 words would be required.

3. Certain types of problems require floating–point

word length of more than 36 bits.

4. Since the largest servicing problem is diagnosis of malfunction,

built–in hardware fault–locating aids are essential to reduce down–times.

5. The general addressing system would have to be able to refer to small

units of bits, preferably the unit used for characters.

6. The design had to yield a range of models with internal performance

“varying from approximately that of the IBM 1401 to well beyond

that of the IBM 7030 (Stretch)”.

The Fetch–Execute Cycle

This cycle is the logical basis of all stored program computers.

Instructions are stored in memory as machine language.

Instructions are fetched from memory and then executed.

The common fetch cycle can be expressed in the following control sequence.

MAR  PC. // The PC contains the address of the instruction.

READ. // Put the address into the MAR and read memory.

IR  MBR. // Place the instruction into the MBR.

This cycle is described in many different ways, most of which serve to highlight

additional steps required to execute the instruction. Examples of additional

steps are: Decode the Instruction, Fetch the Arguments, Store the Result, etc.

A stored program computer is often called a “von Neumann Machine”

after one of the originators of the EDVAC.

This Fetch–Execute cycle is often called the “von Neumann bottleneck” , as

the necessity for fetching every instruction from memory slows the computer.

The Dynamic–Static Interface In order to understand the DSI, we must place it within the context of a compiler for a higher–level language. Although most compilers do not emit assembly language, we shall find it easier to under the DSI if we pretend that they do. What does the compiler output? There are two options:

1. A very simple assembly language. This requires a sophisticated compiler.
2. A more complex assembly language. This may allow a simpler compiler, but it requires a more complex control unit.

The Central Processing Unit (CPU) The CPU has four main components:

1. The Control Unit (along with the IR) interprets the machine language instruction and issues the control signals to make the CPU execute it.
2. The ALU (Arithmetic Logic Unit) that does the arithmetic and logic.
3. The Register Set (Register File) that stores temporary results related to the computations. There are also Special Purpose Registers used by the Control Unit.
4. An internal bus structure for communication. The function of the control unit is to decode the binary machine word in the IR (Instruction Register) and issue appropriate control signals, mostly to the CPU.

Design of the Control Unit There are two related issues when considering the design of the control unit:

1. the complexity of the Instruction Set Architecture, and
2. the microarchitecture used to implement the control unit. In order to make decisions on the complexity, we must place the role of the control unit within the context of what is called the DSI ( D ynamic S tatic I nterface). The ISA ( I nstruction S et A rchitecture) of a computer is the set of assembly language commands that the computer can execute. It can be seen as the interface between the software (expressed as assembly language) and the hardware. A more complex ISA requires a more complex control unit. At some point in the development of computers, the complexity of the control unit became a problem for the designers. In order to simplify the design, the developers of the control unit for the IBM–360 elected to make it a microprogrammed unit. This design strategy, which dates back to the Manchester Mark I in the early 1950’s, turns the control unit into an extremely primitive computer that interprets the contents of the IR and issues control signals as appropriate.

The Micro–Programmed Control Unit The goal of the System/360 micro–programmed control unit [R_51] was to “help design a fixed instruction set capable of reaching across a compatible line of machines in a wide range of performances”. The same authors [R_51] go on to note that “the use of microprogramming has, however, made it feasible for the smaller models of SYSTEM/360 to provide the same comprehensive instruction set as the larger models”. Tucker [R_51] notes that “There has been much talk, but little success, in providing higher–level languages for micro–programs. There seem to be a number of factors which contribute to this. Primarily, almost no inefficiency is tolerated in micro–programs”. Tucker goes on to speak of the “micro–programmer who can justifiably spend hours trying to squeeze a cycle out of his code and who may make changes to the data path to do so”. Tucker notes that the System/360 Model 30 is micro–programmed to run IBM 1401 programs in their native form. This was an additional inducement to those owning an IBM 1401 to “move up”.

Handling Legacy Software During the introduction of the System/360, IBM underestimated the large customer investment in legacy software especially at the assembly language level. In order to prevent mass defection of customers to Honeywell, which was offering its model H–200 that would run IBM 1401 assembly language programs, IBM was forced to develop some sort of simulator to run on the System/360. It was understood that a software simulator of the IBM 1401 running on any System/ model would be unacceptably slow. IBM was “spared mass defection of former customers” when engineers working on the Model 30 suggested the use of an extra control store on the micro–programmed control unit to allow the Model 30 to execute IBM 1401 instructions in native mode [R_62]. Stuart Tucker and Larry Moss led the effort to provide the ability on the System/ Model 30 to execute native mode software for both the IBM 1401 and IBM 700 series. Moss termed their work as “emulation” [R_63]. The emulators they designed worked well enough so that many customers never converted legacy software and instead ran it for many years on System/ hardware using emulation. This was a great marketing success for IBM.

Registers 13, 14, and 15 are used by the control programs and subprograms.

More on the General Purpose Registers There are two important concepts discussed in the previous slide.

1. That only registers 3 through 12 of the sixteen registers are to be viewed as truly general purpose.
2. That the use of some hardware resources evolves by consent of the software designers. There is nothing in the hardware architecture that restricts the use of registers 0, 1, 13, 14, and 15. The restricted use of these registers is a design decision by the system programmers to facilitate the design of system software. These ten registers, R3 – R12, can be used for binary integer arithmetic, and for the computation of the effective address of a memory storage element. The System/360 and subsequent machines use base–displacement addressing with an optional indexing. The index value is stored in the index register, a general purpose register that is being used as an index. We shall discuss indexing later. A base address is stored in the base register, a general purpose register that is being used as the base register. We shall discuss base registers later.

Design Decisions: The Data Format Apparently, there were two main options for the size of the basic storage cell. 2 N the size would be 4, 8, 16, 32, or 64 bits. 3  2 N the size would be 6, 12, 24, or 48 bits. Character size, 6 vs. 4/ At the time, the character set of existing IBM computers comprised 64 characters, inherited from the punch card codes of the day. Decimal digits required 4 bits to encode; general alphanumeric characters required 6 bits. On option was to use 6 bits to encode everything. This wasted 2 bits for each encoding of a decimal digit. Another option was 4 bits for digits and 8 bits for alphanumeric characters, thus wasting 2 bits for every alphanumeric character. The option of 4 bits for digits and 6 bits for alphanumeric characters would require the basic addressable unit to be a multiple of 12 bits. This was thought overly complex. In the end, all of the “6 options” were rejected, because the designers realized that committing to a 6–bit character encoding was “short–sighted” [R_10].

IBM 029 Punch Card Codes Here is a card punched with each of the 64 characters available under this format. Note the lack of lower case letters; the IBM Mainframe assembler reflects this. This is the complete set of characters to which the designers thought it would be “short sighted” to commit. They held out for a larger character set.