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
| Download | |
| Open PDF In Browser | View PDF |
MEMORANDUM
TO:
D,~;c;k
Clayton
Jeg-a. A:tulpragasarn
DATE:
September 13, 1974
FROM:
Craig Mudge
DEPT:
llEngineering
EXT:
SUBJ:
5064
LOC:
5-5
Summary of II/VAX Architecture.
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 1 1 / 4 4 '
9/27
cc:
1
'....
"
'\,.
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
..
..
~
Craig Mudge
9/13/74
ll/VAX ARCHlrrECTURE
SUMMARY OF
I
~
DESIGN GOALS
1.
Implementable over a range.
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.
A substantial increase in virtual address.
2.
Ito
4'
. 1/tJ~
/
~J1
~tv»"
The new address length should be between 2{and 32" bits,
not just an extra bit or two over today's 16 bits.;-
··I_~
VJ v
Use known art.
3.
Segmentation, whose strengths and limitations are known,
should be used. New methods,. domains and capabilities, for example, shoul.dnot be explored.
Compatible wi th today' s PDP-II.
4.
··~4
\0. .
Existing user programs must run unmodified.
Existing user subroutines must' be callable from new
programs which exploit extendedaddr..essing.
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
code·· is' unusually strong.
'1 ..
f
..
5.
.
No loss of performance.
a),
b)
6.
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.
Address translation
No more time added above conventional dynamic address
translation schemes.
Flexible name space (program space)· management.
The
a)
b)
c)
d)
following programming needs must be met:
Program modularity.
Varying-size data structure~ ..
Protection.
Sharing, without the conflict which derives from the
a-segment KTll.
:',~
~i
•
"
Craig Mudge
9/13/74
-2-
II. THE II/VAX ARCHITECTURE
1.
Extended addresses.
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
c
16
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.
RiX.
..
.
The 16'"bit register extension ofregis~er Ri is called
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~ invocation and return.
, '.
. The virtual address space
presented'tothepr~ranuner
is
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, 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(:ef allocation in the physical space.
b)
The page size dictated by the KTll is 4K words, generally accepted to be too large~
32~bit index words and 32-bit'indirect addresses in
memory are not provided.
c)
The only cneof cortcernisthe KT11-derived,page size.
Operating systems l>lhich support 'll/VAX on large systems will require 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".
:'
,,,tea'!:" ;TA.,-e~,",
' ":':',
~,~4-ble hl).$ ..~·.n"I'~I~)-
.
.'I':c
,.-<
,
,0;
';.l:.
.
..
,
.,'
"",,',,';>
".':"
+~b':e?,eW\.+Yre' ".
C-.rt.-\,"s+
[ .P:B ..... ·.
':
~_!:..;,:~!ii,~
·
r.:, (:-~ L-
,
AD D t( t:-~.) 5
" f( 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 Register 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 i t is ,.specifically designed to shift the cost burden
onto theKTX option itself, wherever possible.
/br.
,I
\,;.,
.:,:' ',?'
'.b1<
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c041 52.342996, 2008/05/07-21:37:19 Producer : Adobe Acrobat 9.0 Paper Capture Plug-in Modify Date : 2018:03:23 18:24:15-07:00 Create Date : 2018:03:23 18:24:15-07:00 Metadata Date : 2018:03:23 18:24:15-07:00 Format : application/pdf Document ID : uuid:9c4851fa-e1ca-e04b-9d17-358cfbe57f5b Instance ID : uuid:3b05939b-3e08-7d4d-9f73-dfc0bbde22c3 Page Layout : SinglePage Page Mode : UseNone Page Count : 8EXIF Metadata provided by EXIF.tools