DOCSLIB.ORG

System Programming in a High Level Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

System Programming in a High Level Language Andrew D Birrell Dissertation submitted for the degree of Doctor of Philosophy in the University of Cambridge, December 1977. Except where otherwise stated in the text, this dissertation is the result of my own work, and is not the outcome of work done in collaboration. Copyright © A.D.Birrell, 1977 Acknowledgements The work described in this dissertation has been supported by the Science Research Council. It would not have been possible without the support and encouragement of Brenda, and of my supervisor Roger Needham, and of my head of department, Professor M.V.Wilkes. In particular, Brenda showed particular diligence in typing this document, and perseverance in encouraging me to write it. The paper reproduced as Appendix Y was first published as an invited paper at the 1977 conference on Algol68 at the University of Strathclyde [40]. Contents Section A: Introduction 1. The Problem 1.1 Aims and Requirements 1.2 High Level Language Requirements 1.3 System Programming Language Requirements 1.4 The Present Approach 2. Background 2.1 The Algol68C Project 2.2 The CAP Project Section B: High Level Language Implementation 1. Today's Algol68C System 2. Separate Compilation Mechanisms 2.1 Requirements 2.2 Separate Compilation in Algol68C 2.3 Separate Compilation in Other Systems 2.4 A Complete Separate Compilation Scheme 3. Compiler Portability 3.1 Other Intermediate Codes 3.2 Portability in Algol68C 3.3 Summary and Conclusions Section C: System Programming Facilities 1. Runtime System 1.1 The CAP Algol68C Runtime System 2. Hardware Objects and Operations 2.1 Storage Allocation 2.2 New Data-types 2.3 Conclusions 3. The 'Program' 3.1 Program Structure 3.2 Program Environment Section D: Summary and Conclusions Appendix X: CAP Algol68C Documentation Appendix Y: Storage Management for Algol68 Appendix Z: Cap Project Notes Section A: Introduction 1 The Problem 1.1 Aims and Requirements This thesis is concerned with the construction of a high level language system suitable for the implementation of a general purpose operating system for a computer. There are three aspects to this task: firstly, a suitable high level language must be chosen or designed; secondly, a suitable implementation of this language must be manufactured; thirdly, the operating system itself must be written. These three aspects inevitably overlap in time - experience in implementing the language may cause one to review decisions taken in the design of the language, and experience in constructing the operating system will bring to light inadequacies, inconveniences and inelegancies in both the implementation and the language. Most previous work in this field has been concerned with the first of these aspects, and has adopted the approach of designing special-purpose languages, categorized as 'System Programming Languages' (SPL's) or 'Machine Oriented Languages' (MOL's). Various such languages have been developed, some of which are discussed below. Few such languages have achieved the elegance or generality of ordinary general-purpose languages such as Pascal or Algol68. Little or no investigation has previously - 1 - been made into the second of these aspects, the implementation of the language. The implementation, as distinct from the language, can have a very considerable effect on the practicability of using the resulting language system for manufacturing an operating system. Certainly, there are languages which, however brilliant the implementation, would inevitably be disastrous for writing an operating system; but the implementation, however suitable the language, makes the difference between the language system being an aid or an impediment to the system programmer. It is with aspects of the implementation that this thesis is mainly concerned. It should be emphasised that we are considering the real construction of an operating system on physical hardware without sophisticated external support. The 'language system' must not amount to a simulation package, nor include facilities which would normally be considered part of the operating system (such as in Simula or Concurrent Pascal), unless those facilities are themselves implemented using a high level language (they could then be considered to be part of the operating system). It is a principle of the design that the language system should not contain imbedded design decisions which would be more properly considered as part of the design of the operating system - it should be a tool, not an integral part of the operating system. Also, since we are providing a general purpose operating system, user programs can be written in any language - we are not assuming a single-language operating system. - 2 - When embarking on the production of a suitable language system, we must at an early stage make a fundamental decision: whether to base the work on an existing high level language which can be modified as necessary, or whether to construct a new language from scratch. If we adopt the latter alternative, we will inevitably design a special-purpose language and follow in the footsteps of BLISS et al. In fact, I have adopted the former alternative. This leads to new ground: we must decide to what extent modifications to the language are needed, and this should enable us to decide which factors in the design of a suitable language arise peculiarly from writing an operating system, and which arise from the normal requirements of a non-numerical program. Also, when following this path we can investigate the extent to which suitable implementation techniques can aid us in achieving our aims with minimal special purpose modifications to the language. The language system produced was intended to be used (and is used) for an operating system for the Cambridge CAP computer. This computer, and its operating system, have many unusual fea- tures, but the techniques and facilities developed for the language system are not especially CAP-oriented - they have applicability to many other machines and environments. - 3 - 1.2 Use of Normal High Level Language Facilities The advantages of using a high-level language instead of machine-code are numerous and well known; they amount to saying that, when writing in a high-level language, it is easier to write programs, more difficult to write faulty ones, and when you have written a faulty program you discover the fault sooner. We are not much concerned here with faulty programs (although much of the distinction between a 'good' and a 'bad' implementation of a language lies in what it will do with a faulty program), but it must always be borne in mind when considering any topic in language design or implementation that a programmer must be told as early as possible of any mistake. As far as possible, all error checking should be performed at compile time, and we must always try to have sufficient redundancy in constructs for a simple mistake to be detectable. Error detection is one of the major gains in using a high level language, but first we must be able to express our problem conveniently. Much system programming is amenable to writing in a normal high level language with no particular trouble. Such operations as converting a textual file title into a disc address are merely mathematical mappings (albeit somewhat complicated ones), and can be implemented using techniques remarkably similar to those used in any non-numerical computing. A programmer implementing such algorithms is involved in the task of taking a single, complicated operation and breaking it into several simpler ones. - 4 - When writing in machine code, he is forced to resolve the problem into particular bit or word manipulations allowed by his particular hardware and operating environment; when writing in a high level language, such drastic measures are not forced upon him, since he has available to him operations which are less basic. A high level language makes available to the programmer sets of abstract objects, which he can consider not in terms of his hardware and operating system, but purely in terms of the objects, their relationships to each other, and the operations he can perform upon them. For almost all of almost every system program, it is sufficient to express the algorithm in such abstract terms - it is extremely rare for the programmer to require to manipulate non-abstract (hardware or system oriented) objects or operations. Expressing algorithms in such abstract terms clearly has many advantages. If the abstract objects and operations are suitable, it will be much easier to convert an algorithm into them than into the machine objects, purely because they involve 'higher level' concepts more closely related to the original algorithm. For example, indexing an array is more closely related to table look-up than is adding a fixed point integer, multiplied by the amount of store-per-element, to the base address of a sequence of elements; indeed, the programmer can use the abstract facility without knowing how it is implemented today. Thus, a suitable set of abstractions will be ones which would be encountered while converting the abstract algorithm into machine code - using the abstractions saves a step - 5 - in the conversion. If the algorithm can be expressed purely in terms of the abstractions, then it has no dependency on the hardware or operating environment. This has several beneficial consequences: firstly, it implies that the programmer has not made a mistake in mapping his objects onto the hardware (all such mistakes are centralised in the compiler!); secondly, the hardware can change without affecting his program (for a system program, the gain here is that the program can be developed on a different computer, or before the hardware of the target computer has stabilised); thirdly, the operating system interfaces can change (this is quite likely to happen during the development of a system, and having consequently to rewrite all the programs, rather than just recompile them, would be unfortunate).
Recommended publications
  • A Bare Machine Sensor Application for an ARM Processor

    A Bare Machine Sensor Application for an ARM Processor

    A Bare Machine Sensor Application for an ARM Processor Alexander Peter, Ramesh K. Karne and Alexander L. Wijesinha Department of Computer & Information Sciences Towson, MD 21252 [email protected], (rkarne, awijesinha)@towson.edu Abstract- Sensor devices that monitor environmental changes in In order to build a bare machine temperature sensor device temperature, sound, light, vibration and pressure usually run application, it requires several components as shown in Fig. 1. applications that require the support of a small operating system, A brief functional description of this application is as follows. lean kernel, or an embedded system. This paper presents a The application is loaded from the SD Card interface (Label 9) methodology for developing sensor device applications that can into memory using U-Boot. A temperature sensor (Label 1) is be directly run on the bare hardware without any need for middleware. Such bare sensor device applications only depend plugged into the ADB to monitor the current room on the underlying processor architecture, enabling them to run temperature with a sensing granularity of 900 microseconds. on a variety of devices. The methodology is used for developing, As the temperature changes, its value (Label 8) and a graphic designing, and implementing a temperature sensor application image (Label 7) is displayed on the LCD screen (Label 2). An that runs on an ARM processor. The same methodology can be output console is used to debug the inner working of the ADB used to build other bare machine sensor device applications for and temperature (Label 3). An LED light (Label 4) provides a ARM processors, and is easily extended to different processor visual indication of temperature sensor operation.
  • Operating Systems Privileged Instructions

    Operating Systems Privileged Instructions

    November 2, 1999 Operating Systems • Operating systems manage processes and resources • Processes are executing instances of programs may be the same or different programs process 1 process 2 process 3 code code code data data data SV SV SV state vector: information necessary to start, stop, and restart the process • State vector: registers, program counter, memory mgmt registers, etc. user-level processes assembly & high-level languages operating system, “kernel” machine language & system calls bare machine machine language Copyright 1997 Computer Science 217: Operating System Page 187 November 2, 1999 Privileged Instructions • Machines have two kinds of instructions 1. “normal” instructions, e.g., add, sub, etc. 2. “privileged” instructions, e.g., initiate I/O switch state vectors or contexts load/save from protected memory etc. • Operating systems hide privileged instructions and provide virtual instructions to access and manipulate virtual resources, e.g., I/O to and from disc files • Virtual instructions are system calls • Operating systems interpret virtual instructions Copyright 1997 Computer Science 217: Operating System Page 188 November 2, 1999 Processor Modes • Machine level typically has 2 modes, e.g., “user” mode and “kernel” mode • User mode processor executes “normal” instructions in the user’s program upon encountering a “privileged” instruction, processor switches to kernel mode, and the operating system performs a service • Kernel mode processor executes both normal and privileged instructions • User-to-kernel switch
  • MIPS: the Virtual Machine

    MIPS: the Virtual Machine

    2 MIPS: The Virtual Machine Objectives After this lab you will know: • what are synthetic instructions • how synthetic instructions expand to sequences of native instructions • how MIPS addresses the memory Note: You can use PCSpim using the menu items instead of individual console commands. Familiarize yourself with PCSpim. Introduction MIPS is a ‘typical’ RISC architecture: it has a simple and regular instruction set, only one memory addressing mode (base plus displacement) and instructions are of fixed size (32 bit). Surprisingly, it is not very simple to write assembly programs for MIPS (and for any RISC machine for that matter). The reason is that programming is not supposed to be done in assembly language. The instruction sets of RISC machines have been designed such that: • they are good targets for compilers (thus simplifying the job of compiler writers) • they allow a very efficient implementation (pipelining) Pipelining means that several instructions are present in the CPU at any time, in various stages of execution. Because of this situation it is possible that some sequences of instructions just don’t work the way they are listed on paper. For instance Ex 1: lw $t0, 0($gp) # $t0 <- M[$gp + 0] add $t2, $t2, $t0 # $t2 <- $t2 + $t0 loads a word from memory in register $t0 and then adds it, in the next instruction, to register $t2. The prob- lem here is that, by the time the add instruction is ready to use register $t0, the value of $t0 has not changed yet. This is not to say that the load instruction (lw) has not completed.
  • Latest Results from the Procedure Calling Test, Ackermann's Function

    Latest Results from the Procedure Calling Test, Ackermann's Function

    Latest results from the procedure calling test, Ackermann’s function B A WICHMANN National Physical Laboratory, Teddington, Middlesex Division of Information Technology and Computing March 1982 Abstract Ackermann’s function has been used to measure the procedure calling over- head in languages which support recursion. Two papers have been written on this which are reproduced1 in this report. Results from further measurements are in- cluded in this report together with comments on the data obtained and codings of the test in Ada and Basic. 1 INTRODUCTION In spite of the two publications on the use of Ackermann’s Function [1, 2] as a mea- sure of the procedure-calling efficiency of programming languages, there is still some interest in the topic. It is an easy test to perform and the large number of results ob- tained means that an implementation can be compared with many other systems. The purpose of this report is to provide a listing of all the results obtained to date and to show their relationship. Few modern languages do not provide recursion and hence the test is appropriate for measuring the overheads of procedure calls in most cases. Ackermann’s function is a small recursive function listed on page 2 of [1] in Al- gol 60. Although of no particular interest in itself, the function does perform other operations common to much systems programming (testing for zero, incrementing and decrementing integers). The function has two parameters M and N, the test being for (3, N) with N in the range 1 to 6. Like all tests, the interpretation of the results is not without difficulty.
  • Address Translation

    Address Translation

    CS 152 Computer Architecture and Engineering Lecture 8 - Address Translation John Wawrzynek Electrical Engineering and Computer Sciences University of California at Berkeley http://www.eecs.berkeley.edu/~johnw http://inst.eecs.berkeley.edu/~cs152 9/27/2016 CS152, Fall 2016 CS152 Administrivia § Lab 2 due Friday § PS 2 due Tuesday § Quiz 2 next Thursday! 9/27/2016 CS152, Fall 2016 2 Last time in Lecture 7 § 3 C’s of cache misses – Compulsory, Capacity, Conflict § Write policies – Write back, write-through, write-allocate, no write allocate § Multi-level cache hierarchies reduce miss penalty – 3 levels common in modern systems (some have 4!) – Can change design tradeoffs of L1 cache if known to have L2 § Prefetching: retrieve memory data before CPU request – Prefetching can waste bandwidth and cause cache pollution – Software vs hardware prefetching § Software memory hierarchy optimizations – Loop interchange, loop fusion, cache tiling 9/27/2016 CS152, Fall 2016 3 Bare Machine Physical Physical Address Inst. Address Data Decode PC Cache D E + M Cache W Physical Memory Controller Physical Address Address Physical Address Main Memory (DRAM) § In a bare machine, the only kind of address is a physical address 9/27/2016 CS152, Fall 2016 4 Absolute Addresses EDSAC, early 50’s § Only one program ran at a time, with unrestricted access to entire machine (RAM + I/O devices) § Addresses in a program depended upon where the program was to be loaded in memory § But it was more convenient for programmers to write location-independent subroutines How
  • Microkernels Meet Recursive Virtual Machines

    Microkernels Meet Recursive Virtual Machines

    Microkernels Meet Recursive Virtual Machines Bryan Ford Mike Hibler Jay Lepreau Patrick Tullmann Godmar Back Stephen Clawson Department of Computer Science, University of Utah Salt Lake City, UT 84112 [email protected] http://www.cs.utah.edu/projects/flux/ Abstract “vertically” by implementing OS functionality in stackable virtual machine monitors, each of which exports a virtual This paper describes a novel approach to providingmod- machine interface compatible with the machine interface ular and extensible operating system functionality and en- on which it runs. Traditionally, virtual machines have been capsulated environments based on a synthesis of micro- implemented on and export existing hardware architectures kernel and virtual machine concepts. We have developed so they can support “naive” operating systems (see Fig- a software-based virtualizable architecture called Fluke ure 1). For example, the most well-known virtual machine that allows recursive virtual machines (virtual machines system, VM/370 [28, 29], provides virtual memory and se- running on other virtual machines) to be implemented ef- curity between multiple concurrent virtual machines, all ficiently by a microkernel running on generic hardware. exporting the IBM S/370 hardware architecture. Further- A complete virtual machine interface is provided at each more, special virtualizable hardware architectures [22, 35] level; efficiency derives from needing to implement only have been proposed, whose design goal is to allow virtual new functionality at each level. This infrastructure allows machines to be stacked much more efficiently. common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to This paper presents a new approach to OS extensibil- be provided by cleanly modularized, independent, stack- ity which combines both microkernel and virtual machine able virtual machine monitors, implemented as user pro- concepts in one system.
  • ALGOL 60 Programming on the Decsystem 10.Pdf

    ALGOL 60 Programming on the Decsystem 10.Pdf

    La Trobe University DEPARTMENT OF MATHEMATICS ALGOL 60 Programming on the DECSystem 10 David Woodhouse Revised, August 1975 MELBOURNE, AUSTRALIA ALGOL 60 Programming on the DECSystem 10 David Woodhouse Revised, August 1975 CE) David Woodhouse National Library of Australia card number and ISBN. ISBN 0 85816 066 8 INTRODUCTION This text is intended as a complete primer on ALGOL 60 programming. It refers specifically to Version 4 of the DECSystem 10 implementation. However, it avoids idiosyncracies as far as possible, and so should be useful in learning the language on other machines. The few features in the DEC ALGOL manual which are not mentioned here should not be needed until the student is sufficiently advanced to be using this text for reference only. Exercises at the end of each chapter illustrate the concepts introduced therein, and full solutions are given. I should like to thank Mrs. K. Martin and Mrs. M. Wallis for their patient and careful typing. D. Woodhouse, February, 1975. CONTENTS Chapter 1 : High-level languages 1 Chapter 2: Languagt! struct.ure c.f ALGOL 6n 3 Chapter 3: Statemp.nts: the se'1tences {'\f the language 11 Chapter 4: 3tandard functions 19 Chapter 5: Input an~ Outp~t 21 Chapter 6: l>rray~ 31 Chapter 7 : For ane! ~hil~ statements 34 Chapter 8: Blocks anr! ',: ock sc rll,~ turr. 38 Chapter 9: PrOCe(:l1-:-~S 42 Chapter 10: Strin2 vp·jaLlps 60 Chapter 11: Own v~rj;lI'.i..es clOd s~itc.hef, 64 Chapter 12: Running ~nd ,;ebllggi"1g 67 Bibliography 70 Solutions to Exercises 71 Appendix 1 : Backus NOlUlaj F\:q'm 86 Appendix 2 : ALGuL-like languages 88 Appenclix 3.
  • A Lean USB File System for Bare Machine Applications

    A Lean USB File System for Bare Machine Applications

    A Lean USB File System for Bare Machine Applications Songjie Liang Ramesh K. Karne Alexander L. Wijesinha Department of Computer and Department of Computer and Department of Computer and Information Sciences Information Sciences Information Sciences Towson University Towson University Towson University Towson, Maryland, USA Towson, Maryland, USA Towson, Maryland, USA [email protected] [email protected] [email protected] Abstract USB file management systems for mass storage are and then describe the design of the bare file system, supported on many platforms and commonly used today by including disk map, root directory, sequencing operations, a variety of applications. These file systems vary depending tasks, and user interface. The file system runs on an Intel upon the underlying operating system and environment. We x86 based bare PC. For comparison purposes, essentially consider the design of a USB file system that is the same system, but with minimal system calls, was independent of any operating system or application implemented on a Linux OS. environment. Specifically, we describe the design and development of a lean USB file system for supporting bare The rest of the paper is organized as follows. Section II PC applications that run with no OS or kernel support of considers related work, and Section III describes the lean any kind, and give details of its architecture, design, and file management system. Section IV discusses architecture implementation. Our design leverages the design and issues, Section V narrates some design details, Section characteristics and inherent features of USB mass storage. VI shows implementation, Section VII outlines novel Bare machine USB file management systems enable features of our approach, Section VIII deals with functional computer applications to access mass storage at run-time operation and testing, and Section IX presents the without the operating system and environmental conclusion.
  • On Design and Implementation of an Embedded System for Neural-Machine Interface for Artificial Legs

    On Design and Implementation of an Embedded System for Neural-Machine Interface for Artificial Legs

    University of Rhode Island DigitalCommons@URI Open Access Dissertations 2013 On Design and Implementation of an Embedded System for Neural-Machine Interface for Artificial Legs Xiaorong Zhang University of Rhode Island, [email protected] Follow this and additional works at: https://digitalcommons.uri.edu/oa_diss Recommended Citation Zhang, Xiaorong, "On Design and Implementation of an Embedded System for Neural-Machine Interface for Artificial Legs" (2013). Open Access Dissertations. Paper 23. https://digitalcommons.uri.edu/oa_diss/23 This Dissertation is brought to you for free and open access by DigitalCommons@URI. It has been accepted for inclusion in Open Access Dissertations by an authorized administrator of DigitalCommons@URI. For more information, please contact [email protected]. ON DESIGN AND IMPLEMENTATION OF AN EMBEDDED SYSEM FOR NEURAL-MACHINE INTERFACE FOR ARTIFICIAL LEGS BY XIAORONG ZHANG A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY IN COMPUTER ENGINEERING UNIVERSITY OF RHODE ISLAND 2013 DOCTOR OF PHILOSOPHY DISSERTATION OF XIAORONG ZHANG APPROVED: Dissertation Committee: Major Professor Qing Yang He Huang Joan Peckham Nasser H. Zawia DEAN OF THE GRADUATE SCHOOL UNIVERSITY OF RHODE ISLAND 2013 ABSTRACT According to limb loss statistics, there are over one million leg amputees in the US whose lives are severely impacted by their conditions. In order to improve the quality of life of patients with leg amputations, neural activities have been studied by many researchers for intuitive prosthesis control. The neural signals collected from muscles are electromyographic (EMG) signals, which represent neuromuscular activities and are effective bioelectrical signals for expressing movement intent.
  • A History of C++: 1979− 1991

    A History of C++: 1979− 1991

    A History of C++: 1979−1991 Bjarne Stroustrup AT&T Bell Laboratories Murray Hill, New Jersey 07974 ABSTRACT This paper outlines the history of the C++ programming language. The emphasis is on the ideas, constraints, and people that shaped the language, rather than the minutiae of language features. Key design decisions relating to language features are discussed, but the focus is on the overall design goals and practical constraints. The evolution of C++ is traced from C with Classes to the current ANSI and ISO standards work and the explosion of use, interest, commercial activity, compilers, tools, environments, and libraries. 1 Introduction C++ was designed to provide Simula’s facilities for program organization together with C’s effi- ciency and flexibility for systems programming. It was intended to deliver that to real projects within half a year of the idea. It succeeded. At the time, I realized neither the modesty nor the preposterousness of that goal. The goal was modest in that it did not involve innovation, and preposterous in both its time scale and its Draco- nian demands on efficiency and flexibility. While a modest amount of innovation did emerge over the years, efficiency and flexibility have been maintained without compromise. While the goals for C++ have been refined, elaborated, and made more explicit over the years, C++ as used today directly reflects its original aims. This paper is organized in roughly chronological order: §2 C with Classes: 1979– 1983. This section describes the fundamental design decisions for C++ as they were made for C++’s immediate predecessor. §3 From C with Classes to C++: 1982– 1985.
  • The BCPL Cintsys and Cintpos User Guide by Martin Richards Mr10@Cl.Cam.Ac.Uk

    The BCPL Cintsys and Cintpos User Guide by Martin Richards [email protected]

    The BCPL Cintsys and Cintpos User Guide by Martin Richards [email protected] http://www.cl.cam.ac.uk/users/mr10/ Computer Laboratory University of Cambridge Revision date: Thu 19 Aug 16:16:54 BST 2021 Abstract BCPL is a simple systems programming language with a small fast compiler which is easily ported to new machines. The language was first implemented in 1967 and has been in continuous use since then. It is a typeless and provides machine independent pointer arithmetic allowing a simple way to represent vectors and structures. BCPL functions are recursive and variadic but, like C, do not allow dynamic free variables, and so can be represented by just their entry addresses. There is no built-in garbage collector and all input-output is done using library calls. This document describes both the single threaded BCPL Cintcode System (called Cintsys) and the Cintcode version of the Tripos portable operating system (called Cintpos). It gives a definition of the standard BCPL language including the recently added features such as floating point expressions and constructs involving operators such as <> and op:=. This manual describes an extended version of BCPL that include some of the features of MCPL, mainly concerning the pattern matching used in function definitions. This version can be compiled using the mbcpl command. This manual also describes the standard library and running environment. The native code version of the system based on Sial and the Cintpos portable operating system are also described. Installation instructions are included. Since May 2013, the standard BCPL distribution supports both 32 and 64 bit Cintcode versions.
  • User|Mjs Guide

    User|Mjs Guide

    Tivoli® Storage Manager FastBack for Bare Machine Recovery Version 6.1.1.0 Tivoli Storage Manager FastBack for Bare Machine Recovery User's Guide SC27-2308-05 Tivoli® Storage Manager FastBack for Bare Machine Recovery Version 6.1.1.0 Tivoli Storage Manager FastBack for Bare Machine Recovery User's Guide SC27-2308-05 Note Before using this information and the product it supports, read the information in “Notices” on page 35. This edition applies to version 6, release 1, modification 1 of IBM Tivoli Storage Manager FastBack for Bare Machine Recovery (product number 5724-U95) and to all subsequent releases and modifications until otherwise indicated in new editions. This edition replaces SC27-2308-04. © Copyright IBM Corporation 2008, 2010. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Preface ...............v Using the FastBack for Bare Machine Recovery CD Who should read this guide .........v for bare machine recovery on your Windows system 13 Publications ..............v Using the Any-to-Any Hardware Restore utility 16 Support information ............v Restoring a disk using the non-system disk restore 18 Getting technical training .........v Scenarios using Tivoli Storage Manager FastBack . 19 Searching knowledge bases ........v Using a single system for client and server ....20 Contacting IBM Software Support ......vi | Restoring from a Tivoli Storage Manager FastBack Conventions used in this information .....viii | repository located on a Tivoli Storage Manager Documentation changes ..........viii || server ................20 | Using Tivoli Storage Manager FastBack for Bare Chapter 1. Overview .........1 || Machine Recovery on your Linux system ....21 Supported environments ..........2 Access permissions ............5 Chapter 4.