is sit

... ----+----,

I BUG S I

L _ _ _ _

+ ___ _

^J

The Drown University Graphics Systemt

META 4 13 I SIMALE I VECTOR GENERAL

Paul Constantine Anagnostopoulos

Harold Henry Webber' , Jr.

John Zahorjan

'l'he Brown University Graphics Project Division of Applied Mathematics

Box F

Brown Uni versi t y

Providence, Rhode Island 02912

Updated: January 12,1 976 Printed: Decembet: 6, 1976

tThis Research is being supported by the National Science Foundation Grant GJ-28401X, the Office of Naval Resea rch, Contract N000 14-67-A-0191-0023, and the Drown University Division of Applied Mathematics; Princi pal I nvestigator Andries van Dam.

I sometimes feel, in reviewing the evidence on t he design of computing systems, that the necessary conclusion is that de-kludging just i s not possible. It is difficult to conceive of a mechanism which can satisfy the conditi,ns necessary for it.

Nevertheless, in spite of such evidence against it, de-kludging does sometimes occur.

--adapted from Karl S. Lashley, 1950

2

3

I nt rod.uction 1. 1 Overview ••

1 2 System Component

• ••

· ..

• ••

Concepts.

o •

· .

1. 2.1 Units . . . . • . • , •.

· . · . . . .

1 • 2. 1 1.2. 1 1.2. 2

1 2

Processors ••

Input/Output Stores . • . . .

· ^.,

^{• •}

U ni ts ••

· ...

^{• •}

1. 3 Componen t De scr:i pt ions. • ••

1.3.1 Processors. • NETA

META 1 • 3. 1

1.3. 1 2 1.3. 1. 3 The

411.

4BI.

SIMALE.

1.3. 1.4 Nain store.

1 • 3. 1 • 5 Di sk S to r:e • 1. 4 System Stcuctur:e.

1.4.1 User •.••••••

· . · . · .

· ^{. ·} ..

· ...

· ^.

•

· .. · .

1. 4.2 1. 4. 3 1.4. 4 1. 4. 5 1. 4.6

Pr:ogr:amming Languages ••

Manitor:.

· ...

Extended Monitor.

o •

Q-interpreter • . . . Extended Q-inter:preter.

· .

· . ...

•

• ••

· . . .

· .

· . . .

• • • 0

• •

• •• • •

• •

1. 5 On wa r:d.

. . . . . . . . . . . . . . ..

• •• • •

· ^. · ..

Data Facilities 2. 1 Intr:oduction.

2. 2 P r:og.r:a mmer: S tor:es.

2.2. 1 Register File •.

2.2.2 Local Stor:e.

· .

• •

· ^.

· .

· ^.

· .. · .

^{• • • •}

· ^.

^•

• •

•

•

· ..

2.2. 3 2.2.4

Main Store • • . .

Vector General Register File •• _{• 0} 2.3 Data _{2.3.1 Num}1'_er:ic ypes •••.•• _Data.

. ^.

^{• •••}

_· .

• • • • •

· ^.

2.3. 1.1 2.3 . 1 2 2.3.13 2.3. 1 4

In tegers ••

· .

Fl-actions. • •

I ndex-Base-Displacement.

Procedur~ Displacement ••

Da ta •• •

· ^...

•

2.3.2 String 2.3.2.1 2.3.2.2

By te . . . . ^{• 0} Ch ar acte r: Str:ing ••

Program Facilities . • . . . • . • . 3.1 Pr:ocedure Desc.i:iptian.

3. 1.1 lntr:oduct ion.

3.1.2 Progr:amming •••• • ••

· .

3.2 Instr:uction DesSr:iption.

3.2. 1 Introduction.

3.2.2 Operands . . . • . • • • Integers . . . .

· .

^•

· .

0 0 •

• 0 •

0 0

· .

3.2.2. 1 3.2.2.2 3.2.2.3 3.2.2.4

· .. · .

^{0 0}

Fractions .•.

Index-Base-Displacements.

Pr:ocedure Displacements •••

- i-

• 0

•

• •

· ..

• •

• ••

· .

· .

• •

· .

· .

•

• •

· .

•

· ^.

•

•

• •

•

•

· .

• •

•• •

· . .

•

...

• •

· .

•

o

• • 0

' . . ..

· .

• •

· . . .

^•

·

•

.

• 1 1 1 2 2

• • 2

· . · ... · ...

³

3

· ...

^{• •} 3

· ...

· .

· ....

^"

^{' .}

....

· ...

· .. . ....

· ...

· ...

· .

•

• •

.. . . · · .. .

· ...

· ...

· . · .

· .

· .

· ... · ...

· .

· . · .

• •••

· ..

· · ^. . · .

· . · ^.

· .

· · .. ^.

^,

· ...

• •

· ... .

· .... · ^.

• ••

· ..

. .

•

•

· ...

· ...

· .

· .

· ...

• •

·

• •

.

· ...

· ^.

· .

· .

· .

4 4 4 5

• .5

• 5

• 6 . 6 .6

• • 6

• .7

• • 7

• • 8

9 9

• '. 9 9

10

• 10

• •• 1 1

• •

•

1 1 11 1 1 12 12 13 13

• •• 1 3

• •• 1 3

· · . .

· .

·

• •

^.

· .

. .

• 14 14 14 16 16 16 17 17 17 17 18

3.2.2.5 3.2.2.6

Byte s . . . . Char:acter: strings . 3.3 Pr:ocedur:e Checks •••••••

· .

· .

· .

•

• •

· ..

. . ^...

· ....

· ... .

• ^{1 8} 18 18 The Tra nsfe r Da ta Ins tr uc tion.

· ... .

^{.1 9}

5 Branclling I nstructions . • ••

5. 1 Introduction . . . . • • • . • . . • • .

5. 2 Condi t ion Fl ag Register •••

· ^.

^{• •}

5.3 Unconditional Branching Instructions ••

5.4 Conditional Branching Instructions . 5. 5 CASE ••••••••

· ... .

6 Data Moving Instructions. 6.1 Unary Instructions . 6.2 Replace.

6. 3 Swap ••••••

Instructions ••

· ^. · .

• •

· .

· .

• ••••

• ••

· .

· ^.

^•

7 Shift

7. 1 In tr:od uc tionA • •. • •• ••

7. 2 7. 3

Arithmetic Shift Instructions ••

Logical Shift Instructions •• ••

· .

8 Arithme tic I nstrllctions ••

· _· . _.

Test

· .

8. 1 Test Sign . . • . . . . • . 8. 2 Una r y In crem en t.

8. 3 Unary Decr:ement and

8.4 Absolute Value a nd Negate. 8. 5

8. 6 8.7 8. 8

l\.d d ••••••

su btra ct.

~lultiply ••

Divide.

S ig n.

8. 9 ExtE.nd

8. 10 Square [loot ••

· ..

. '

.

· ...

· .

• •

•

· ^...

9 Comparison Instr:uctions ••

9.1 Arithmetic Compares. 9. 2 ^Logical Compares •••• •

•

•

• ••••

· . .

• •

. ..

· ...

· ..

· ...

.. . ^.. .

· .

· .

· .

•

l OBi t 10. 1 10. 2 10.3 10.4 10.5 10. 6 10.7

and Char:acteI; St r:i ng I nstr uction s.

· ...

Or ••

. ^. . .. . . . . . . . . · . · ..

ANt I ns tr:uctions .

· ...

EXCLUSIVE OR I nstruction.

Test under: Mask Instr:uctions.

Scan.

T r:a nsla te ••

Initialize.

· .

· . ^{. · . . .}

^{• •}

11 Subroutines alld Int errupts ••

11.1 The Stack ••••

· ^.

•

•

· ...

•

•

.. ..

· ^...

•

•

· . · · ... . · .

• •

· ...

· .

· ..

· ...

· .

^{• •}

· ...

^{• •}

21

• 21 21 . 22 . 24 .25 .26 . 26

• •• 28

· .... · ...

^{• •• J 1}

· .

· .

^•

•

• • •

•

· .

· .

^{• •}

• • • •

•

· .

· ... ... .

· ^.

· _... ..

• •

• •

•

· ...

· ...

· ...

· .

· .. ..

· .. · ^.

•

· .

· . · ...

· . · .

• •

· ...

· .

· .

· . · ^...

• ••

. .. .

33 33

• •• ) 3 . •. 36

· . • 38 .38 . 39 .40 .41

• •• 42 .44 . 45 .47

• .48

• .• 48

· • . 50

• •• 50

• •• 52 55

• .. 55

• •• 57 .57

• •• 57

• •• 58 .60 . •• 60 . 62 . 62 11.2 Stack Condi t ions.

· .

^•

_·

^•

....

^{• •• • •}

· ... .

^{• • • •• 63}

11.4 11. 5

Interrupt Procedure

Calls ••

Return.

.. · . . . . . . .

12 Internal Interrupts . . . 12.1 Extended Instruction

" "

..

^"

.

^{" "}

...

III terr upts. 12. 2

12.3

self-Interrupts ••

Procedure Checks.

..

"" "

..

13 Communicati on with the META 13.1

13. 2

Overview." .. "",, •. " .•• ". ".

The Unit Control Bl ocks ••

· .

4A ••

· ^.

· .

^{" "}

" "

..

· .

•

13.3 META 4ft i nterrupts META 48 •••

Q-interpreter- Handled Interrupts ••

Software-Handled Interrupts •••

META 48 interrupt META 4ft ••••••••

Synchronization via Semaphores •••

· .

13. 3. 1 13. 3.2 13.4 13. 5

•

. . .

•

•

•

•

.. · .

· . · .

• • ••

· .

^{• •}

· . · . ..

· . ,..

^"

•

·

^" " "

..

•

· ..

• •

·

^"

... · .

•

· ^.

· .

· .

· .

• •

• •

· .

· .

· .

.65 .67 .68 .68 . 69 69

" " " 7 1

• .71 .7 1 .72 .72

•.• 72 .73 .73 14 The SIMALE

...

^"

..

^"

..

^"

...

^"

...

^"

.

^"

..

^"

.

^{" "}

..

^"

.

^"

...

^"

...

^"

.

^{" .76}

15 vector Gene['al •.•. "."" •• " • .•.••••

15.1 (Vector) General Description. 15.1.1 Introduction ••••••

15.1. 2 CRT Display Unit..

15.1.2.1 Vectors . . . . 15.1. 2.2 Characters.

15. 1.3 Interactive Devices

· .

^{• •} .

•

· .

15. 2 VG Register Fil e . . . .

· ..

15.3 CRT Display Orders ..•..••

..

· . · .

•

· _...

•

.

15.3.1 NO-oPeration and Special Orders . 15. 3. 2 LOAD/AUD/AND/OR reg va lu€s ••••••

15.3. 3 ABSolute and RELative vector order s . 15. 3. 4 CHARacter order •••••

· ..

^"

...

In teLrupts." •• ".

VG Unit Control

..

Block.

15. 4 VG 15. 4.1

15.4. 2 Interrupt In terrupt

~

.

JenslIlg •••• "

15.4.3 Ca 11 Con tro!.

16 ET CETEDA Instruction. 16. 1 Introduction •••

Ra tionale.

. ..

16.1 . 1 16.1.2 16. 1. 3E'fC

ETC Regi sters ••

Instruction.

16 .2 ETC Da ta Structure.

16. 2.1 Data Area. Blocks ... ".

Su b- Blocks.

•

•

.. · .

^•

· .. .

^•

· . ..

^{• •}

...

· ..

· ..

·

^{" "}

. ...

· .

•

" "

..

• • ••

· ..

16. 2.2 16.2.3

16. 2._Vector 4 ETC General Sub-BlocksInstruction Execut i. on.

· .

16. 3 16.4 16.5 A

The Clock Typical

Instruction •••...•

uisp.lay sequence ••

•

17 Running 17.1 RUNB 17 .2

META ^4B Prog rams MULTIPAC.

17.3

Mode •• ""

Normal Mode. ^"

..

"

..

Main Store Control

..

in

..

•

. . ^.

the B ..

-iii-

• •

• •

..

· .

•

·

^"

..

· . · ..

^"

· .

·

" "

. · . . .

•

· .

•

· . . .

" "

..

• "

. .

^"

·

^{" "}

.

· . .

^"

·

^"

..

· ^.

..

•

. ..

· _· ^. .

· ^.

· . .

^"

• •

· ...

• "

..

^"

"

. . .

.

•

. .

• •

• •• • •

•

· . · .

^"

.

· .

^{" "}

.

^"

· .

· ^.

• •

· . · ..

· ^.

· .

• •

· .

•

•

. ..

· ...

•

"

....

^"

· ^.

^"

.

•

· ^.

.77 .77 .77 .77 .•. 78

• .78 .78

· ^.

80 .83 .83

. 84

.85

• 86 . 87 . 87

· .

^._.⁸₈₈ ⁷

• . 90

90 ..90 . 90 . 91

• • 91

91

• •• 92

• •• 93

• •• 93

• •• 94 . 95

• •• 95 .96 . 96

• •• 97

• •• 98

17.4 t.iMS SVCS fL"Om the B ••••••••••••••••••••••••••••••••••••••• 99 18 The Fudd Debugying Package •••••••••••••••••••••••••••••••••• 100

Appendix 0: Appendix 2a: Appendix 2b: Appendix Ja:

Me talinguistic Symbo.1s . . • . • • . . • . • • • . • . . . •• .• •.• ••. 10 1

I nstructions by Mnemonic

Ins tr uctions by Operation Code ASCll to EBCDIC Conversion Appendix Jb: EBCDIC to ASCII Conversion

In trod uction

l .... LQHll.Y.Hli

The Drown University Graphics System:

"The stated objectives of the pr::oject's activities are an

investigation into the ar::ea of medium-cost, micropr::ogr::ammable, intelligent graphics termillals and the

"division of labor" trade-offs between a mainframe processor:: and the intelligent satellite. In addition to these goals, we ar::e also interested in examining ~lle

impact which micropr::ogramming has on the design of other aspects of a gr::aphics -terminal, for:: example, system configur::aticn a nd the local opera ting system design."

--Geor::ge M. Stabler The BUGS Over::view

The META 4D / SIMftLE / Vector Gener::al comprise the core of the graphics facility of the Br::own Univer::sity Graphics System

(DUGS). The purpose of this document is to present the

concepts and facilities of this cor::e in such a way as to make it easy to 1ear::n and pleasing to use by people at all levels of design and implementa tion.

In order:: to accomplish this goal, BUGS has herein been formalized and conceptualized beyond the level done in other::

documents pertaining to the system (a list ot such documents is pr::esented in refer::ences). It is hoped that by so doing, the various facilities can be made more understandable, more

useful, and hence more enjoyable. If this should turn out not to be the case, however, any comments, suggestions, etc., would be greatly appreciated and carefully considered.

How are the hardwaIe components from which BUGS is constructed inter::connected and how do they interact? All components can be divided into one of two classes, known as !ni1§ and §1Qfg§.

- 1-

Intr-oduction

Units ar-e those components of the system capable of peL.for-ruing manipulation of and computation ^UpOIl data. In this way, a unit is an active component whose pur-pose is to allow a per-son to per-for-ru the oper-ations necessar-y to solve his pr-oblem. All units can, in tur-n, be divided into t wo s ub-classes, known as

£IQ£§§§Q£§

and

iD£Y1LQY12Yl Ynil§.

Pr-ocessors ar-e units whose bel.avior is capable of being contr-olled and changed at will, that i s, they ar-e pr-ogrammable. Thus the word pr-ocessor is used in the conventional sense to denote a "computer" or a "CPU". A pr-ocessor- consists of hardware which is capable of executing a set of primitive commands, known as

hQ§l in§lIY£ilQD§,

which can be used dir-ectly by programmers to implement their a pplica tions.

An input/output (I/O) unit is a hardwar-e uevice which i s not progr-ammable, hence having a .fixed function (e.g., a car-d reader or a console terminal). Although I/O units are capable of performing some manipulation of data, their- pr-incipal function is to tr-ansmit and pr-esent data to other system components and to human users.

In trod uc tion

A store is a passive component of the s ystem whose sole capability is that of retaining or remembering data. I t is the conventional memory space of a computer, although various types of stores with various operating speeds may

I be present on the system. Examples of stores on BUGS are main core storage and secondary disk storage.

Edch of the above components will be described in greater detai l below. Simply keep in mind the simple picture of stores containing programmer-defined data structures; these data structures are operated upon in a fixed manner by I/O units, and in a variable manner by the processors.

The diagram on the following page pictures the various components of BUGS and their interconnections. Data is , in most cases, transferred among components in groups of sixteen bits, called !!i!lf!iQI~2' Furthermore, most stores a.r e halfword-oriented, also containing data in 16-bit groups, each

halfword accessabl e via an address specified by a number from zero to n. (The exception is the SIMALE, as described la·ter.) The following paragraphs describe the components in greater detail.

There are three processors in 'BUGS: the META 4A, META 43, and the Super-Integral Multi-purpose Arithmetic/Logic Expediter (SIMALE). Each processor has three stores for its own internal use, a nd may be co.nnected to a variety of I/O units . .

As was previous ly mentioned, each processor is capable of executing a set of primitive host instructions . Programs composed of these intructions reside in a program memory known as £Q1l1IQl §!Q!:g. It is from control store that the processor fetches, decodes, and executes host ins tr uc tion s.

Programmers us ing host instructions require work space in which to keep operands , temporary results, etc. , and with which to communicate to other units. This work s pace comes as a set of halfwords known as a I~~i§l~I Kilg. Each processor has its own register fi le.

- 3-

Introduction Finally, each processor is equipped with a relatively large

lQ£~l §lQ!:~ for retaining larger amounts of information s uch as tables, matrices, or data lists. Although sma ller than main store, local store is at least an order of magnitude faster, and hence s hould be used for retaining often-used information.

'rhe META 4A processor is composed of a Digitial scientific corp. META 4 computer. The META 4A is eguipped with control store consisting of 4K2 halfwords of !:~~g=Q~lY ill~illQ!:Y (ROM), making modification of host programs diff icult. The register file consists of 32 half word registers, many of which serve special purposes. Local store has not yet been implemented and is unavailable to the programmer.

The I/O. units connected to the 11ETA 4A include a disk controller, a console terminal, a control panel, and a general-purpose binary switch. In addition, the META 4A is connected via a multiplexor channel to a S/360-67.

The META 4B processor with its nature to the META 4A, althouyh halfwords of local store.

stores is identical in it is eguipped with lK

The only General display.

I/O unit connected to the META 4B i s the Vector

(VG) high-speed CRT t ube used for graphical

The S.ll1ALE is a high-speed uni t wnich is actually composed o~ four independent sub-processors. Originally intended to be used solely for the matrix operations necessary for graphical transformations, i t has evolved into a completely general-purpose processor. It is eguipped with 256 halfwords of fully readable-write able control store which contains t he host program. In addition, each sub-processor has a register file with three l8-bit registers, and a local store with sixteen l8- bit locations . There are no I/O units connected to the SIMALE.

Introduction It should be clear from the diagram that data paths exis t between the SIMALE and the META 4B, and between the META 4B and the META 4A.

Main store is the central data memory for the system.

It is accessable from both the META 4A and META 4B processors, so that it can contain data structures, programs, e tc. It can also be accessed directly by the disk controller so that data transfers can be made directly to and from main store without processor intervention. A halt word can be transferred to or from main store in 900 nanoseconds.

He are currently eguiFped with 32K halfwords of main sto["e.

Disk store is implemente d on large circular packs, each of which contains 512,000 halfwords. These packs are re movable and replaceable, hence allowing victually any amount of backup s torage. However, data is accessed via the disk controller I/O unit, and the access time is extreme ly s low, averaging approximately 250

mi lliseconds.

It has been said that, given the components described above, a user/programmer could implement his applications using the host instructions provided by the processors in conjunction with stores and I/O units. This would be extremely crude, however, given, the rather primitive nature of these instructions, the fixed ROMs in the META 4A and META (IB, and the lack of programming facilities in general.

To alleviate this problem, the designers of BUGS have provided the user with various facilities to aid him in his work. These facilities are embodied in an overall system

§1'£.!l£1l!!:~; this s tructure encompasses various conceptual

l~Y~l§ into which the facil i t ies fall. Each level has the use of those facilities supported by the lower le vels , and in turn offers various additional facilities to the levels above it. The system structure i s pictured below and described in the following paragraphs.

- 5-

Introduction

At the pinacl e of the structure is the user himself, provided with all the faci l i t ies s upported by t he levels below him. All in all, the level at which he can design and i mpl ement is much closer to the probl em descri ption than i t he were to work on the bare hardware. He comes in con tact with t he following three l evels :

The programming language is the user's vehicle for expressing t.he computations he wis hes to perform. Ideally t his programming language would be f ull Englis h, however curre nt technology allows only si mple artif icial languages,

ranging across a s pectrum starting with s uch high-level l anguages as PL/I and continuing down to a language which is directly e xecuted by the hardware (i.e ., the host l anguage). On BUGS we will ha ve a high-le vel lang uage cal led ALGOL W, a nd currently have a low-level PL/360-like

language called PL/DUGS, and

2§§gm£lx

^{12Qgg~gg, to be}

described later.

The monitor, al so called the ope rating system, i s a comprehensive package of p~ograms provided to the user for performing standard and often-used f unctions . These functions include I/O unit control, management of s torage space, progL"am control, etc.

The extended monitor comprises an extension to the monitor which is spec if ically oriented toward the application with which the user is involved. Such extensions might include graphical s upport packages, scientific s ubroutines, or communications programs. The extended monitor provides those useful faci l i t ies which do not belong in the standard monitor because the y are not generally used by all applica tions.

Introduction

As we have said, the user expresses his a lgorithms in a programming language, as opposed t o directly in host instructions. Clearly then, we must have a program, called a £Ql!lE!.l!Zf, which takes the user's programs and translates them into a sequence of host instructions . This i s a very difficult task, however, due to the primitiveness of the host; current compiling techniques dictate that such compilati on ' would be extremely inefficient and time-consuming. We might then be torced to design programming languages that were lower-level, closer to the host in the worst case we could require the user to specify each host instruction individually, something which we stated would be unreasonable.

In order to make high-level l anguages possible, and in order to provide the user with a reasonably useful language

in the absence of a high-level one, we have provided a q-interpreter (commonly called an emulator) to act as an interface between the host machine and the programming language. The q-interpreter, written in the host instructions and residing in control store, provides facilities which are much more useful than the host itself.

Such faci l i t ies may include the interpretation of higher-level intructions or data structures, control of 1/0 units, control of communication wi th other processors, etc. In other words, the q-interpreter provi des the well-known assembly language instruction set.

Ideally, many di fferent q-interpreters could exist, one for each application, one for each high-level languages to compile into, et c. Each of these g-interpreters could be des igned so as to be well-suit~d for its intended purpose.

However, the exist ence of ROM for control store rules this out, except in the case of the SIMALE (where i t is f ully exploited, as described later). Therefore, a g-interpreter had to be designed which was useful for all applications and all progr~ruruing languages, obsiously a Ropeless task.

In order to hel p alleviate the unadaptability of the ROMs, an extra level has been added between the g-interpreter and

the programmming language. This level, implemented using the faci l ities provided by the q-interpreter, extends the q-interpreter by supporting additional faci l i t ies in a manner transparent to the programming language. Since the extended q-interpreter i s programmable just like higher levels of the structure, features can be added with ease, debugged, experimented with, etc. However, the

-7-

Introduction programming language uses the m just like any other feature, and hence need not know that they are not really part of the g-interpreter. Eventually, when a feature is completely implemented, it can be moved down into the g-interpreter, causing an increase in speed with no reprogramming necessary.

Due to their implementation, each level fal ls into one of three categories, depending upon i ts "solidity". The mos,t solid i s the hardware, changeable only via e ngineering modifications. Next, the q-interpr:eter, although changea.ble, is "firm", both because it may reside in ROM and because i t is somewhat difficult to program • . Finally, the remaining levels, the major:ity thereof, are "soft" -- easily p.r:ogr:ammable and adaptable.

The r:emainder of META 48 / SIMALE / chapter:s describe q-in te rp r:e te r:.

this document is devoted to describing the Vector: Gener:al units of [JUGS. The next few the facil i t ies pr:ovided by the META 4B

Data Facilities

The META 48, with its q-interpreter, becomes a general- purpose processor. It provides many storage and data types to the programmer with which he can design a nd implement any type of data structures and data bases necessary for his application. In order to operate upon this data, a comprehensive set of instructions is provided, which can be used directly i n assembly language or via a high- level language and i ts compiler.

There are four types of stores provided to the META 48 programmer: register fi le, local store, main store, and the VG regis ter fi le. These stores are described briefly in the following paragrapbs ; more detai led information is given in the course of this document.

The programmer, rather than using the processor' s register

f~le, is provided with a more extensive one of his own.

This register fi le consi sts of 64 halfword registers, divided into fo ur groups of si xteen each.

The fi rst group, numbered 0 - 15, is called the

ggng~.l=~Q~BQ§g ~gg~§l§£§ (GPR) . These registers can be used to' contain numeric data for purposes of arithmetic or compar:ison, addr:ess data, program flags, etc. They are the major store for performing data operations, and can be referenced by all

instructions.

The second group, numbered 16 - 31, is the £QU1£Ql

£gg;j&t§£§. 'rhese registers a.re used by the q-interpreter to control the execution of a user's program. Access to these registers might be useful to the programmer, and hence they are included in his register file.

The third group, numbered 32 - 47, is the

.111

£~lglill.

i!l§.!.~Q£.tiQ!l ~ggi§.tg~§. Refer to Chapter 16. for an explanation of this group.

-9-

Dat a Facili ties The final group, numbered 48 - 63, is the ~!.!:l1\fE;

2xi.!H:lH!.! !:gg.!§i2!:§,

used as a com mu nica tion a rea between the programmer and the SIMALE processor.

The META 48 is equipped with a 256-halfword local store (soon to be expanded to lK). This local store contains often-used data, both for the user and the q-interpreter. The contents of the first 96 locations are pre-defined, as follows:

Tt,e f irst correspond

o -

15.

sixtee n ha l.fwords, numbered 0 15, one-for-one with general-purpose registers

Locations 16 - 3 1 data queue between is necessary in display on the VG.

are used by the g-interpreter for a the SIMALE and the VG. This queue order to maintain a high rate of

Locations 32 - 47 correspond one -for-one with the ET CBTERA instruction registers 32 - 47.

Locations 48 63 correspond one-for-one with the SIMALE external registers 48 - 63.

Locations 64 - 95 contain the information necessary to mainta'in the swapping of SIMALE virtual control store pages to and from real control store. These 32 half words are called the ~!.!:l1\1E; Yi!:i~2.!

gQrri!:21 §i2£2

£~g2

i!!H2'

All local store locations from 96 on up can be used by the programmer for any purposes he desires.

The META 48, along with the META 4A, has access to main store which is eguipped with 32K ha lfwords. These halfwords comprise the major store for both the user's data structures and his programs.

There is a major difference between the hardware operation of main store and the way the programmer uses i t via the

Data Facilities then, the low-order bi t of an address specifies one of two bytes within the half word addressed by the remaining bits.

In spi te of reguires that byte address, reguirement is

this added flexibility, the q-interpreter certain 16-bit data be located at an even 1. e., not cross a halfwocd boundary. This cal led halfword ~li[nmgnt.

The VG displa y unit is equipped with a cegister file containing 85 registers of varying sizes (II one great ec t han 16 bits). These regist er are used to control the di splay, handle user input devices, a nd provide information to the programmer.

We have described the data stcres which ace available to the pcogcammec; what sort of data can he keep in these stores? A vaciety ot data types exist, each of which is useful for solving certain t ypes of problems. These data types are divided into two classes: numeric and string.

The operations which can be performed on t hese data types are described beginning in Chapter4.

lntegers are the simplest form of numeric data.

consist of some number 01' bits (commonly representing a base two integer number.

They 16 )

Integers used for performing arithmetic need to be si gned. Hence they are stored in two's-complement binary form, with the high-order bit indicating the sign. A sign bit of 0 signifies a non-negative number, whi le that of 1 s ignifies a negative one. Some integers and their decimal equi valents are:

000 . . . 000 ~

a

(base 10) 000 ••• 001 ~ 1

111 . . . 111 ~- 1

111 . . . 100 ~-4

- 11-

-'

Data Facilities The value of an n-bit signed integee eanges feom -2** (n-1) up to +2** (n-1) -1. Thus a halfwoed 'integer can have the values -32,768 up t o +32,767.

It is also possible to work with unsigned integers, which are called lQgbf~l. The value of a n-bit logical integee rallges from 0 up to +2**n - 1. The most impoetant use of logical integers i s for addressing data stores, which have locations numbered feom 0 on up. Al l references to stores must eventually gellerate a logical

,integer to act as the final location address.

I t is possible for the programmer to woek with signed fracti ons on the META 48. A feaction is eepresented as an II-bit t wo' s-comple ment binary numbee, the high-order bit indicating the sign. The binary point is assumed to lie between t he sign bit and the next high-order bit.

This allows fractions in the eange - 1.0 up to +.999 •••

Examples of feactions are:

Fractions are because the cooL'dina tes.

a VG

010 ••• 000 0 11 •• • 000

o

1 1 • • • 111 110 ••• 000 100 ••• 000 necessary

dis~lay

= . 5 (base 10)

= .75

= . 999 . . .

= -.5

= -1.0

data ty pe on the META 4B

SCOp8 uses feactional

An i ndex-base-displacement (XBD) is a data type which i s present only within instructions. It is used to generate an integer which can be used for various purposes quring the execution of the instruction.

Typically this integer is treated logically and used as a main store address in order to obtain one or more bytes for the instruction to operate upon.

The integer i s generatEd from the sum of three other in tegers specified by the index, base, and di splacement. The base i s a 4-bi t field (called the D field in the instruction) which speci fies one of the sixteen general-purpose regi sters , the contents of which is treated as an integer. Added to this integer is the contents of the GPR specified by tJIe 4-bit index (X)

Da ta Facili t ies specifies GPRO, that field is ignored and GPRO is not added to the s um.

If the XBD i s to be used as an address, the above computation will produce the expected result regardless of whether the X, D, or D components are considered to be signed or logical integers; the f i nal sum is a logical illteger specifyitg a location in main store.

See C hap t e r 3. 1 • 1 for an e x pIa na t i ⁰ n.

A byte i s the simplest ferm of s tring data. It consists of any single byte of information, which could be an 8-bit number, a character, or a flag. A byte is also a character string of l ength one (see next paragraph).

A character string is a sequence of bytes in main store, having a length from zero (the

ngll

^string) to 65, 535. Character strillgs are used to represent arbitrary l ength logical data (e. g. , a PL/I bit string) or character stri ngs in the usual sense (e.g., messages).

-13-

Program Facilities

The q-interpreter provides a comprehensive set of facilities whicl. can be used directly 1n assembly language or via a high-level language. Speci fications for a high-level language such as ALGOL W will hi de many of the q-interpreter features from the programmer and hopefully make i t easier to proyram. However, it is the purpose of this document to present all of the features for posterity; hence we wil l be oriented toward the asse mbly l anguage programmer.

It is assumed that the reader is familiar with the META 4A Principles of Operation and the facil i t ies provided by Waterloo

Assembler G (ASMG). The differences between S/360 ASMG and BUGSASM A, which are outlined in the META 4A Assembler Users' Guide, do not hold for the META 4B, however. Any di fferences will be presented in this document. The general format used herein is to present each META 4B feature and i ts use in conjunction with BUGSASM B.

The metalinguistic symbols used in this document to speci fy syntax are described in Appendix O.

Th~ average programmer i s accustomed to t hinking of hi s program as a sequence of individual computations leading to the solution of his problem. Programming practice dictates that these computations should be grouped i nto logical sets of associated computa tions, each of which performs a specific porti,on of t he overall job. The META 4B supports such a concept by requiring a program to be split up into

QIQ£~1Y£~!. sequencing of procedures is controlled by procedure

£111

and I~iYID' During the execution of one procedure , other procedures may be called (either explicitly by the programmer or implicitly by the g-interpreter), execute, and return.

The q-interpreter 1S at al l times executing a specific procedure, called the £YfI~Di procedure. The execution of this procedure i s ma intained by three registers in the

register fi le. The f irst, control register 16, i s cal led

Program Facilities PBR is always forced to be even (1. e., the low-order bit is ignoreu). In addition, whenever a new procedure is entered, GPR 15 in the register file i s set to contain a copy of the PBR. This is useful for implic i t addressing of static uata i ll the procedure, and sllould not be modified by the programmer.

PBIl

r---- -, 1 rroc. address 01

L ________________ J

o ¹⁵

The third register is the Procedure Displacement Register (PDR) , control register 17. I t contains the byte displacement from the PBR to tbe next illstruction to be e xecuted. whenever the q-interpreter is ready to execute an instruction, i t fetches it from the locations specified by the s um of the PBR and PCR, and then adjusts the PDR so as to be ready for the next instruction.

Procedures are limited to 4K bytes in length. Furtllermore, instructions must be on halfword boundaries, so the

low-order bit of the PDR is ignored, as with the PBR.

P DR

r---, 10000proc . disp.O I

L ____________ _ _ _ _ J

o ⁴ 1 5

Procedure disglacements are a standard data type, and can reside in areas other than the PDR. For example, instructions which alter the normal sequential execution path (branc hing ins tructions) contain such displacements.

-15-

Program Facil i t ies

A single assembly may contain any number of procedures, each of which is coded as follows:

[EXTE:RN AL] PROe <name>

• •

• (procedure code)

• •

static data

The PROe statement specifies the start of a new procedure with the name indicated by <name>. Each procedure must have an identifying name. If the scope of the procedure i s to be external, that is, if the procedure name can be referenced by other assemblies (e. g., via V-constan ts) , the specification EXTER NAL must be included.

Following the PROe statement is up to 4K bytes of code and data which performs the computations assigned to this procedure. static data not used by other procedures should be placed at the end, including a LTORG statement to locate all literals. The PROC statement sets up a USING on GPR15 so that this data can be implicitly addressed.

NOTE that i t is not necessary to code a CSECT statement anywhere in the assembly.

Instructions on the MET 4B are similar to those on an IBM

System/360/37~

J.

Each instruction consists of an operation, which specifies some function to be performed upon olle or two QE~Lt:!!j}G2.

The op"l~a·tion i.s specified in an instruction by a four-, eight-, or twelve-bit operation code. This code specifies not only the basic function to be performed, but also certain modifiers, such as the data type of the operands.

Each different operation code is given a mnemonic for use in assembly language progrilmming (e. g. , "A" for add).

Program Facilities s pecify the data type and location of the operands (e.g.,

"ARH" for adding the cor.tents of two general-purpose registers). The next section describes the various types of operands and their referencE codes.

When programming in assembly language , instruction operands are specified in the ir logical order. The instruction descriptions in the document give the symbolic format for these operands. A gene ral-purpose register is shown symbolically as an "R", while an XBD address is shown symbolically as "D(X,B)". A symbolic operand may have a

"1" or a "2" suffix to denote which operand it is, or an

"S" oc "0" suffix to denote soucce and destination. Thus an instruction to add two cegisters is shown as:

ARR R1, R2

Vacious cestcictions ace placed upon to be operated upon directly by restcictions are outlined hece:

data types if they are an iostcuetion. These

In most cases, inte gers must be sixteen bi ts in length in ocdec to be opecated upon by inst.ructions. In a fe'.

cases they must be 32 bits long, such as for the dividend in a divide operation. These integers may reside in the general-purpose regi sters (and if so are given the reference code "R" ), within instructions as

immediate data (code "I"), or within a halfwocd in main stoce (code "H").

The restriction pl aced fractiolls.

XSD data can only r eside given the code "A". They a four-bit B field, and a

upon integecs also hold for

within instructions , consist of a four-bit twelve-bit D fi eld.

and are X field,

-17-

Program Facil i ties

Procedure displacements typically reside within the PDB control register or branching instructiollS, but they can al so be stored i n GPRs (code "B") or halfwords in main store (code "H"). Since they ' r equire only twelve bits, the high-order four bits of the register or half word are igllored and assumed to be zero.

Single byte data i tems can reside in the low- order eight bits of a GPB (code "R"), a ll inEtL-uction (coele "1") , or in any byte in main store (code "13"). When in main store, bytes do not necessarily have to be on 11alfword boundaries.

Character strings can only reside i n main store and are given the code "C". They may begin on any byte boundary and be of any l ength from 0 (t'he flY'!''!' string) up to 65, 535 bytes.

Certain errors can arise during the execution of a program, such as an a ttempt to divide by zero. The g-interpreter provides a means of informing the monitor and/or user of these e rrors, a means called 2£QfigQ£& fn&ff§. When an error is detected , execution of the instruction in question is aborted, and an implicit procedure call occurs. A detailed e xplanation is given in Chapter 12.

with each instru~tion

is given a list of occur and why.

description the possi ble

in the following chapters procedure checks that can

The Transfei Data Instruction

The purpose of this chapter is to serve as an introduction to the instruction set of the NETA 4B by describing a fundame ntal instruction, XFER. NOTE that the f ormat used to describe this instruction will be used throughout the remaining cha pters.

Each instruction description consists of four parts;

1. The name of the instruction.

2. The mnemonic used when coding the instruction, follo wed by the symbolic format of the operands.

3. A picture of the instruction as i t with its operand code (hexadecimal) Unused bits are indicated by a slash.

resides in main store, and operand fields.

4. All English-language description of the instruction.

transFER data

XFER 0, DO (DO) , S,DS (BS), ON (BN)

r---T---~----T----T---T----r_---T----T--- -,

I FF 1/ D 1/ S I BD I DO OS I BS I I BN I ON J

L _ _ _ _ _ _ _ ...L... ___ ..L _ __ ..L _ _ _ _ ...L ____ __ -....L __ . __ .l.. _ _ _ _ _ _ _ ..1. _ _ _ _ ..L.. _ _ _ _ _ _ -.J

o ¹² 1 6 20 3" 36 48 52 63

The XF8R instruction allows the programmer to transfer one or more halfwords of data from l ocations i ll one store to locations 1n the same or any other s tore. Data is transferred from the source store s pecified by S, starting a t the loca tion speci fi ed by DS (BS) , to the destination store s pecified by 0, s tarting at the location DO (80) The n umber of h!!lf}tQf:tl2 transfen'ed is

speci.fied by 'DN (BN) , '

Addresses and the length are computed by adding the contents of the base GPR (BD, 3S, or BN) to the i mmediate twelve-bit displacement (DO, DS, 0.[ ON ), forming a logical integer. If a base tield contains zero, GPRO is not added; the displacement is used by itself. The reader may have noticed that the addresses and length are

xno

data types without the index.

The stores which can be specifed in the three-bit D or S fi elds and their idiosyncracies are as fol lows:

code 0: Register file (R). Addresses are treated modulo 64, so that transferring wraps from register 63 to O.

-19-

code

The T~ansfe~ Data I ns truction 1; Local Store (LS) • Addresses

bei ng the current si ze of local wraps from location n-1 to O.

are treated modulo n, n s tore. Thus transferring

code 2: Main Store (MS) • The address must specify a halfword i t does not, an a lignment procedure c heck boundary. If

occurs.

code 3: Vector General Registez: file (VGR) . Addresses az:e tz:eated modulo 128, s o tha t 'trans ferring wraps from register 127 to

O. See chapter 15.2. for an explanation of the Vector

General z:egisters.

codes 4-7: unused . If specified as a source , zez:oes are obtained;

i f as a destination, the data fa lls off the face of the eart h.

If t he number of halfwords tc be transferred i s

zero ,

you wouldn't believe what happens.

I n order to simpli fy the specif icat ion of s tore types, regis t ers, etc., a macro i s pz:ovided which genez:ates eq uates for them. This macz:o i s called "M4BEQUS" and should be inclUded at the end of al l META 4B assembl ies. A lis ting of t he generated code can be found in Appendix 1.

Examples:

xrER R, RS, aS,PLACE,3

Three halfwoz:ds az:e tz:ansfez:red fz:om main store, s tarting at PLACE, into GPRS-7.

XPER LS, 256,LS,128,128

128 half words are transferred from local s toz:e locations 128-255 to locations 256-383.

XfEi'! LS,O (ll2) ,VGR,VGDIAL1,0 (ll3)

The number of vector General dial registers speci f ied by the contents of GPH) is transfe'rz:ed into local s tore staz:ting at t he location speci fied by the contents of GPR2.

XFEH R, R8,R, DBR,1

The DBR i s placed into GPRB.

NOTE that XFER is not intended for transferz:ing single among the general-furpose registers a nd mai n store . o thez:, more powez:f ul, instructions for this puz:pose, described in later chapters.

data i tems There are which az:e

B~anchillg Inst~uctions

A class of operations known as branching operations a~e p~ovided to allow the p~og~amme~ to make decisions and alte~

the flow of control th~ough his procedu~es. B~anching

de6isions a~e cont~olled by the Condition Flag Register.

The CFR, control registe~ 18, p~ovides the means for making decisions in a procedure. ~t centains eight condition bits which are set by certain instructions in order to inform the prog.['a mmer of the ~esults of the instruction. For example,

compa~e 0Fe~ations set the CFR to ~eflect whether the first

ope~and was less than, equal to, o~ g~eate~ than the second

ope~and.

CFR

r---T-T---, J flags J51000000001

L _______ ~_~ ________ J

o ^{7 8} 15

Whenever the CFR is modified by an instruction, all bits are initially set to ze~o. Next, one of the flags (bits 0-6) is set to reflect the results of the operation. (In the case of compares, bit 0 is set on if the operands a~e equal, bit 1 i f the fi~st operand is greater, or bit 2 if i t is less than the second operand.) Finally. the summar y flag, bit 7, is set to reflect the most important condition. (For compares, i t is set off if the ope~ands are unequal. or on if t hey are equal.) The pu~pose of some branching instructions is to test the CPU and either branch or not, depending upon the test.

-21-

Unconditional B~anching Instructions

No OPera tion

NOP 0

r---r---, I OD 1000000001

L ________ ~ ________ ~

o ^{8 15}

NOP peL-forms no operation whatsoeve~.

with the next seguential i ntruction.

Branch

B label

Ir- - - -. - -- - - -, 4 J proc. disp.Ol

L _ _ _ _ ~ _ _ _ _ _ _ _ _ _ ___ ~

o ^{4 15}

Execution continues

A branch i s taken to the speci fied label ~egardless of the setting of the CFR. Such a branch i s called

gn£QnAiliQDI!.

Branch via Regis ter

BR R

r---T----'

I 0 FC I H J

~ _ _ _ _ _ _ _ _ _ _ __ ^~ _ _ _ _ J

o 1 Z 1 5

Branch via Halfwqrd [Note t he mnemonic

1

BH D(X, B)

r---T----T----r---,

I 9 FC I X I B J D I

l ____________ i _ _ _ _ L -_ _ ^~ _ _ _ _ _ _ _ _ _ _ _ _ J

o ^{12 16 20 31}

Unconditional Branching Instructions

An unconditional branch is taken. For BR, the procedure displacement i s obtained from the GPR specifed by the operand.

For BH, it is obtained from the halfword at the main store address speci fied. In both cases, the high-order four bits of the operand are ignored.

An alignment procedure check occurs during BH if the main store address is odd.

-23-

conditional Branching Instructions

Branch True

BT label

r----T----, I 3 Iproc. disp.O J

L ____ ^~ _____ _______ j

o

•

¹⁵

Branch False

OF label

r----T---, 2 jproc. di sp.O j

L __ __ ^~ _____________ J

o

•

^{I 5}

If the s ummary f lag is on off and the operation specifed label. Otherwise

and the operation is is EF, and branch no b~anch is taken.

Branch on Condition Flag register BCF mask, label

r---T---T-------,

J 5D j mask jOOOOproc. dlsp.Oj

l _ _ _ _ . ___ ..l. _ _ . ______ . ..L ________________ J

o ^{8 16 31}

BT, or i f i t is is taken to the

The eight-bit masK is used to select bits in the CF'R. I f ~.!!y

selected bits are on, a branch is taken to the label.

Otherwise, no branch is taken. Each bit in the mask corresponds to a bit in the CPR. Wherever a one bit appears ill the mask, the corresponding CFR bit is selected for testing.

It is not usually necessary for t he programmer to specify a mask on a BCF inst.ruction. Instead, "extended mnemonics"

are prov ided which allow the user to i gool:e the mask. Examples al:e BE (Bl:anch Egual) and BNG (Bl:anch Not Gl:eater). Extended mnemonics are described with the I:elevant instructions, and are also l istE,d in 1\ ppendix 2a.

Case Instt:uction

CASE R.D (X,Il)

r---T----.----T----T---,

I 6D 1 R I X 1 B I D I

L ________ ^~ ____ ^~ ___ - k ____ L - ___________ J

o 6 12 16 20 31

The main store address specifies a table of halfwords containing procedure displacements. The n 'th halfword is selected, and a branch is taken to the procedure displacement within this halfword. As usual, the high-order four bits are ignored. The value of n is the logical integer in the GPR specified by H, and ranges frem 0 on up.

An alignment procedure check cccurs if the table address is odd.

In order (Define provided.

to simplify the generation of CASE tables, the DCPD Constant Procedure Displacements) statement is

It is coded as follows:

(label] DCPD labell,labe12, ••• ,labeln

A table of n procedure displacements is generated.

-25-

-~

Unary Data Moving Instructions

Set to Zero Register

SZR R

r---T----' 1 _l _ _ _ _ _ _ _ _ _ _ _ 0 FO ^~ 1 ____ R J I

o 12 15

Set to Zero Halfword

SZfI D(X,B)

r---T----T----r---,

1 9 PO 1 X 1 B I D I

l ____________ ~ ____ ~ ___ ~ __ __________ ~

o 12 16 20 31

These two instructions cause their operand to be set to zero.

For SZR, the speci f ied GPR is set to zero, while for SZIi, the halfword at the main, store addres~ is zeroed.

An alignment procedure check occurs during SZH if the address is odd.

Set to One Register

SO R R

r---~---,

I ' OF'1 .1 R 1

L ____________ ..L. ____ J

o ^{12 15}

Set to One Halfword SOH D (X, B)

r------y----T----r------,

9 P1 1 X 1 B D 1

L ____________ ..L. _ _ _ _ ^~ _ ___ ..L. ____________ J

o ^{12 16 20 31}

Unary Data Moving ~nstructions

These two instructions cause t heir operand to be set to the integer 1. For SOH, the specifed GPR i s set to 1, while for SOH, the main store halfword is set to 1.

An alignment procedure check cccurs during SOH i f the address is odd.

- 27-