This improved version of the HTML fixes some typos
and adds markup that is missing even
in the PDF and PS renditions. It was kindly supplied by Naoki Hamada.
I am responsible for remaining problems.
--DMR
This memorandum describes the VAX-11/780 hardware and the UNIX operating
system and the C programming language software implementation, records some
observations on program portability, and speculates ways in which the
operating system overhead can be significantly reduced. The authors conclude
that the VAX-11/780 provides and excellent hardware environment for running
UNIX and C software.
このメモは
VAX-11/780
ハードウェアおよび
UNIX
オペレーティング・システムについて記述します。
さらにCプログラミング言語ソフトウェアの実装について述べ、
プログラムの移植性についていくつかの観察結果を報告し、
オペレーティング・システム・オーバーヘッドを
大幅に縮小できる方法を考察します。
著者は
VAX-11/780
が
UNIX
および
Cソフトウェアを実行するための
優れたハードウェア環境を提供すると結論を下します。
The VAX-11/780 [1] is a new, general-purpose, stored-program electronic
digital computer manufactured by Digital Equipment Corporation.
At minicomputer
prices it provides addresses and data which are 32 bits wide; the traditional
minicomputer address space bound of 64K is gone. This memorandum describes the
VAX-11/780 and the implementation of a UNIX operating system and complete user
environment for it. Section 2 contains an overview suitable for general
consumption; details normally of interest only to devotees of computer system
architecture appear in Section 3.
The authors comment on software portability in
Section 4.
VAX-11/780 [1]
は
Digital Equipment Corporation
によって製造された
新しいストアドプログラム方式の
汎用電子ディジタル・コンピューターです。
ミニコンピューターの価格で、
32ビット幅のアドレスおよびデータを提供します;
64Kに拘束された従来のミニコンピューターのアドレス空間はなくなりました。
このメモは
VAX-11/780
およびそのための
UNIX
オペレーティング・システムおよび完全なユーザ環境の実装について記述します。
セクション２では
一般的な消費者向けの概観を含んでいます。
通常コンピューターのシステム・アーキテクチャーの愛好者にのみが
興味のあるような詳細は
セクション３に現われます。
セクション４では
ソフトウェアの移植性に関して著者がコメントします。
Environment. A user of UNIX and C software on the PDP-11 will find
that the VAX-11/780 provides a very similar environment. There are no apparent
differences in the command language or the vast majority of programs which are
customarily invoked directly from the shell.
A casual user probably will not be
able to distinguish the hardware, except by issuing the command "who am i"
(which identifies the hardware and the current user) or by noting that one of
the columns printed by the process status command ps is in hexadecimal
rather than octal. The C language programmer will find that int,
long, and pointer data types all occupy 4 bytes
(a short still occupies 2
bytes), and that a long has its two halves stored in
a different order on
the PDP-11 than on the VAX-11. Characters still suffer sign extension when
converted to longer integer types, but one may use the declaration unsigned
char.
環境 --
PDP-11
で動作する
UNIX
および C ソフトウェアのユーザには、
VAX-11/780
が非常に良く似たの環境を提供することが分かるでしょう。
コマンド言語、あるいはシェルから
慣習的に直接起動される大多数のプログラムで明白な違いはありません。
一時的なユーザには、
恐らく
(それはハードウェアおよび現在のユーザを識別する)
"who am i"
コマンドを実行する場合、
あるいはプロセス・ステータス・コマンド
ps
の出力のカラムの１つが8進法ではなく16進法に表示される以外は、
ハードウェアを識別することができないでしょう。
C言語プログラマは
int、
long
およびポインター・データ・タイプがすべて4バイト占めること
(short ではまだ2バイトを占めます)、
また
VAX-11
では
long
のその２つの半分が
PDP-11
とは異なる順に格納されることを知るでしょう。
より長い整数タイプに変換された時、
文字はまだサイン拡張を受けますが、
unsigned char
の宣言を使用する方法もあります。
Hardware. The VAX-11 is a follow-on computer to the PDP-11. The
architecture seen by the user-mode assembly-language programmer of a VAX-11 is
"culturally compatible" with the PDP-11. Specific details differ, but a
programmer familiar with the PDP-11 can quickly understand the differences.
The
VAX-11 provides UNIBUS and MASSBUS interfaces and uses the same input/output
peripheral devices as a PDP-11.
ハードウェア --
VAX-11
は
PDP-11
の後継コンピューターです。
VAX-11
のユーザー・モードでのアセンブリ言語プログラマには、
アーキテクチャーは
PDP-11
と「文化的に互換」に見えます。
特定の詳細は異なりますが、
PDP-11
に精通しているプログラマにはその違いを素早く理解することができます。
VAX-11
は
UNIBUS
と
MASSBUS
のインターフェースを提供し、
PDP-11と同じように入出力の周辺装置を使用します。
Significant new features of the VAX-1l include an extended virtual address
space, intelligent console, and dramatically improved physical packaging. The
address space of a process is divided into a few gigantic segments.
Each segment
is further divided into a large number of small pages. Sufficient hardware
exists to make demand paging a viable memory management strategy. All console
functions are handled by an LSI-11 microcomputer through a standard ASCII
terminal. The terminal may be remotely located from the processor
and can still
halt, boot, or diagnose the VAX-11. The mechanical and physical design of the
VAX-11/780 is well done. The processor contains no sliding drawers or moving
cables. All parts are easily accessible for servicing. Adequate airflow is
maintained even under maintenance conditions.
VAX-1l
の顕著な新しい特徴には
拡張仮想のアドレス空間、
知的なコンソール
および劇的に改善された物理的なパッケージングが含まれています。
プロセスのアドレス空間は少数の巨大なセグメントに分割されます。
各セグメントさらに多くの小さなページに分割されます。
要求時ページングを実行可能なメモリ管理を行うための
十分なハードウェアが存在します。
コンソール機能はすべて標準のASCIIターミナルを通って
LSI-11
マイクロコンピュータによって扱われます。
ターミナルはプロセッサーから離れた場所に位置することもでき、
今までどおり
VAX-11
を停止／起動／診断することができます。
VAX-11/780
の機械的・物理的なデザインは上手に行われています。
プロセッサーは
スライドする引き出しには収められていませんし、
ケーブルが動くこともありません。
サービスには部品が全て容易にアクセスできます。
メンテナンス時にも適切なエアーフローが維持されます。
Configuration. The actual configuration purchased by Department 1353
is:
コンフィグレーション --
1353部門によって購入された実際のコンフィグレーションは次のとおりです:
VAX-11/780 cpu 0.5 megabytes memory with battery backup floating-point accelerator 12Kbyte user-writeable control store UNIBUS adaptor with DZ11 (8 RS-232C lines) MASSBUS adaptor with TE16 tape drive (800/1600 bpi) MASSBUS adaptor with two RP06 disk spindles (176M bytes per spindle) additional BA11KE UNIBUS box
Software. We have implemented a UNIX operating system [2] and complete
user software environment on the VAX-11/780. The operating system is Research
version 7 as of April 15, 1978. The environment includes the Bourne shell, C
compiler, code improver c2, assembler, loader, debugger, standard I/O
subroutine library libS, C subroutine library libc, source code
control system SCCS, nroff/troff and more than 130 commands.
Maintenance
programs for file system checking, bootstrapping, and physical disk pack
handling have also been implemented.
ソフトウェア
私たちは
VAX-11/780の上に
UNIX
オペレーティング・システム
[2]
および
完全なユーザ・ソフトウェア環境を実装しました。
オペレーティング・システムは
Version 7
の1978年4月15日版です。
環境は
Bourne shell、
Cコンパイラー、
code improver c2、
アセンブラー、
ローダー、
デバッガ、
標準の I/O サブルーチン・ライブラリー libS、
C サブルーチン・ライブラリー libc、
ソース・コード・コントロールシステム SCCS、
nroff/troff
および130を越えるコマンド>を含んでいます。
ファイル・システムのチェック、
ブートストラップ、
および物理的なディスクパックの操作のための
メンテナンスプログラムも実装されました。
We began with the C language code of Research version 7 of the UNIX operating
system, and a PDP-11/45 running UNIX as a bootstrap machine. Creating a C
compiler which produced VAX-11 native-mode assembly code was the first task.
The
code generator portion of the portable C compiler was rewritten to do this. An
assembler and loader, based on similar code for the Interdata 8/32, completed
the basic support software. Existing PDP-11/70 device drivers for disk, tape,
and terminal communication lines were adapted to the VAX-11/780. Assembly
language interfaces (trap handlers, hardware initialization, etc.) were
completely rewritten.
We then created magnetic tapes in the proper format for an
initial file system and for deadstart load, and physically carried these tapes
from the PDP-11/45 to the VAX-11/780.
私たちは
UNIX
オペレーティング・システムの
Version 7
のC言語コードおよびブートストラップ・マシンとして、
UNIX
が稼働する
PDP-11/45
から始めました。
VAX-11
ネイティブモードのアセンブリー・コードを生成する
C コンパイラーの作成が最初の仕事でした。
そのために
portable C compiler
のコード・ジェネレーター部分は書き直されました。
Interdata 8/32
と同様のコードを基したアセンブラーとローダー、
および基礎的なサポート・ソフトウェアも完成しました。
PDP-11/70
に対応する既存のディスク、テープ
およびターミナルのコミュニケーション・ライン用のデバイス・ドライバは、
VAX-11/780
向けに修正されました。
(トラップ・ハンドラーやハードウェアの初期化など)
アセンブリ言語によるインターフェースは完全に書き直されました。
その後、
ファイルシステムの初期化と
cold boot (deadstart load)
のため、
私たちは適切なフォーマットで磁気テープを作成し、
PDP-11/45
から
VAX-11/780
まで物理的にこれらのテープを運びました。
Work on the C compiler began in mid-December 1977. The hardware arrived on
March 3. We held a party on May 19 to celebrate successful multiuser operation
of the system.
C コンパイラーの作業は1977年12月中旬に始まりました。
ハードウェアは3月3日に到着しました。
私たちは
システムのマルチユーザによる操作に成功したことを
祝うために5月19日にパーティーを開催しました。
Performance. Identical documents were formatted by nroff on our
VAX-11/780 and on a PDP-11/70 running Research version 7 UNIX;
both systems used
RP06 disks. Identical C programs were compiled and assembled on the VAX-11/780
and on the PDP-11/70. As reported by the time command, the results
(converted to seconds) were:
| nroff -ms -e -T450-12 ios.r >/dev/null | |||
| real | user | sys | |
| VAX-11/780 | 47.0 | 28.6 | 8.7 |
| PDP-11/70 | 54.0 | 36.9 | 7.9 |
| cc -c -O pftn.c | |||
| real | user | sys | |
| PDP-11/70 (Ritchie compiler) | 86.0 | 43.5 | 11.8 |
| VAX-11/780 (portable compiler) | 82.0 | 64.0 | 10.5 |
| PDP-11/70 (portable compiler | 153.0 | 114.6 | 16.6 |
| for Interdata 8/32) | |||
From the statistics on nroff one should conclude that, based on
user-mode CPU time, the VAX-11/780 can execute the code produced by the VAX-11 C
compiler approximately 22% faster than the PDP-11/70 an execute the code
produced by the PDP-11 C compiler. This is a measure of the combined power of
the hardware and efficiency of the code generated by the compiler. Except as an
upper limit, the figures give no indication as to the throughput, response time,
or efficiency of the operating system. The differences in real time and system
time between the VAX-11/780 and the PDP-11/70 are not significant.
The times given for compilation of the file pftn.c are an attempt at a
"black box" comparison of apples and oranges. The black box is any program
(compiler) which takes C language input and produces executable instructions.
The black-box comparison is that the current VAX-11 C compiler running on the
VAX-11/780 and compiling code for the VAX-11 requires 49% more user-mode CPU
time than the current PDP-11 C compiler running on the PDP-11/70 and compiling
code for the PDP-11. The apples and oranges aspect arises because the two
compilers, while equivalent from the black box viewpoint, are (on the inside)
totally different pieces of software. The PDP-11 compiler is a production
compiler written by D. M. Ritchie; the VAX-11 compiler is a portable compiler
based on work by S. C. Johnson. The figures for the portable compiler running on
the PDP-11/70 and compiling for the Interdata 8/32 are included for those who
wish to compare two portable compilers. We have no VAX-11 equivalent to the
Ritchie compiler, and thus cannot run the tests which would enable comparison of
two production compilers.
The loaded size in bytes of the operating system and seven other programs
appears in Table 1. One should note the general similarity between the text
(instructions) sizes on the PDP-11 and on the VAX-11, and between the bss
(uninitialized data) sizes on the VAX-11 and on the Interdata 8/32. The
particular PDP-11 UNIX system chosen has several more input/output device
drivers and experimental multiplexing software not in the VAX-11 system, which
accounts for its larger text size. If many global integer variables (or large
arrays) are used, there is a tendency for the data and bss portions to double in
size when going from a PDP-11 to a VAX-11 or an Interdata 8/32 because an
int occupies two bytes on the PDP-11 and four bytes on the other
machines. However, character arrays occupy the same amount of space on all
machines. An unusually large number of references to global variables in the
nroff program accounts for its increase in text size on the VAX-11
compared with the PDP-11. A program can be written to automatically change the
addressing modes used in the VAX-11 code so that most references to global data
become shorter than at present, but this has not been done.
Evaluation.
We believe that
the VAX-11/780 provides an excellent hardware environment
for running UNIX and C software.
With the software in its current state, we view the system
as operationally equivalent to a PDP-11/70 running UNIX software,
except that the 64K limit on process address space is gone
and programs run faster.
We believe that the advanced memory management
and user/system communication capabilities of the VAX-11/780
offer an opportunity to construct future UNIX-like systems
with substantially higher throughput
than provided by today's UNIX on a PDP-11/70.
評価
私たちは
VAX-11/780
が
UNIX
および C ソフトウェアを実行するための
優れたハードウェア環境を提供すると思います。
現状のソフトウェアでは、
私たちはシステムを、
プロセス・アドレス空間に対する 64K の制限がなくなり、
プログラムはより速く実行される以外は、
PDP-11/70
の上で走る
UNIX
ソフトウェアと操作上等価なものと見ています。
また、
私たちは
VAX-11/780
の高度なメモリ管理およびユーザ/システム・コミュニケーション能力が
現在の
PDP-11/70
の上の
UNIX
が提供するより本質的に高い処理能力を備えた、
将来の
UNIX
のようなシステムを構築する機会を提示するものと思います。
Hardware
Four main subsystems — the central processor, console, main memory, and
input/output — constitute the VAX-11/780 computer system. The central processor,
memory, and input/output subsystems are connected by the Synchronous Backplane
Interconnect (SBI), an internal synchronous bus with a maximum data throughput
of 13.3 megabytes per second. The SBI deals in physical addresses which are 30
bits wide. Half of the SBI address space is reserved for memory addresses, and
half for input/output device registers. Arbitration for bus cycles on the SBI is
distributed; each subsystem decides if it will use the next bus cycle.
The central processor is a microprogrammed 32-bit general-register computer.
The architecture seen by the user-mode assembly-language programmer is
"culturally compatible" with the PDP-11; an expert programmer familiar with the
PDP-11 can learn and understand the differences in one day or less. The
processor handles binary integers of 8, 16, and 32 bits; single precision (32
bit) and double precision (64 bit) floating-point numbers; character strings up
to 65535 bytes long; bit fields up to 32 bits wide; and IBM-style packed decimal
strings up to 31 digits long. Bit fields have no alignment restrictions
whatsoever, all other data types require alignment only to a byte (8 bit)
boundary. The central processor provides sixteen 32-bit general registers.
Register 15 is the program counter pc. Software operating in one of the
privileged access modes (see below) must use register 14 as a stack pointer
sp. The instructions which implement high-level procedure call and return
(pushl, calls, callg, ret) assume a convention about
the use of sp, register 13 (fp, the frame pointer) and register 12
(ap, the argument pointer). The instructions which handle character and
packed decimal strings use registers 0 through 5 to hold pointers and counters,
so as to be interruptible. Floating-point operations may use the general
registers; there are no separate floating-point registers. Instructions take
from zero to six operands. The operation code occupies one byte and is followed
by the operands, which require from one to nine bytes each. Nine addressing
modes (including all the PDP-11 modes except *-(r)) are allowed, and the
addressing modes are independent of the operation code. When the central
processor is executing in the context of a process, there are four access
privilege modes (user, supervisor, executive, kernel), each with its own stack
pointer; software which desires a per-process kernel stack is easy to implement.
A fifth stack pointer is used when executing in a special system-wide interrupt
context. The VAX-11/780 processor includes an eight kilobyte, two-way set
associative, write-through, memory data cache; an eight-byte instruction stream
buffer; and a 128-address virtual address translation buffer. Most of the
processor is implemented in Schottky TTL MSI logic. A programmable realtime
clock and a time-of-year clock (battery operated during loss of line voltage)
are standard equipment. Options include a hardwired floating-point accelerator
and user-writeable control store.
The console subsystem consists of an LSI-11 computer, local memory, floppy
disk, DECwriter terminal, and remote-access communications port. The console is
connected directly to the central processor and performs all the functions of a
conventional "lights and switches" front panel. The floppy disk serves as the
initial bootstrap device for normal operation and holds special microcode for
diagnostic operation. When activated by a key switch on the central processor,
the remote-access port becomes the console. A terminal connected through the
remote-access port can halt the central processor, boot it, diagnose it, etc.
The virtual address space of a process running on the VAX-11/780 consists of
2**32 8-bit bytes. The two high-order bits of a 32-bit address determine one of
four segments. Two of these segments are system segments common to the address
space of all processes. One of the system segments is reserved for future use.
The other two segments are separately defined for each process and are
automatically managed by the context switching instructions. One of the
per-process segments is designed for a stack which grows towards lower-numbered
memory addresses. Segments are divided into pages of 512 bytes. Memory mapping
hardware translates virtual addresses into physical addresses using page tables.
A page table contains one four-byte entry for each page mapped; the entry
contains a valid bit, a four-bit field which encodes access privileges, a modify
bit, and the physical page-frame number where the page is mapped. (There is no
reference bit which is maintained by hardware!) A base register and a limit
register describe the page table of each segment. The base register of a
per-process segment contains a virtual address within the system segment; the
base register for the system segment contains a physical memory address. The
VAX-11/780 central processor contains a virtual address translation buffer
holding 128 virtual address-page frame number pairs which eliminates the need
for extra memory references during address translation for (typically) 98% of
all memory references. The memory is implemented using MOS semiconductor RAMs
with an error correcting code which corrects all single-bit errors and detects
all double-bit errors and 70% of all greater-than-double bit errors. A memory
controller can handle 8 memory boards; using 4K chips each board can hold 128K
bytes. There can be two memory controllers, thus the maximum amount of physical
memory is currently 2 megabytes. When 16K chips are used [forecasted for late
1978], each board will hold 512K, and physical memory can be 8 megabytes. There
is a battery backup option for maintaining data in the event of a power failure.
Each optional battery will maintain l megabyte for 10 minutes.
The input/output subsystem consists of UNIBUS adaptors and MASSBUS adaptors.
A UNIBUS adaptor (UBA) is an interface between a standard UNIBUS and the SBI.
The UBA does the bus arbitration and everything else necessary to administer the
UNIBUS. It also contains a set of registers for mapping UNIBUS addresses to and
from SBI addresses. The maximum throughput on a UBA is 1.5 megabytes per second.
A MASSBUS adaptor (MBA) is an interface between the SBI and MASSBUS devices
(RP06 disk, TE16 tape, etc.). An MBA would be more properly called an RH-780
controller, analogous to the RH-11 controller on a PDP-11/70 MASSBUS; only one
unit may transfer data at a time, although several similar units connected to
the same MBA can execute control functions simultaneously. The MBA contains the
device control registers normally found in an RH controller. The registers lie
in the I/O section of SBI addresses. An MBA also contains a set of mapping
registers which translate device byte addresses to and from SBI addresses. The
maximum throughput on a MBA is 2.0 megabytes per second. The published limits
are 1 UBA and 4 MBAs per system. Theoretically one could have any number of
either kind as long as the sum of the number of central processors, memory
controllers, MBAs, and twice the number of UBAs were 15 or less, since the SBI
has 15 "ports".
The physical packaging of the system has been dramatically improved compared
with the PDP-11. The VAX-11/780 processor cabinet contains no drawers or moving
cables. The SBI is fixed and rigid. Three one-third horsepower squirrel-cage
blowers provide sufficient air flow &151; even while servicing the CPU. Any logic
card, power supply, or blower an be replaced within twenty minutes by one person
using only a screwdriver The CPU stands 1.53m x 1.17m x 0.77m (HWD); cabinets
housing the CPU, UNIBUS devices, and tape drive are usually bolted together to
form a single unit 1.53m x 2.51m x 0.77m. Our configuration (see section 2)
weighs 3452 pounds and requires 42050 BTU/hr cooling.
A VAX-11 "native mode" C compiler was constructed using S. C. Johnson's
portable compiler as a base. After one month, a reasonable version began to
evolve: it produced code which was good enough to exercise the assembler,
loader, and debugger (on the bootstrap PDP 11/45).
This initial version did not
make use of VAX-11 indexed addressing (which does single-level array
subscripting including appropriate index shifts), bit field instructions, or
autoincrement/decrement addressing.
It contained its share of bugs, particularly
since the hardware had not arrived and could not be used to actually run the
generated code.
VAX-11
"native mode"
Cコンパイラーはベースとして
S. C. Johnson
のポータブルコンパイラーを使用して構築されました。
1か月後に、合理的なバージョンは次のものを発展させ始めました:
それは
(PDP 11/45の上で動作する)
アセンブラー、
ローダー
およびデバッガを実行するに十分なコードを生成しました。
この初期バージョンでは
(インデックスのシフトに適した単一レベルの配列の添字付けを行う)
VAX-11
のインデックス・アドレッシング、
ビット・フィールド命令、
自動インクリメント/ディクリメントアドレシング
を利用しませんでした。
特にハードウェアが到着しておらず、
現実に生成されたコードを実際に実行することができないので、
それにはバグが含まれていました。
Substantial effort has been subsequently directed towards improving all
aspects of the compiler: bugs have been corrected, routines have been made to
execute more efficiently, and the quality of the generated code has been
improved. All addressing modes are supported, bit field instructions are used
for programmer-defined bit fields, and autoincrement and autodecrement
addressing as well as three-address instructions are used.
その後、
コンパイラーの全ての側面に対する改善に向けて、
多大なる努力が行われました:
バグは修正され、
ルーチンはより効率的に実行するために作られ、
そして生成されたコードの質が改善されました。
全てのアドレッシングモードがサポートされました。
ビット・フィールド命令は
プログラマに定義されたビット・フィールドのために使用されます。
また、３アドレス命令と同様に
自動インクリメントおよび自動ディクリメントアドレシングも使用されます。
Overall, our experience with the compiler has been very favorable. When the
VAX-11/780 was delivered, the compiler worked well enough to compile itself,
the
UNIX kernel, and many user-level commands. In fact, since the delivery of the
machine, only about a half-dozen serious bugs have been detected.
Additionally,
the framework of the compiler has proven itself to be flexible: a compiler for
the Interdata 8/32 was transformed into a compiler for the VAX-11/780, some
improvements and extensions were easily added, and, in general, a quickly
evolving compiler has remained stable and productive. The authors feel that,
with a few extensions to the model of the compiler and a certain amount of
tuning,
the current VAX-11 compiler could easily remain as the production VAX-11
compiler.
全体として、
コンパイラーに対する私たちの取り組みは非常に順調でした。
VAX-11/780
が導入された時、
コンパイラーはそれ自体や、
UNIX
カーネル、
また多くのユーザレベルコマンドをコンパイルできるほど
十分にちゃんと動作しました。
現実にマシンの到着以降では、
半ダース程度の重大なバグしか検知されませんでした。
さらにコンパイラーのフレームワークは、
それ自体が柔軟であることを証明しました:
Interdata 8/32
のコンパイラーは
VAX-11/780
ためのコンパイラーに変形され、
いくつかの改良および拡張は容易に加えられ、
そして素早く進化したコンパイラーは総じて安定的と生産的な状態を保ちました。
コンパイラーのモデルに対する少数の拡張と
然るべきチューニングにより、
現在の
VAX-11
コンパイラーは
VAX-11
コンパイラー製品として
維持することができると著者は感じます。
There are still some deficiencies in the current version of the compiler, as
well as in the basic "product" itself. The compiler is slow and quite large;
see
the statistics in section 2 and Table 1. Some of the blame for the size and
lethargy of the first pass can be attributed to the use of lex for the
scanner and yacc for the parser, and to the use of ASCII to communicate
information between passes. both lex and yacc produce large
routines: the scanner is 17K bytes in length
(over 4.5K bytes of instructions),
and the parser is 16K bytes long (over 5.5K bytes of instructions). On the
average, the first pass spends 20% of its time in the lexical scanner
yylook, and 9% of its time in the parser yyparse.
基礎的な「製品」自体と同様にコンパイラーの現行版で
いくつかの欠乏がまだあります。
コンパイラーは遅く、全く大きい;
見てください。セクションおよびテーブル1 2つごとの統計。
第1のパスのサイズおよび不活発のための非難のうちのいくらかは、
パーザ用のスキャナおよび
yacc
のための
法
の使用、およびパス間の情報を通信する
ASCII
の使用に起因することができます。
法
および
yacc
の両方は大規模なルーチンを生産します:
スキャナは長さ(指示の4.5Kバイト以上)17Kバイトです。
また、パーザは長さ(指示の5.5Kバイト以上)16Kバイトです。
平均して、第1のパスは、語いのスキャナ
yylook
の中のその時間の20%、およびパーザ
yyparse
の中のその時間の9%を費やします。
Using ASCII to communicate between the two paves causes an additional speed
penalty for character conversion. On typical programs, the fast pass (parser)
spends roughly 30% of its time performing output services (i.e.,, calls to
_doprnt (18%), _strout (8%), and printf (4%), while the
second pass (code generator) spends roughly 21% of its time reading it back in
(i.e., calls to read (18%) and rdin (3%). (Additionally, the
routine used to convert from ASCII to binary contained a bug which caused
"-2147483648" (which is -(2**31) ) to be read as zero on our PDP-11/45.)
2つの間に通信するためにASCIIを使用することは、
原因を舗装します、文字転換に対する付加的な速度罰。
典型的なプログラムにおいては、
速いパス(パーザ)が、
その出力サービス
(つまり、第2のパス(コード・ジェネレーター)がそのそれを中へ(つまり)
読み返す時間のおよそ21%を費やしている一方、
_doprnt(18%)、
_strout(8%)
および
printf(4%)に呼ぶ)
を行う時間のおよそ30%費やします。
への呼び出しは(18%)
および
rdin(3%)を読みました。
(さらに、ルーチンはかつてはASCIIから切り替えりました、
に、2進法"-2147483648を引き起こしたバグを含む」
(どれがありますか―(2**31))
私たちのPDP-11/45の上の0と解釈されるために)
The above problems are not inherent to the compiler model. To speedup
compilation, the scanner can be hand-coded
(as in the standard PDP-11 compiler),
and the interpass data can be formatted in binary (or the two passes can be
combined). With these simple modifications (some are already in progress), it
should be possible to produce a compiler almost twice as fast as the current
one.
上記の問題はコンパイラー・モデルに固有ではありません。
スピードアップ編集に、
スキャナは手コード化することができます
(標準のPDP-11コンパイラーの中でのように)、
また、相互パスデータは中へフォーマットすることができます、
2進法
(あるいは、2つのパスは組み合わせることができます)。
これらの単純な修正
(いくらかは既に進行中です)
で、コンパイラーをほとんど2度現在のものと
同じくらい速く生産することは可能に違いありません。
Two features of the VAX-11 architecture — three-address instructions and
indexed addressing mode —
were difficult to model within the basic structure of
the compiler.
The full implementation of three-address instructions proved to be
so difficult that it was not really attempted.
Instead, c2, the assembly
language code improver,
tries to merge several instructions into an appropriate
three-address instruction.
For example, the statement a = b + c compiles
VAX-11
アーキテクチャー—の2つの特徴;
3-アドレス指示およびインデックスが付けられたアドレッシングモード—
コンパイラーの基礎的な構造内にモデル化することが困難でした。
3-アドレス指示の十分なインプリメンテーションは、
非常に困難なので、それが実際に試みられないことを証明しました。
代わりに、
c2
(アセンブリ言語コード見習い)は、
適切な3-アドレス指示へいくつかの指示を合併しようとします。
例えば、ステートメントa = b + cはコンパイルします。
addl3 b,c,r0 movl r0,a
addl3 b,c,a
a = b + c return;
return(a = b + c );
The VAX-11 has six indexed addressing modes which yield the address of an
element of a one-dimensional array of a base type (char, short,
int, long, pointer, float, or double).
The statement
VAX-11
は、基礎タイプ
(炭、短い、int、長い、
ポインター、フロート、あるいはダブルの)
の一次元の配列の要素のアドレスを産出する、
6つのインデックスが付けられたアドレッシングモードを持っています。
ステートメント
a[i] = b[j] * c[k];
muld3 b[j],c[k],a[i]
The fact that the code generator can easily recognize only expression trees
of height one (two if OREG and UNARY MUL nodes are taken into account) causes
substantial difficulty in making use of indexed mode, three address
instructions, and indirect addressing. Expression trees of non-trivial height
occur not infrequently (e.g. as a worst case, the statement
コード・ジェネレーターが高さ1
(OREGとUNARYのMULノードが考慮に入れられる場合2)
の表現木だけを容易に?F識することができるという事実は、
インデックスが付けられたモード、
3つのアドレス指示および間接のアドレシングを利用する際の
本質的な困難さを引き起こします。
不自明な高さの表現木が、
希にではなく(例えば最悪の場合(ステートメント)として)生じます。
a = b + (*p++)[i];
addl3 b,*(p) + [i],a
The size and alignment attributes of data objects are logically independent,
even though previous hardware architectures (IBM 360, PDP-11, Interdata 8/32,
...) have imposed alignment restrictions based on size. The VAX 11/780 has no
such restrictions, although programs run faster with data aligned on natural
boundaries. The C language has little notion of alignment; because of run-time
penalties, the VAX-11 C compiler aligns all the basic data types on address
boundaries which are a multiple of sizeof the basic type. Due to
questions about alignment, both the language and the compiler have difficulty
with the declaration char c:10;.
たとえ前のハードウェア・アーキテクチャー
(IBM、PDP-11、Interdata 8/32 360)
がサイズに基づいた整列制限を課したとしても、
データ・オブジェクトのサイズと整列の属性は論理上独立しています。
プログラムは自然的境界上で提携したデータでより速く走りますが、
VAX 11/780
はそのような制限を持っていません。
C言語は、整列についてのわずかな概念を持っています;
ランタイム罰のために、
VAX-11
Cコンパイラーは、多数の
sizeof
であるアドレス境界上の基本的なデータ・タイプをすべて整列させます、
基本型。
整列についての疑問により、
言語およびコンパイラーの両方は宣言炭cに苦労します:10;。
The decision to naturally align most data items has undesirable side effects
which cannot be ignored. Consider the structure declaration
当然ほとんどのデータ・アイテムを整列させる決定は、
無視することができない不適当な副作用を持っています。
構造宣言を考慮してください。
struct foo {
char c;
float f;
} bar;
A UNIX system running on a PDP-11/45 was used as the base for transporting
software to the VAX-11/780. The software itself originated with the code
produced by members of Center 127, Computing Science Research,
for the Interdata 8/32.
Programs were cross compiled, assembled, loaded, and put an magnetic tape
in tp format; absolute bit-string files were put on tape in dd
format. Tapes were then carried across the room to the VAX-11/780. An absolute
tape boot (in machine language), tp boot and primary disk boot (in
assembly language), secondary disk boot (in C),
and stand-alone utilities (disk
formatter, disk verifier, tape-to-disk, disk-to-tape , disk-to-disk, and
disk-to-console, all in C) were then used to bring up the system.
PDP-11/45
の上で動作する
UNIX
システムは、
VAX-11/780
にソフトウェアを転送するためのベースとして使用されました。
ソフトウェア自身は
Interdata 8/32
のために、
Computing Science Research
の
Center 127
のメンバーによって作られたコードが元となりました。
プログラムはクロスコンパイルされ、
アセンブル、ロードされたのち、
磁気テープに
tp
フォーマットで記録されました;
absolute bit-string files
は
dd
フォーマットでテープに記録されました。
その後、テープは
VAX-11/780
が置いてある部屋へ運ばれました。
そして、
システムを起動するために
(機械語による)
absolute tape
にのブート、
tp
にのブート、
(アセンブリ言語による)
ディスクからのプライマリブート、
(C 言語による)
セカンダリブート、
そしてスタンドアローンのユーティリティ
(disk formatter,
disk verifier,
tape-to-disk,
disk-to-tape,
disk-to-disk,
disk-to-console,
全て C 言語による)
が使われました。
Establishing an initial file system on the disk took longer than expected.
The PDP-11/45 was running USG issue 3 of the UNIX operating system with a
"16-bit" file system and the VAX-11/780 was to have a Research version 7
"32-bit" file system. Also,
C-language code on the VAX-11 expects the bytes of a
32-bit integer to be stored in a different order than C-language code on the
PDP-11. We swallowed these two red herrings hard, and suffered.
We now know that
the proper way to create an initial file system is to modify the program
mkfs so that its output (on the bootstrap machine) is a file containing
the proper bits, put that file on tape,
and use the tape-to-disk utility on the
target machine.
ディスク上に最初のファイルシステムを作成することは
想像より長くかかりました。
PDP-11/45
では
UNIX
オペレーティング・システムは
USG
の第３版が稼働していたので、
16ビットファイル・システムを使用していましたが、
VAX-11/780
では
Version 7
の32ビットファイル・システムを使用する予定でした。
さらに、
VAX-11
の上での C コードは、
32ビットの整数のバイトについて
PDP-11
の上の C コードとは異なる順序で格納することを要求します。
私たちは苦労して、
これら２つの本質的でない問題を何とか受け入れました。
今では、私たちは
初期のファイルシステムを作るための適切な方法が
(起動するマシンにおいて)
その出力が適切なビットを含むファイルになるように
mkfs
というプログラムを修正し、
テープにそのファイルを記録して、
ターゲットマシンの上で
tape-to-disk
ユーティリティを使用することを知っています。
Mapping the software architecture of the UNIX operating system onto the
hardware architecture of the VAX-11 required a number of decisions. Commentary
on these decisions follows. The SCB (system context base) processor register
contains a page-aligned physical memory address which is the base of the
hardware interrupt vector. The UNIX system puts this vector at physical memory
address zero. Operating system code, data, kernel stacks, and interrupt stack
occupy the VAX-11/780 system segment (virtual addresses 80000000 to bffffff).
User code and data are loaded into segment zero (0 to 3fffffff) and the user
stack is initialized in segment one (7fffffff to 40000000).
User processes pass
arguments to system service code using the ordinary calls subroutine
calling sequence. The ckmk instruction is then used to gain kernel
privileges. The chmk instruction switches the stack pointer sp from the
user stack to the kernel stack, but does not change the argument pointer
ap or the frame pointer fp.
The kernel uses the value in ap
to copy the arguments into u.u_arg.
The VAX-11 hardware allows the values
to be directly addressed, but the kernel software requires the copy.
VAX-11
のハードウェア・アーキテクチャー上に
UNIX
オペレーティング・システムの
ソフトウェア・アーキテクチャーをマッピングするためには
多くの決定を必要としました。
これらの決定に関するコメントを続けます。
SCB
(システム・コンテキスト・ベース)
プロセッサー・レジスタは、
ハードウェア割り込みベクトルのベースである
ページに位置合わせした物理メモリーアドレスを記録します。
UNIX
システムではこのベクトルを物理メモリーアドレスの０に置きます。
オペレーティング・システムのコード、データ、カーネル・スタック、
およびインターラプト・スタックは
VAX-11/780
のシステム・セグメント
(仮想アドレスの 80000000 から bffffff まで)
に置かれます。
ユーザのコードとデータは
セグメント０
(0 から 3fffffff まで)
にロードされます。
また、ユーザ・スタックは
セグメント１
(40000000 から 7fffffff)
で初期化されます。
ユーザー・プロセスはごく一般的な
calls
サブルーチンの呼び出しシーケンスを使って、
システム・サービス・コードへ引数を渡します。
その後、
カーネル特権を獲得するために
ckmk
命令が使用されます。
chmk
命令はスタック・ポインターspを
ユーザ・スタックからカーネル・スタックに切り替えますが、
引数ポインター
ap
とフレーム・ポインター
fp
は変更されません。
カーネルは
引数を
u.u_arg
にコピーするため、
ap
の中の値を使用します。
VAX-11
ハードウェアは
値を直接参照すること (the values to be directly addressed) を許しますが、
カーネル・ソフトウェアはコピーすることを要求します。
The u area is a per-process data structure in which the operating
system keeps swappable information about a process. The kernel virtual address
of the u area must be a constant across all processes. The PDP-11
implementation puts the u area at kernel address 0160000; when process
switching occurs the u area is switched by changing a kernel data space
segmentation register. Since the operating system can address user memory on a
VAX-11, the u area could be placed in (protected) user memory, say at
address 0 or at 7fffe000.
However,
it was desirable for the first implementation
to make the page tables for user segments part of the u area,
which creates timing problems unless the u area lies in system space.
The base
of the u area was assigned kernel virtual address 80020000.
When process
switching occurs, the u area is changed
by changing the system-space page
table and invalidating the page-table translation cache for the appropriate
pages.
u area
はオペレーティング・システムが
プロセスに関する交換可能な情報を保持するためのプロセス毎のデータ構造です。
u area
のカーネル仮想アドレスは全てのプロセスで同じ値をとらなければなりません。
PDP-11
の実装ではカーネル・アドレス
0160000
に
u area
を置き、
プロセス・スイッチングが発生すると、
u area
はカーネル・データ・スペース・セグメンテーションレジスタを
変更して切替えられます。
VAX-11
ではオペレーティング・システムが
ユーザ・メモリを参照することができるので、
u area
は
アドレス 0 から 7fffe000 の
(保護された)
ユーザ・メモリに置くことができます。
しかしながら、
それは
u area
のユーザ・セグメントの部分のページ・テーブルを作るために
最初の実装においては望ましかったのですが、
システム空間に
u area
が存在しない場合にはタイミングの問題を引き起こします。
u area
のベースはカーネル仮想アドレスの 80020000 におかれました。
プロセス・スイッチングが発生した時、
システム空間のページ・テーブルを変更し、
適切なページのページ・テーブル変換キャッシュを無効にすることにより、
u area
は変更されます。
Since the operating system can directly address the memory of the current
user process, the procedures fubyte, subyte, fuword,
etc.,
are unnecessary and could be made into macros which would merely do the
appropriate load or store. However, these procedures
(along with copyin and copyout)
were kept to ensure that each access to user space is valid.
オペレーティング・システムは
現在のユーザー・プロセスのメモリを直接参照できるので、
プロシージャ
fubyte、
subyte、
fuword
などは不要で、
単に適切な load/store を行うマクロにすることもできましたが、
ユーザー空間への各々のアクセスが有効であることを保証するため、
(copyin、copyoutと一緒に)
これらのプロシージャは残されました。
A VAX-11/780 internal processor register called the PCB
(process context base)
points to an area in which the VAX-11/780 saves the hardware state of the
machine (96 bytes) when switching context.
This save area was put in the
u area as u_rsav.
PCB
(プロセス・コンテキスト・ベース)
と呼ばれる、
VAX-11/780
の内部プロセッサー・レジスタは、
コンテキストが切り替わった時、
VAX-11/780
がマシンのハードウェア状態 (96 bytes) を退避する領域をポイントします。
この退避領域は
u_rsav
として
u area
の中に確保されました。
The implementation of context switching required major effort. The VAX-11 has
two very nice instructions (svpctx, save process context; and
ldpctx, load process context) which facilitate context switching.
Unfortunately, they do not implement the mechanism which the UNIX system
expects. The mechanism used by UNIX is so dispersed and intricately detailed
that it is hard to imagine any hardware which implements it directly.)
The temptation to drastically change the UNIX code has been resisted so far.
The
savu/retu/aretu tar pit was VAXinated, but it took more than a week.
The
newer save/restore primitive does make the C-language code prettier,
but
the assembly-language side (at least for the VAX-11) is just as dirty as ever.
The UNIX context switching mechanism requires three state save areas,
u.u_rsav, u.u_ssav, and u.u_qsav
because the same mechanism
is also used for abnormal returns.
The VAX-11 context-switching instructions use
only a single state save area. To make use of the VAX-11 instructions, the
software simulates a great deal of microcode and bastardizes call frames in a
most ugly manner. Context switching is certainly high on the list of things to
rewrite in the second implementation (even for the PDP-11!).
コンテキスト切替の実装には大きな努力が必要でした。
VAX-11
はコンテキスト切替のための
２つの非常によい命令
(svpctx プロセス・コンテキストのセーブ;
ldpctx プロセス・コンテキストのロード)
を持っていますが、
不運にも
UNIX
が期待するメカニズムが実装されていません。
UNIX
が使用するメカニズムは、
どんなハードウェアにもそのまま実装するのは難しいと思われるくらい、
大変分散し複雑に詳細化されています。
これまで
UNIX
のコードを修正する誘惑に徹底的に抵抗しました。
savu/retu/aretu
は
VAX
化されましたが、
この作業に１週間以上かかりました。
新しい
save/restore
プリミティブでは C 言語部分はよりきれいなものになりましたが、
アセンブリ言語のサイドは (少なくとも
VAX-11
のために) は相変わらず汚いままでした。
異常発生時のリターンでも同じメカニズムが使用されるので、
UNIX
のコンテキスト・スイッチングのメカニズムは
u.u_rsav,
u.u_ssav,
u.u_qsav
の３つの状態退避領域を要求します。
しかし
VAX-11
コンテキスト・スイッチング命令は
１つの状態退避領域しか使用しません。
VAX-11
の命令を利用するために、
ソフトウェアは多くのマイクロコードをシミュレートし、
ほとんどの醜いやり方で呼び出しフレームを荒っぽく扱います。
コンテキスト・スイッチングは
次の実装において確実に書き直すべきもののリストの
高いところにおかれるでしょう。
(PDP-11のものであっても!)
The procedures sureg and estabur were also tricky to implement.
They were designed with the assumption that only a small number
(16 or fewer)
of registers would be needed to map the address space of a user process,
while on the VAX-11 a 32K process requires 64 page table entries.
Furthermore,
the memory map of a process is diddled in tricky ways,
particularly in
expand
and
getxfile.
プロシージャ
sureg
および
estabur
も巧妙に実装されました。
VAX-11
において
32Kのプロセスが
64ぺージのテーブル・エントリーを要求するのであれば、
ユーザー・プロセスのマッピングのためにはごく少数
(16個程度)
のレジスタしか必要とされないという仮定に基づいて設計されました、
更にプロセスのメモリ・マップは、
特に
expand
と
getxfile
といった巧妙な方法でいじられます。
Handling DMA I/O hardware was the other major implementation bottleneck.
The UBA and MBA mapping registers contain physical memory page numbers,
and physical addresses are hard to handle.
It is not pleasant to deal with the hardware
which implements the mapping registers.
If an I/O transfer is in progress
then the mapping registers may be neither read nor written;
this applies even to registers which would not be used by the transfer.
As a result,
the map for the next I/O operation cannot be setup
during the current I/O operation.
Furthermore,
a single transfer is limited to 64K bytes
because the byte counter is only 16 bits wide.
Thus swapping a process to the disk can require multiple I/O operations.
The solution to these problems
involved permanently reserving the last 129 registers
in each map to service both swap and physical I/O operations.
The remaining map registers are available to map the system buffers,
and are loaded at system initialization time.
Disk ECC error correction is currently done
only for I/O involving the system buffers.
Disk errors on raw I/O cause process termination;
the swap area on disk had better be error-free.
DMA I/O Hardware
のハンドリングはその他の実装上のボトルネックでした。
UBAとMBA
のマッピング・レジスタには物理メモリページの番号が記録されますが、
物理アドレスを操作は困難なものです。
マッピング・レジスタが実装されている
ハードウェアに対処することは楽しいことではありません。
I/O
の転送中は、
マッピング・レジスタの内容を参照することも更新する事もできません。
これは転送に使用されないレジスタにも当てはまります。
その結果、
I/O オペレーションが行われているうちは、
次の I/O オペレーションのマップの準備ができません。
それどころか、
バイト・カウンターのサイズが 16 ビットしかないため、
１回の転送は64Kバイトまでに制限されています。
したがって、
ディスクへのプロセスのスワッピングには
多数の I/O オペレーションを必要とするかもしれません。
このような問題の解決策は
スワップと物理的 I/O オペレーションを行うために、
個々のマップ毎に最後の 129 個のレジスタを常時予約しておく事です。
残りのマップ・レジスタはシステム・バッファーをマップするよう
システム初期化時に設定されます。
現在、ディスクの
ECC
エラー訂正はシステム・バッファーに伴う I/O のためにのみ行われます。
低水準 I/O 時のディスク・エラーはプロセス終了を引き起こします;
ディスク上のスワップ領域はエラー・フリーであったほうがよいでしょう。
Like the UNIX system for the PDP-11, the current implementation for the
VAX-11/780 maintains each process in contiguous physical memory and swaps
processes to disk
when there is not enough physical memory to contain them all.
Reducing external memory fragmentation to zero by utilizing the VAX-11/780
memory mapping hardware for scatter loading is
high on the list of things to do
in the second implementation pass. To simplify kernel memory allocation, the
size of the user-segment memory map is an assembly parameter which currently
allows three pages of page table
or 192K bytes total for text, data, and stack.
This also deserves to be rewritten, both to allow varying process size, and to
allow processes larger than physical memory through demand paging.
Dynamic page
table size would mean dynamic u area size
if the page table remained part
of the u area.
PDP-11
版
UNIX
システムのように、
VAX-11/780
の現在の実装は連続した物理メモリの中に各プロセスを保持し、
全部のプロセスを収めるに十分な物理メモリがなくなった時には、
プロセスをディスクにスワップします。
scatter loading
のための
VAX-11/780
のメモリ・マッピング・ハードウェアを利用して、
外部メモリが０まで細分化がしてしまうことを減らすことは
次の実装作業でのやるべきことのリストの上位に位置します。
カーネルのメモリ・アロケーションを単純化するため、
ユーザ・セグメントのメモリ・マップの大きさは
アセンブラのパラメータにしました。
現時点ではページ・テーブルの３ページか、
テキスト、データ、スタックを合わせて全体で 192K のいずれかです。
また、これはプロセス・サイズの変更を許す、
あるいはデマンド・ページングを使って
物理メモリよりも大きなプロセスを許すために書き直すことには価値があります。
もしページ・テーブルが
u area
の一部だとしたら、
動的なページ・テーブル・サイズは
動的な
u area
サイズを意味するでしょう。
The code in sendsig for sending a signal to a process involves a
tedious simulation of the calls instruction due to the problem of "inward
return" across privilege modes upon termination of the routine
which handles the
signal. Making a portion of the kernel code readable by a user-mode process
would simplify sendsig. Motivated by a problem with the Bourne shell,
the signal
number is passed as a parameter to the signalled routine.
プロセスに信号を送るための
<私>sendsig
の中のコードは、
信号を扱うルーチンの終了上の特権モードを横切って、
「内部のリターン」の問題により呼び出し指示の
退屈なシミュレーションを含んでいます。
核コードの部分をユーザー・モードプロセスによって判読可能にすることは、
sendsig
を単純化するでしょう。
ボーン・シェルに関する問題によって動機づけられて、
信号の数は示されたルーチンにパラメーターとして渡されます。
Interprocess communication via signals (signal and kill) uses
the low-order bit of a machine address for something other than addressing.
This implies that
a procedure which handles signals must start on an even byte boundary,
which means that every procedure must start on an even byte boundary.
The C compiler thus issues a pseudo-op
to the assembler to align the beginning of each procedure.
This can waste memory on a VAX-11.
It also imposes a nontrivial requirement on the assembler,
since if the resolution of conditional jump instructions
can change the parity of the length of a procedure
then the alignment directive must also be handled like a conditional jump.
In hindsight,
it would have been better
if a distinct value (say +1 or -1) were used for ignore,
rather than multiplexing the bottom bit.
signal
(signal と kill)
を介したプロセス間通信は、
アドレシング以外に何かのために
マシン・アドレスの低位ビットを使用します。
これは
signal
を扱うプロシージャが偶数のバイト境界から始まらなければならない、
つまり全てのプロシージャが偶数のバイト境界から始まらなければならない事を
暗に意味しています。
このため C コンパイラーは、
各プロシージャの始まりを整列させるため、
アセンブラーの疑似命令を生成します。
これは
VAX-11
にメモリを浪費させることができます。
さらに、それはアセンブラーに、
条件付きのジャンプ命令の解決が
そのときのプロシージャの長さのパリティーを変更することができる場合、
alignment directive
も条件付きの跳躍のように扱われなければならないという、
自明でない要求を課します。
結果論ですが、
ignore
のためには、
低位ビットを多重化するよりも、
(+1あるいは-1といった)
明解な値を使った方がよかったでしょう。
The VAX-11/780 provides a (non-maskable) trap for integer division by zero.
The system would like to turn this into a signal to the process.
A similar situation exists for subscript range trap.
Integer overflow, floating overflow,
floating underflow, and reserved operand also need signal numbers.
Perhaps only one "error" signal is needed
with some other means for determining the true fault.
The whole business of interrupts, signals, asynchronous I/O, and the use
of the hardware AST mechanism deserves more attention.
VAX-11/780
は０による整数除算のための(マスクできない)トラップを提供します。
システムはこれをプロセスへの
signal
に変換します。
subscript range trap
でもそれは同じ状況でしょう。
整数演算オーバーフロー、
浮動少数点演算オーバーフロー、
浮動少数点演算アンダーフロー、
および予約オペランドは、
さらに
signal
の番号を必要とします。
恐らく、１つだけの
"error"
の
signal
と実際のフォルトを決定するための他のある手段で必要です。
割り込み、
signal、
非同期 I/O、
およびハードウェア AST メカニズムの使用などの振舞には
より多くの注意が必要でしょう。
A bug was discovered in the UNIX code for process termination involving the
proc and xproc structures. (The problem also existed on the
PDP-11, but it would only be noticed if a process had accumulated more than
65535 ticks of system time, which is highly unlikely.) When a process dies its
resource utilization statistics
(currently only exit status, system, and process CPU time)
are temporarily saved so that they can be added to the totals for the
descendents of the parent process.
The actual accumulation is done by the kernel
when the parent process issues a wait system call; the child process is then
completely erased. The kernel was overlaying the statistics in a part of the
proc structure normally used by the scheduler to contain the pointer
p_textp.
Ordinarily the exit was processed immediately, causing no harm.
But if the system was loaded so that swapping was necessary,
then the scheduler
could sneak in after the child exited
and before the parent read the statistics,
and would interpret the timing data in the zombie xproc structure as a
pointer. This invariably caused an illegal memory reference
from kernel mode on
the VAX-11/780.
バグは、
proc
を含む、
プロセス終了および
<私>xproc
構造のための
UNIX
コードの中で発見されました。
(その問題は、さらにPDP-11に存在しました。
しかし、もしプロセスがシステム時間
(それはほとんどありそうもない)
の65535を越えるかちかちを蓄積していたならば、
それは単に気づかれるでしょう。)
プロセスが死ぬ場合、
親プロセスの子孫のための合計にそれらを加えることができるように、
その資源利用統計
(現在単に出口ステータス、システムおよび?vロセスCPU時間)
は、一時的に保存されます。
親プロセスが待機システムコールを出す場合、
実際の蓄積はカーネルによって行われます;
その後、子プロセスは完全に削除されます。
カーネルは、ポインター
p_textp
を含むためにスケジューラによって通常使用される
proc
構造の部品中の統計を覆っていました。
通常、出口は直ちに処理され、その結果害を引き起こしませんでした。
しかし、もしスワッピングが必要だったように、
システムがロードされれば、子供が出た後、
および親が統計を読み、ポインターとしてゾンビ
<私>xproc
構造中のタイミング・データを解釈するだろう前に、
スケジューラは中へこっそり入ることができるでしょう。
これは、常に
VAX-11/780
の上のカーネル・モードからの不法なメモリ参照を引き起こしました。
One of the greatest disappointments with the current system stems from a
design quirk in the FP-11 floating-point processor for the PDP-11. When
converting between floating-point and 32-bit integer, the FP-11 expects the
high-order 16 bits of the integer to be stored at the lower memory address;
this
is not in line with the general "right to left" design of the PDP-11, which
would place the low-order 16 bits in the lower memory address. C code for the
PDP-11 uses the FP-11 convention for storing long integers. The VAX-11
hardware stores the least significant bit of any integer data type
in the
lowest addressed byte. C code for the VAX-11 uses the hardware convention.
This
means that files containing long integers represented in the local
convention are not binary compatible between a UNIX system on the VAX-11 and a
UNIX system on the PDP-11. This is the only exception for data types common to
both machines: char, short, float, and double all
have a common representation. Except for this
(and the structure alignment problem noted earlier),
disk packs containing 32-bit file systems, tapes, etc.,
would have been interchangeable. The fact that DEC's Fortran-IV Plus for the
PDP-11 avoided the FP-11 convention, and that RSX-11 files are binary
compatible between the VAX-11 and the PDP-11, is only salt on an open wound!
現在のシステムに対する最も大きな失望のうちの1つは、
PDP-11
のための
FP-11
の浮動小数点式のプロセッサー中の設計奇癖から生じます。
浮動小数点式と、32ビット整数間に変換する場合、
FP-11
は整数の高いオーダー16ビットが
より低いメモリ・アドレスに格納されることを予期します;
これ
PDP-11
(それはより低いメモリ・アドレスに低位16ビットを置くだろう)
の一般的な「残したべき権利」デザインに従いません。
PDP-11
のためのCコードはの格納のためにFP-11協定を使用します、長い整数。
VAX-11
ハードウェアは、
どんな整数データもタイプ?Cンする、の最も重要でないビットを格納します、
最も低くアドレスされたバイト。
VAX-11
のためのCコードはハードウェア協定を使用します。
これ手段、それ、ローカルの協定で表わされた長い
整数がそうでない、を含んでいるファイル、
2進法、
VAX-11
の上の
UNIX
システムと
PDP-11
の上の
UNIX
システムの間で互換性をもつこれは
両方の機械に共通のデータ・タイプのためのただ一つの例外です:
炭、短い、フロートおよびダブルのは
すべて共通の表現を持っています。
これ(また、構造整列問題は以前に注意しました)、
32ビットのファイル・システムを含んでいる
ディスクパック、テープなどを除いて、交換可能だったでしょう。
PDP-11
にはプラスのDECのフォートランIVが
FP-11
協定を回避したという事実
およびは、です、2進法、VAX-11とPDP-11の間で互換性をもつ、
解放傷上の単に塩である!(RSX-11)(ファイル)
libc. Conversion of the system-call interface routines was
straightforward but tedious. Most routines are merely
.word 0x0000 chmk $nn bcc L1 jmp cerror L1: ret
libS. Conversion of the standard input/output library libS
posed no problems except for _doprnt, the routine which constructs
character representations of other datatypes for the printing routines
printf, fprintf, and sprintf. Since many programs spend 15%
to 20% of their execution time within _doprnt, it pays to code the
routine for speed in assembly language. Packed-decimal instructions handle
decimal, unsigned, and floating-point conversions. The algorithm chosen for
converting from floating-point to character string revealed a microcode bug in
the VAX-11/780's ashp (arithmetic shift and round packed) instruction.
Under certain conditions a carry from the rounded digit propagated both to the
adjacent digit and to the digit eight places further left. This usually caused
an overflow, since the destination packed-decimal string was typically not long
enough to represent the spurious carry. DEC claims to have a fix for the bug,
but the FCO has not arrived. In the meantime a five-instruction patch detects
and corrects the spurious overflow.
as, ld. Code developed by Center 127 for the Interdata 8/32 was the
model for an interpretation by a VAX-11/780 artist. The assembler uses an
algorithm described in [3] with heuristic improvement of [4] to resolve
conditional jump pseudoinstructions. Variable-length, unaligned instructions and
address constants forced the relocation information in object tiles to include
the explicit segment-relative address for each relocatable datum, rather than
deducing the address from a one-to-one correspondence between the position in
the segment and the corresponding position in the relocation table. This caused
a slight change in the header information within object files.
c2. The code improver for the assembly language generated by the
VAX-11 C compiler is based on a similar program for the PDP-11. A "backwards"
register usage pass, performed once and before anything else, was a major
addition. Knowing that no temporary register is live across a backwards jump,
the register usage pass introduces three-address instructions wherever possible.
It also recognizes situations where jump on bit (jbc, jbs,
jlbc, jlbs), extract field (extzv, movzbl), and move
address (moval, movab, pushal, pushab) instructions
can be used. The code for insertion of fancy loop control instructions
sob, sob, scb was also extended.
adb. The most significant change to the symbolic debugging routine was
the writing of a disassembles for VAX-11 native-mode instructions. Additionally,
the character input and output routines were modified to use a default radix for
all numeric values. The radix is initialized to sixteen.
sh. The (Bourne) shell is the standard user command interpreter. It
required by far the largest conversion effort of any supposedly portable
program, for the simple reason that it is not portable. Critical portions are
coded in assembly language and had to be painstakingly rewritten. The shell uses
its own sbrk which is functionally different from the standard routine in
libc. The shell wants the routine which fields a signal to be passed a
parameter giving the number of the signal being caught; signal was also a
private routine. This was handled by having the operating system provide the
parameter in the first place, doing away with the private code for
signal. The code in fixargs (for constructing the argument list to
an exec system call) had to be diddled.
ps, iostat. The process and input/output status commands consistently
referenced /dev/mem (physical memory) when they should have referred to
/dev/kmem (kernel virtual memory). iostat also assumed that
certain variables maintained by the kernel were allocated contiguously, even
though they were not declared as part of a structure.
pr. The command which formats and prints files had a bug that caused a
division by zero when it was asked to print several files and the fist file in
the list did not exist. On a PDP-11 division by zero returns the dividend, but
on a VAX-11 it gives an unmaskable trap.
cat, dc. These two commands did not count their arguments using the
first parameter argc, but rather assumed that an additional argument
(argv[argc], initialized as -1) could be used as a pointer. On the PDP-11
the resulting address references the fixed end of the stack; on the VAX-11, -1
is an illegal address.
nroff/troff The source code for the document preparation and
phototypesetter commands is not portable; several weeks were required to produce
properly running version of these commands. Use of the explicit (or worse,
implicit) constant "2" instead of sizeof(int) was quite common.
The code assumes that variables which are adjacent in external declarations
occupy contiguous memory at execution time. Several tables are initialized by
assembly-language programs. Converting the tables was merely tedious; changing
the code which thought it knew the format of an a.out file required some
effort. This memorandum was created using the converted nroff/troff programs on
the VAX-11/780.
SCCS. Version 4 of the Source Code Control System [5] is used to
provide version backup for software in case disastrous bugs are introduced. The
source for SCCS itself had not quite been converted to version 7 UNIX, and the
header files required some massaging. The PWB routines logname and
pexec had to be simulated. The utility procedures for dynamic storage
allocation required some work to integrate them with libS and to remove PDP-11
dialect. The exit status of the diff command changed in version 7,
causing delta to bomb. The code implicitly assumed that all checksums
were computed modulo 65536. The documentation is incorrect: everywhere "99999"
appears it should really say "65535". The procedure satoi returns two
values, storing one of them indirectly through a pointer parameter. Naturally,
satoi and its callers did not agree on sizeof the stored value;
this took a day to track down.
We thank the members of Center 127, Computing Science Research, for their
efforts in producing the basic software and for their recent efforts towards
making the software portable. The fact that people other than the original
developers an quickly create a running system for a new machine is a tribute to
how well the original work was done.
Yet in our effort to transport a complete UNIX system to the VAX-11/780 we
stumbled across a large number of nonportable constructions and were dismayed by
the seeming lack of appropriate facilities to detect and prevent them. Based on
our experience, we strongly recommend that the C language and its compilers be
enhanced so that
There is a program called lint [6] which, if conscientiously used
throughout the life of a piece of software provides type checking which
partially addresses the first two points in the above list. The problem is that
lint is big, noisy, relatively recent and unknown, and (partially as a
result) infrequently used. There is little incentive for the average programmer
to use lint as a matter of course. The authors believe that type checking
belongs in the everyday compiler as the default, where it is very inexpensive to
implement. Those who wish to do "dirty" work may request that type checking be
disabled; those who wish to bless their dirty work may use type casts.
We believe that these four enhancements would go a long way towards making C
language software portable as a rule rather than as an exception, thus
preserving Bell Laboratories' investment in present and future C software.
Acknowledgements. Thank you, D. M. Ritchie and S. C. Johnson, for
answering questions at key moments; G. K. Swanson, for assistance with boot
procedures and stand-alone utilities; J. F Jarvis,
for the mathematical function
library; and D. K. Sharma, for help in bringing up user-level commands.
Additional thanks go to many other members of Centers 127 and 135, and
Department 8234, for helpful comments and suggestions.
| Program | System | Text | Data | Bss | Total |
| /unix | |||||
| PDP-11 | 48064 | 2470 | 44040 | 94574 | |
| VAX-11 | 34476 | 4292 | 39448 | 78216 | |
| Interdata 8/32 | 79976 | 11904 | 39208 | 131088 | |
| C, pass 1 | |||||
| PDP-11 | 36736 | 19826 | 17656 | 74218 | |
| VAX-11 | 37520 | 29492 | 23512 | 90524 | |
| Interdata 8/32 | 60606 | 32192 | 24920 | 117718 | |
| C, pass 2 | |||||
| PDP-11 | 21248 | 6254 | 5246 | 32748 | |
| VAX-11 | 23408 | 9092 | 7552 | 40052 | |
| Interdata 8/32 | 35652 | 9032 | 7560 | 52244 | |
| ed | |||||
| PDP-11 | 10752 | 302 | 4390 | 15444 | |
| VAX-11 | 11552 | 212 | 4556 | 16320 | |
| Interdata 8/32 | 21886 | 480 | 4576 | 26942 | |
| grep | |||||
| PDP-11 | 4736 | 408 | 1906 | 7050 | |
| VAX-11 | 4864 | 476 | 1936 | 7276 | |
| Interdata 8/32 | 11950 | 1160 | 1936 | 15046 | |
| ls | |||||
| PDP-11 | 7104 | 768 | 3856 | 11728 | |
| VAX-11 | 6884 | 1140 | 5764 | 13788 | |
| Interdata 8/32 | 15660 | 1920 | 5768 | 23348 | |
| nroff | |||||
| PDP-11 | 29312 | 6684 | 7842 | 43838 | |
| VAX-11 | 36360 | 9408 | 10636 | 58836 | |
| Interdata 8/32 | – | – | – | – | |
| sort | |||||
| PDP-11 | 6656 | 1578 | 2104 | 10338 | |
| VAX-11 | 6580 | 1764 | 2788 | 11132 | |
| Interdata 8/32 | 13886 | 2208 | 2792 | 18886 |
Table 1. Loaded Program Sizes (in bytes)