/* INTRO.TXT - Introduction to the KLH10 */ /* $Id: Intro.txt,v 2.4 2001/11/19 12:11:30 klh Exp $ */ /* Copyright © 1997,2001 Kenneth L. Harrenstien ** All Rights Reserved. ** ** This file is part of the KLH10 Distribution. Use, modification, and ** re-distribution is permitted subject to the terms in the file ** named "LICENSE", which contains the full text of the legal notices ** and should always accompany this Distribution. */ CONTENTS ======== All KLH10 documentation is online in ASCII text files for simplicity and portability. The contents, in suggested order of perusal, are as follows: Intro.txt - General intro news.txt - Changes from previous versions install.txt - Build, install, & configuration instructions usage.txt - General usage instructions klt20.txt - KL10 TOPS-20 installation and startup klt10.txt - KL10 TOPS-10 installation and startup kst20.txt - KS10 TOPS-20 installation and startup kst10.txt - KS10 TOPS-10 installation and startup ksits.txt - KS10 ITS installation and startup backgrnd.txt - Background comments coding.txt - Coding guidelines cmdref.txt - Command reference cmdsum.txt - Command summary cheat sheet dfkfb.txt - KL10 timing diagnostic dvhost.txt - Special host device history.txt - Historical notes kldiff.txt - Differences from real KL10 utils.txt - KLH10 Utilities vtape.txt - Virtual tape details GENERAL INFORMATION =================== "KLH10" is an emulator for the PDP-10 series of machines from Digital Equipment Corporation. The most important thing to know is that this is a MACHINE emulator. It emulates a specific PDP-10 CPU and all necessary I/O devices, running a site's existing operating system (monitor) binary without change -- which then runs user-mode application programs just as if they were on a real PDP-10. Even floating-point results are bit-identical. This means sites must continue to manage the virtual system in the same way as a real one, without the old hardware. However, the emulator doesn't monopolize the actual platform, and runs as a set of simple user processes that co-exist with other software on the native system. It is possible to configure it so that no actual CPU time is used while the virtual system is idle. The KLH10 emulator is extremely portable and flexible -- it is written in ANSI C so that it can be ported to new platforms quickly, and new "virtual hardware" can readily be added. The following describes the currently supported versions: Emulation Target: KL CPU: KL10B with extended addressing Memory: 4MW MF20 (22 bits - 8192 pages of 512 words) Microcode: v.442 (supports final versions of TOPS-10 or TOPS-20) Devices available: DTE - one CTY RH20 - up to 8 (7 if using a NI20) Disk - 8 RP06 or RP07 drives per RH20 Tape - 8 TM02/3 formatters per RH20, with one TU45/TU77 each Network - one NI20 (KLNI/NIA20) ethernet interface Emulation Target: KS CPU: KS10 Memory: 512KW (19 bits - 1024 pages of 512 words) Microcode: ITS v.262 (supports final version of KS10 ITS) DEC v.130 (supports final versions of KS TOPS-10/20) Devices available: FE - one CTY RH11 - up to 2 Disk - 8 RP06 or RP07 drives per RH11 Tape - 8 TM02/3 formatters per RH11, with one TU45/TU77 each Network - one "ACC LH-DH" IMP interface (ITS only) Supported Host Platforms: Compaq/DEC Alpha with Tru64 (formerly Digital Unix, formerly OSF/1) SUN Sparc with Solaris Any x86 with FreeBSD, NetBSD, or Linux Plus: Any system providing equivalents to basic Unix system calls. WNT/W2K ports are possible. Requirements: Memory: KL: 35MB (3MB program, 32MB emulated PDP-10 memory) KS: 6MB (2MB program, 4MB emulated PDP-10 memory) Disk: .2-.3 GB per RP06, .5-.9 GB per RP07, 50+GB per dynamic RPxx Tape: optional, can use any variable-record-length drive Network: optional, LAN interface advised (can share single interface with native OS, but a second may be desirable) Performance: Varies with job mix and platform architecture, but general observations suggest the following ratios relative to a real PDP-10 (where 1.0 = KL10 speed): SPARC: (MHz / 200) Alpha: (MHz / 250) x86: (MHz / 200) Thus, a 450MHz x86 would provide slightly over 2x KL speed. IMPLEMENTATION ============== The KLH10 internals are organized in a fashion roughly similar to that of actual hardware. There is a "KN10" process equivalent to a KS10 or KL10 processor that carries out all CPU operations and is continuously running, except when the KLH10 user-interface command parser has control. Most importantly, each hardware device is implemented as a separate subprocess, with optional direct access to main PDP-10 memory for data transfers. This architecture has several advantages: - It can take advantage of multi-processor host platforms. - The emulated CPU never needs to wait for I/O. This considerably speeds up operation, compared to a non-threaded emulator which must block on disk I/O. - It can directly use very slow physical devices such as magtape drives (half-inch, 8mm, 4mm, DLT, etc). Virtual tapes (i.e. tape images on disk) are also supported. - The sub-process implementation is more portable and robust than a threaded implementation. - Device failures need not be fatal. The NIA20 network device for example can be reloaded and restarted without stopping the KN10 or the TOPS monitor. TERMINOLOGY =========== There are two terms used in the documentation and source that may cause confusion: KLH10 and KN10. "KLH10" refers to the entire software product covered by the license. This is theoretically a proper name ("KLH10 has") but is often used as an object name ("the KLH10 has"). "KN10" refers to the virtual PDP-10 created at runtime by the "kn10" executable image. It is specifically intended to serve as an object name alongside the physical PDP-10s KA10, KI10, KL10, and KS10. Nearly all software products are referred to like people (ITS, Emacs, Oracle, Solaris, etc) and the same can be done with "KLH10". However, to emphasize that it emulates a hardware device, it is often still referred to as an object -- "the KLH10". In fact this objectification urge is so strong that it is actually difficult to avoid using the articles "the" and "a". The term "KN10" was invented to help maintain the distinction between the product and the virtual machine/object. I will let others speculate on why English is this way.