740913_Summary_Of_11_VAX_Architecture 740913 Summary Of 11 VAX Architecture

User Manual: 740913_Summary_Of_11_VAX_Architecture

Open the PDF directly: View PDF .
Page Count: 8

1

' .... '\,.

"

TO:

D,~;c;k

Clayton

Jeg-a.

A:tulpragasarn

MEMORANDUM

DATE:

September

13,

1974

FROM:

Craig

Mudge

DEPT:

llEngineering

EXT:

5064

LOC:

5-5

SUBJ: Summary

of

II/VAX

Architecture.

cc:

Enclosed

is

the

report

you

requested.

Detailed

schedule

forVAX.isthe

followi'1g:

Overall

Summary

9/13

Architectural

Spec

9/27

Software

&

other

Implications

10/15

Effect

of

Implementation

on

11/44'

9/27

En~ineerinl~Sir~

..

•

·Go~don

Bel

.

Roger

Cady

Dick

Clayton,

Bruce

Delagi

Bill

Denuner

Robin

Frith

Andy

Knowles

Phil

Laut

Al

Sharon

Steve

Teicher

DRAGON

Engrs.

Sas

Durvasula

Bab

Giggi

Bob

Gray

Kent

Griggs

Dave

Ives

John

Levy

Product

Line

Managers

Irwin"

Jacobs

Ed

Kramer

Bill

Long

Julius

Marcus

Brad

Vachon

Software

Ron

Brender

Dave

Cutler

Frank

Hassett

~ete

V~n

Roekens

Garth

Wolfendale

Den6y

Pavlock

..

~

..

SUMMARY OF

ll/VAX

ARCHlrrECTURE

I

~

DESIGN

GOALS

1.

Implementable

over

a

range.

Craig

Mudge

9/13/74

The

architecture

must

be

efficiently

implementable

over

a

cost

and

performance

range.

The

range

should

span

from

an

Il/OS-type-cost

machine

to

an

11/55-successor-type-performance

maohine.

In

addition

the

hooks

necessary

on

the

Basic

Machine

should

be

minimal

-

no

more

than

a few

IC's.

The

option

itself

may

exceed

the

current

KT

in

cost.

2.

A

substantial

increase

in

virtual

address.

.

1/tJ~

/

~J1

Ito

~tv»"

The

new

address

length

should

be

between

2{and

32"

bits,

··I_~

not

just

an

extra

bit

or

two

over

today's

16

bits.;-

4'

VJ

v

3.

Use known

art.

Segmentation,

whose

strengths

and

limitations

are

known,

should

be

used.

New

methods,.

domains

and

capabilities,

for

ex-

ample,

shoul.dnot

be

explored.

4.

Compatible

wi

th

today'

s

PDP-II.

··~4

'1

.. \0. .

Existing

user

programs

must

run

unmodified.

Existing

user

subroutines

must'

be

callable

from

new

programs

which

exploit

extendedaddr

..

essing.

f . . .

code··

is'

c)

Existing

system

code,

except

for

the

code

that

loads

the,I{Tll

mapping

registers,

must

,ruDunmodified.

d) The'

scheme

must

be

compatible

with

the

KTllmemory

management

unit.

The

goal

0.£

running

most

system

code

as

well

as·all

user

unusually

strong.

5.

No

loss

of

performance.

a),

I...;stream

Within

a

loop,

the

number

of

I-stream

bits

passed

must

be

no

more

than

in

today's

11.

Extra

I-stream

bits

for

lo~p

set·

up

are

allowed.

b)

Address

translation

No

more

time

added

above

conventional

dynamic

address

translation

schemes.

6.

Flexible

name

space

(program

space)·

management.

The

following

programming

needs

must

be

met:

a)

Program

modularity.

b)

Varying-size

data

structure~

..

c)

Protection.

d)

Sharing,

without

the

conflict

which

derives

from

the

a-segment

KTll.

II.

THE

II/VAX

ARCHITECTURE

1.

Extended

addresses.

:',~

~

i • "

-2-

Craig

Mudge

9/13/74

In

toda.y"s

11 a

processor

generates

A.16-bit

virtual

address.

A

regieteralways

takes

part

in

thiS,

~ddresscalc\11at

tion.

For

example,

.

in

the

instruction

CLR'

(R4) + ,

thellddress

mode

is

2

(auto-increment)

and

the

contents.ofR4is

the

operand

address.

In

MOVB,

-(SP),

the

source

operand

addressing

iaby

mode

6,

register1.and

the

destination

operand

addressing

is

by

mode

4,

register

6.

'

ll/VAX

exploits

this

fact

that

a

general

register

always

takes

part

in

address

formation

and

simply

extends.each

register

to

32

bits.

The

'32-bit

address

has

two

components:

.

16

16

c d

c=chapter

number

d=

displacement

with

chapter

,A

single

chapter

is

exactly

equivalent

in

size:

and

structure

to

,the '64K

bytes

of

today

's

·11

virtual

address

space.

The

16'"bit

register

extension

ofregis~er

Ri

is

called

RiX.

The

definition

of.

the

·address

mode

is

as

in

today's

11.·

..

.

Now

consider

the

11/VAXinstructions

!leeded

to

manipulate

32-bitaddresses.

The

instructionsto·manipulatethed

partef

the

acldress

(c,

d)

are

e;)Cactly

today's

11

instructions.

New

in

....

structions

to

l.oad

and

store

RiX,

i.e.,

lead

and

store

chapter

number,

have

been

added.

There

are·alsonew

instructions

to

do

inter

chapter

jwnps .

(JMPX)

,

andJSRX

and

RTSX

torsubreutin~

invo-

cation

and

return.

,

'.

. The

virtual

address

space

presented'tothepr~ranuner

is

a

classic

segme·nted1.address

spac~:2l6

chapters

of

21

bytes.

The. two

."

componellt

.addressingwillbe

exploited

by.

programmers

:

logically

related

entities

will

be

grouped.and

asSj.gned

separate

chapter

numbers.

For

example,

a

separate

ohapt.er

number

could

be

assigned

to

eachofa).a

matrix,

b)a

row

of

a

large

matrix,

c) a

large

main .pro<iram, d)

a.,.

large

subroutine,

and

·e)

a

group

of

sub-

l;'outinese.g.

, .

the

FORTRN

object

time

system.

: The

chapter

is

thus

the

logica~

unit

of

allocation'

for'

modularity,

sharing,

and

protection

in

the

programmer's

logical

address

space.

Address

specification

is'

efficient.

Fu.l132-bit

addresses

will

appear

in

the

instruction

stream

.much

less

frequently

than

16-bit

addresses"

which,

in

turn,

appear

much

less

frequently

than

3-bit

register

addresses

(specifying

address-holding

registers).

1.

I

have

used·

tile

term

chapter

instead

of

segmentbecauseKTll

documentation'has'

somet.imes

used

the

terms

segment

and

page

inter-

i

changeably.

I

~

,j

" :

;;1

'.,J

, .

-3-

2.

Mapping.

,

;,

,,'

"~I

; i

;":;~~"l;r:;"'~f{\i',11i:;'::

1(;

'ir;I'!:ihf

::,:":,

, •

,~

....

' I

cr~i(iMUdge

9/13/74

Every

address

generated

by

the

processor

is

mapped

to

a

physical

address.

Map

tables

in

memory

define

themappinq

fo~,:"

eachProces,

s ,dr,,',

"",

t,ll,Sk

'1',

,known

,to

the.

oper,

a,tin",."

9"

'.,Y,',

S"",t,e".,'

'..

se"

,e,,'

Fig", ut,:e

1.

su,ppose

;ro:c,essJt'1!xecutes

the,

l.nstru,

ction

INC'~"',(,R3)

a,

nd,

that.

,'"

R3

holds

I

C~4

,'CI-Albo?].

Then

Figure

2

shows'tbe

address

. '

translation.

This

address

translation

takes

4

memory'references.

'Be~

'cause

it

is

8

'8&1':i'41

,

delay

whic:hmust,occur'

before

the

processor

can

issue

a

memory

reference,

it

must

be

speededup(to

about

150

'nsec.

,on

an,

ll/44

type

of

machine)

• Thus a

"DAT'

box"

for

dynamic

address

translat!:on

will

be

used

in

each

implementation

of

II/VAX.

"

This

will

hold'

a

subset

of

the

map

table

in

fast

registers.

The

90a10£

a

OAT

box

is

to

make

this

subset

the

most

f,requently

used

parts

of

the

total

map'. '

A

range

of

implementation

of

DAT

is

possible:

from a

one-

register

implementation

(slow,

cheap-

11/05)

toone

that

has

many:

:-egisters,

associa.tive

look-up,

and

elaborate

,rep;acement

ail""l.\j~¢~~+h~

~

(fast,

expensl.ve

-11/95)

such

as

the

"translatl.on

buffer

'

memory"

on

the

<51370.

III.

COi-1PATIBILITY.",

,

To

,ensure

that

user

programs

will

run

unmodified,a

spare

PS,

bit,

PS

<08">,

is

used

to

indicate

X

or

non-X mode. A

program

written

for

today's

machine

does

not

know

about

RiX.

Themode

.

bit

when

zero

forces

the

program

to

'run

as

it

was

in£ended,

i.e.,

as

a

one-chapter

program,

by

using

R7X

,(PCX)as

the

value

,for

RlX

through

R6X.

,Witb

this

mechanism

an

extended

pJ;

oq

ram

may

calla

"16-bit"

subroutine

by

a

normal

JSR.as

feilews.

Thecal'l

itself

is

issued

from

a

'chapter

whose

'page

table

is

iden'ticalwi

th

that

required

by

the

subr,outine.

'

,This

is·

'possiblesin(:e<by'definitionthe

subrout~ne

was

written

to

exist

in

a

16-bit

VAS,'

and

there

'is

horestricti()n

against

different

chapters'

having

.identiealpages

•.

Note

that

with

a

normalJSR

the

PCX

is

not

stacked

and

the

called

'prClq:rapl,

therefore,

faces

no

ambiguity.

The

ll/VAX

working

notes

(Versionl,

5/2/74)

gives

full

details

of

how

,the

X-mode

bit,

together,with

the

general

mapping

concept

works

for

all

calls,

including

examples

with

the

appro-

priate

Ulinkinq"cpde"

(a

couple

of

instructions),

where

necessary.

To

ensure'that

our

compatibility

goals'

for"system.'

programs

are',

met,

another

spare

bitlPS

~09")

is

used

to

control

the

stack-

ing

and

unstackin90f

PCX,on

interrupts

and

RTI,

return

from

inter-

upt.

All

interru

ts

are

returned

to

Process

.

,eha

ter

• The

interrupt

vector

here,

~n

part~cular

PS

fl9;',

controls

the

stacking

and

unstacking

ofPCX.

· ;

I.,

-4-

,

Craig

Mudge'

9/13/74

,This

allows

,the

placing

of

a

current

16-bit

supervisor

in

P

nCo;

"

or

allows

a

SUi:lersupervisor"

os

X}

to

reside

he:re,3'~(:t

forward

iI!t~r-'

ruptions

tose'V'8t'al

different

"16-bi

til

Supervi,sor.sexisting'

s.1mul-'

taneous

Iy

~n

,different

individual

chapters.

..

Refere.nceis

again

made

to

the

Workin9 NQtes.

for

full

de... : '

tails

of

how

this

actually.works.

Note

that

Veraion

2

of

the'

'

Working

Notes.eliminatesa

deficiency/limitation'

in

this

area,

,

which

had

beet:lcaused

by

attempting

to

get

by

with

a

single

mode

bit

•.

Version,2recoqnizes

that

addinqa

second

mode

bit

to

re-

move

that

deficiency

is

a

trade-off

with

a

high

payback.

IV.

WEAKNESSES

...

t k e (

hct,f'+-

e (

S('

h

t'

Ih

e

..1.

"""

,-v

I o( f

H'

f

,.

$

c!

,If

we

were

det':S'ning

PDP

next,

i.e.,

'designing

the

size'

and

structure

of

a

32-

it

virtual

address

space

from

scratch,

we

would

not

propose

a,classicsegmentation

scheme,

but

the

segment

size

would

be

24,

not

16.

Other

less-than-ideal

proper-

ties

of

the

chapter

scheme 9

which

derive

from

our

strict

compati-

bility

goal

are:

/

a)

Access

rights

appear

at

two

levels

-

at

the

chapter

level

and

the

page,

level

-

the

latter,

is

not

only

re-

dundant,

but

is

the

wrong

place

because

a

page

is

the

,unit

(>f

allocation

in

the

physical

space.

b) The

page

size

dictated

by

the

KTll

is

4K

words,

gen-

erally

accepted

to

be

too

large~

c)

32~bit

index

words

and

32-bit'indirect

addresses

in

memory

are

not

provided.

The

only

cneof

cortcernisthe

KT11-derived,page

size.

Operating

systems

l>lhich

support

'll/VAX

on

large

systems

will

re-

quire

hardware

assistance

for

physical

memory

mangement~

-In

Wilt

"

case

the

page

size

should

be

changed.

,The

RSXII-Dgroup

claim.

that

that

partoftheKT!l

compatibility

could

be

sacrificed

at

little

cost.

The

other

part

ofKTll

compatibility

is

the

Kernel/

,user

privilege

structure~

We

could

not

change

tha~withouta

large

rewriting

effort.

We

are

currently

getting'a

new

set

of

figures

to

quantify

"little"

and

"large".

,

".':"

, 0;

+~b':e?,eW\.+Yre'

".

C-.rt.-\,"s+

[

.P:B

.....

·.

,,,tea'!:"

;

TA.,-e~,",

'

":':',

~,~4-ble

.

hl).$

..

~·.n"I'~I~)-

.'I':c

';.l:.

.

..

,

.,'

,.-<

"",,',,';>

':

~_!:..;,:~!ii,~

· ,

r.:,

(:-~

L-

AD

D

t(

t:-~.)

5 "

f<t\-

1'j

S

\.,

A,''')

0 N

t::.>(

1\""")"

L e

.:rCA..;

~'/1}/7(/..

'9/13,174

possible

Implementation

on a Medium

Scale

11

•..

It

will

,be

noted

that

each

Rix

corresponds

to

a

single

chapter

whichwill'each

have

a

set

of

Page

~ables'e6rresponding

to

it,

identic.'1

in

form

to

todays

set

of

KTll

registe,rs.

'.

Therefore

an

implementation

could

be

such

that

the

KTX

option

itself

would

hold

RiX

and

a

limited

set

of

KT'type

Regis-

ter

sets.

Instead

of

6

sets

,for

Kernel/Supervisor/User

times

I/O

space,

we

would

have

at

most

16

sets

(probably

only

9)

which

w9uld.be

Kernel/User

times

one

for

each

of

the

RiX. (9

if

the

Kernel

was

essentially

single

chapter)

•

The

"hooks"

required

can

be

seen

to

be

only

the

provision

of

the

Register

used

on

each

memory

reference

(4

lines:

8

registers

plus

Kernel/user).

and

the

mechanism

for

setting

R!X

on

a Load

Address

instruction.

The

latter

hook

can

also

be

made

simple

if

integrated

at

initial

design

timer

With

these.

hooks

accessing

the

required

page

table

is

clearly'ofthesaxne

order

of

speed

as,

for

the

present

KT.

Further"

replacement

of' -.the

page

tables

could

be

driven

from

the

KTX

itself

and

Tllould ,run

"blinding

fast"

on

a

high

bandwidth

32-bit

wide

memory

bus,

as

loading/storing·

would

be

.f:rom/to

contiguous

memory

locations.

In

particular,

the.

DRAGON

bus

would

be

appropriate.

The

extra.costof

the

hooks

on

the

basic

DRAGON

is

estimated

to

be

<$25,

if

it

is

,.specifically

designed

to

shift

the

cost

burden

onto

theKTX

option

itself,

wherever

possible.

/br.

,I

\,;.,

.:,:'

',?'

'.b1<