CACAO a Bit Javavm JustInTime Compiler

Total Page:16

File Type:pdf, Size:1020Kb

CACAO � a �� Bit Javavm Just�In�Time Compiler CACAO A bit JavaVM JustinTime Compiler Andreas Krall and Reinhard Gra Institut fur Computersprachen Technische Universitat Wien Argentinierstrae A Wien httpwwwcomplangtuwienacatandi Abstract for native co de compilation since it is more p ortable and gives more opp ortunities for improving the execu tion sp eed Compiling to native co de can b e done in This article describ es the design and implementation of two dierent ways compilation of the complete pro CACAO a just in time compiler for Java The CACAO gram in advance or compilation on demand of only the system translates Java byte co de on demand into native functions which are executed just in time compiler co de for the ALPHA pro cessor During this transla JIT Our JIT compiler is describ ed in detail in Gra tion pro cess the stack oriented Java byte co de is trans in German and is freely available via the world wide formed into a register oriented intermediate co de Lo web cal variables and stack lo cations are replaced by pseudo registers eliminating the bit restriction on address typ es A fast register allo cation algorithm is applied to Previous Work map the pseudo registers to machine registers During co de generation eld osets are computed for prop er The idea of machine indep endent program represen alignment on bit architectures Even though the tations is quite old and go es back to the year CACAO system has to incur loading and compilation TBS An intermediate language UNCOL UNiver time it executes Java programs up to times faster sal Computer Oriented Language was prop osed for than the JDK interpreter up to times faster than the use in compilers to reduce the development eort of kae JIT compiler It is slightly slower than equivalent compiling many dierent languages to many dierent C programs compiled at the highest optimization level architectures The design of the JavaVM has b een strongly inuenced by P co de the abstract machine used by many Pascal implementations PD P co de Intro duction is well known from its use in the UCSD Pascal system There have even b een eorts to develop micropro ces Javas AG success as a programming language re sors which execute P co de directly sults from its role as an Internet programming lan The Amsterdam compiler kit TvSKS TKLJ guage The basis for this success is the machine inde uses a stack oriented intermediate language This lan p endent distribution format of programs with the Java guage has b een designed for fast compilers which emit virtual machine LY The standard interpretive im ecient co de The intermediate representation of the plementation of the Java virtual machine makes execu Gardens Point compiler pro ject is also based on a stack tion of programs slow This do es not matter if small machine called Dcode Gou Dcode was inuenced applications are executed in a browser but b ecomes by Pascal P co de Both Dcode interpreters and co de intolerable if big applications are executed There are generators for dierent architectures exist two solutions to solve this problem The problems of compiling a stack oriented abstract machine co de to native co de are well known from the sp ecialized JavaVM pro cessors programming language Forth In Ert and his thesis compilation of byte co de to the native co de of a Ert Ertl describ es RAFTS a Forth system that gen standard pro cessor erates native co de at run time Translating the stack op erations to native co de is done by translating the SUN to ok b oth paths and is developing b oth Java op erations back to expressions represented as directed pro cessors and native co de compilers We chose to go acyclic graphs as an intermediate step In EM he translates Forth to native co de using C as an interme only correct programs The following examples show diate language In this system the stack slots are trans some imp ortant JavaVM instructions and how a Java lated to lo cal variables of a function Optimization and program is represented by these instructions co de generation are p erformed by the C compiler x push integer constant with value x iconst iload n load contents of lo cal variable n In his thesis Fra Franz claims that generating istore n store stack top in lo cal variable n native co de on the y at load time is faster than loading iadd sum of two topmost stack elements a much bigger native co de image from a oppy or hard imul pro duct of topmost stack elements disk Franz uses a compressed representation of the abstract syntax tree as an intermediate representation The Java assignment statement a b c is trans Generating native co de is so fast that this idea has b een lated into extended to dynamic run time reoptimization Kis Sp ecializing and optimizing co de at run time is also iload b load contents of variable b p erformed in the Self system US and in some Prolog iload c load contents of variable c systems KB iadd compute b c The rst implementations of JIT compilers b ecame istore a store stack top in variable a available last year for the browsers from Netscap e and Microsoft on PCs They were followed by Syman Figure shows the contents of the stack b efore and tecs development environment Recently SUN released after execution of each instruction Prior to the rst a JIT compiler for the Sparc and PowerPC pro ces instruction and after the last instruction the stack is sors Silicon Graphics develop ed a JIT compiler for empty the MIPS pro cessor A public domain JIT compiler for several architec tures is the kae system develop ed by Tim Wilkinson httpwwwkaffeorg For all the ab ove men tioned systems no publicly available description of the c compilation techniques exists b b c b The translation scheme of the Caeine system is de iload b iload c iadd istore a scrib ed in HGmWH It supp orts b oth a simple translation scheme which emulates the stack architec Figure JavaVM stack op erations ture and a more sophisticated one which eliminates the stack completely and uses registers instead Caeine is not intended as a JIT compiler It compiles a complete The iload b instruction pushes the contents of the program in advance DAISY Dynamically Architected lo cal variable b onto the stack iload c works in a Instruction Set from Yorktown is a VLIW architecture similar way iadd adds the two elements at the top of develop ed at IBM for fast execution of x PowerPC the stack p ops these two values and pushes the sum S and JavaVM co de Compatibility with dierent onto the stack The istore a writes the value at the old architectures is achieved by using a JIT compila topmost stack p osition into the lo cal variable a and tion technique The JIT compilation scheme for the p ops this value JavaVM is describ ed in EAH Accessing the elds of ob jects is handled by the in structions getfield and putfield getfield exp ects an ob ject reference on the stack and has an index into The Java Virtual Machine the constant p o ol as an op erand The index into the constant p o ol must b e a reference to a pair contain The JavaVM is a typ ed stack architecture LY ing the class name and a eld name The typ es of the There are dierent instructions for integer long inte classes referenced by the constant p o ol index and by ger oating p oint and address typ es Byte and charac the ob ject reference must b e compatible a fact which ter typ es have only sp ecial memory access instructions is usually checked statically at load time The ob ject and are treated as integers for arithmetic op erations reference has to b e dierent from the null p ointer a The main instruction set consists of arithmeticlogical fact which must usually b e checked at run time and loadstoreconstant instructions There are sp e Array access is handled by the aload and astore cial instructions for array access and for accessing the instructions Separate versions of these instructions elds of ob jects memory access for metho d invo ca exist for each of the basic typ es byte int float tion function call and typ e checking A JavaVM has ref etc The aload instruction exp ects a reference to check the program for typ e correctness and executes to an array and an index of typ e int on the stack Translation to Register Form The array reference must not b e the null p ointer The index must b e greater than or equal to zero and less The architecture of a RISC pro cessor is completely dif than the array length ferent from the stack architecture of the JavaVM RISC pro cessors have large sets of registers The Alpha has The Java metho d invo cation oprinta is integer registers and oating p oint registers which translated into are b oth bits wide They execute arithmetic and aload o load object pointer o logic op erations only on values which are held in regis iload a load contents of variable a ters Load and store instructions are provided to move iconst push constant data b etween memory and registers Lo cal variables iadd compute a of metho ds usually reside in registers and are saved in invokevirtual print call oprint memory only during a metho d call or if there are to o few registers If JavaVM co de is translated to machine co de the stack is eliminated and temp orary registers replace the stack slots a a a Machine co de translation examples o o o o aload o iload a iconst iadd invoke The example expression a b c d has the JavaVM co de Figure JavaVM metho d invo cation iload b load contents of variable b iload c load contents of variable c Figure shows the contents of the stack for a metho d imul compute b c invo cation Each metho d has its own virtual stack and iload d load contents of variable d an area
Recommended publications
  • Embedded Linux Systems with the Yocto Project™
    OPEN SOURCE SOFTWARE DEVELOPMENT SERIES Embedded Linux Systems with the Yocto Project" FREE SAMPLE CHAPTER SHARE WITH OTHERS �f, � � � � Embedded Linux Systems with the Yocto ProjectTM This page intentionally left blank Embedded Linux Systems with the Yocto ProjectTM Rudolf J. Streif Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales depart- ment at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. Visit us on the Web: informit.com Cataloging-in-Publication Data is on file with the Library of Congress.
    [Show full text]
  • Rmox: a Raw-Metal Occam Experiment
    Communicating Process Architectures – 2003 269 Jan F. Broenink and Gerald H. Hilderink (Eds.) IOS Press, 2003 RMoX: A Raw-Metal occam Experiment Fred BARNES†, Christian JACOBSEN† and Brian VINTER‡ † Computing Laboratory, University of Kent, Canterbury, Kent, CT2 7NF, England. {frmb2,clj3}@kent.ac.uk ‡ Department of Mathematics and Computer Science, University of Southern Denmark, Odense, Denmark. [email protected] Abstract. Operating-systems are the core software component of many modern com- puter systems, ranging from small specialised embedded systems through to large distributed operating-systems. This paper presents RMoX: a highly concurrent CSP- based operating-system written in occam. The motivation for this stems from the overwhelming need for reliable, secure and scalable operating-systems. The major- ity of operating-systems are written in C, a language that easily offers the level of flexibility required (for example, interfacing with assembly routines). C compilers, however, provide little or no mechanism to guard against race-hazard and aliasing er- rors, that can lead to catastrophic run-time failure (as well as to more subtle errors, such as security loop-holes). The RMoX operating-system presents a novel approach to operating-system design (although this is not the first CSP-based operating-system). Concurrency is utilised at all levels, resulting in a system design that is well defined, easily understood and scalable. The implementation, using the KRoC extended oc- cam, provides guarantees of freedom from race-hazard and aliasing errors, and makes extensive use of the recently added support for dynamic process creation and channel mobility. Whilst targeted at mainstream computing, the ideas and methods presented are equally applicable for small-scale embedded systems — where advantage can be made of the lightweight nature of RMoX (providing fast interrupt responses, for ex- ample).
    [Show full text]
  • David T. C~Ai9 736 Edgewater [M J Wichita, Kansas 67230 (USA)
    _.., ,.i.'~...< ~~ ':' ..". PASCAL US~RS GROUP Pa.scal.N ews I.. NUMlsER ,< Iq COMMUNICATIONS ABOUT THE PROGRAMMING LANGUAGE PASCAL BVPASCALERS SE PT EMbER .,1980 ~,_v., j : ;,. ~ - EX LIBRIS: David T. C~ai9 736 Edgewater [M J Wichita, Kansas 67230 (USA) ' ... '-" .- . .. .,.- ... ., '-" -'. ..,. ...- .--'- -"--"'.". '. POLICY: PASCAL NEWS (15...Sep...80) * Pascal~ is the official but informal publication of the User's Group. * Pascal Newa contains all we (the editors) kriowabout Pascal; we use it as the vetlICIe to answer all inquiries because our physical energy and resources for answering individual requests are finite. As PUG grows, we unfortunately succumb to the reality of: 1. Having to insist that people ~o need to know "about Pascal" join PUG and read Pascal News - that is why we spend lime to produce, it! 2. Refusing to return phone calls or answer letters full of questions - we will pass the questions on to the readership of Pascal News. Please understand what the collective effect of individual inquirie8lias at the "concentrators" (our phones and mailboxes). We are trying honestly to say: "We cannot promise more that we can do." ' * Pascal News is produced 3 or4 times during a year; usually in March, June, September, and December. * ALL THE NEWS THAT'S FIT, WE PRINT .Please send material (brevity is a virtue) for Pascal News single-spaced and camera-ready (use dark ribbon and 18.5 em lines!) '. - ~ * Remember : ALL LETTERS TO US WILL BE PRINTED UNLESS THEY CONTAIN A REQUEST u TO THE CONTRARY. -.- * Pascal News is divided into flexible sections: o POLICY - explains the way we do things (ALL-PURPOSE COUPON, etc.) EDITOR'S CONTRIBUTION - passes along the opinion and point of view of the D.
    [Show full text]
  • Ucsd-Psystem-Fs UCSD P-System Filesystem Reference Manual
    ucsd-psystem-fs UCSD p-System Filesystem Reference Manual Peter Miller [email protected] . This document describes ucsd-psystem-fs version 1.22 and was prepared 21 July 2013. This document describing the ucsd-psystem-fs package, and the ucsd-psystem-fs utility pro- grams, are Copyright © 2006, 2007, 2008, 2010, 2011, 2012, 2013 Peter Miller This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) anylater version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without eventhe implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICU- LAR PURPOSE. See the GNU General Public License for more details. Youshould have receivedacopyofthe GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. 0 Table of Contents(ucsd-psystem-fs) Table of Contents(ucsd-psystem-fs) The README file . ................. 1 Release Notes ................... 2 Howtobuild ucsd-psystem-fs .............. 6 ucsdpsys_disk(1) manipulate files on a UCSD p-System filesystem image ...... 10 ucsdpsys_fsck(1) verify and repair UCSD p-System filesystem images ....... 13 ucsdpsys_fs_license(1) GNU General Public License ............... 14 ucsdpsys_interleave(1) decode interleavedUCSD p-System filesystem image ....... 23 ucsdpsys_mkfs(1) create newUCSD p-System filesystem disk images ........ 25 ucsdpsys_mount(1) mount aUCSD p-System filesystem . ........... 27 ucsdpsys_rt11(1) extract files from RT-11 disk images ............ 29 ucsdpsys_text(1) translate UCSD p-System text files . ............ 30 ucsdpsys_umount(1) unmount UCSD p-System filesystems .
    [Show full text]
  • Implementing the UCSD PASCAL System on the MODCOMP Computer
    TDA Progress Report 42-60 September and October 1960 Implementing the UCSD PASCAL System on the MODCOMP Computer T. Wolfe DSN Data Systems Section This article describes the UCSD PASCAL system developed by the University of California, San Diego, now available on the MODCOMP computer. The system includes a Pascal compiler and many useful utility programs. A BASIC compiler and a FORTRAN 77 compiler are also avatkble. There is currently a large amount of software availabie written in UCSD PASCAL, including a data base system, word processing systems and a MODULA compiler. I. Introduction Assembly language subroutines thus produced may also be called from either Pascal or FORTRAN. Currently the assem- The UCSD PASCAL* System is a complete interactive bler has not been modified to produce MODCOMP machine software development system consisting of an operating sys- code. A system library program may be used to build libraries tem, compilers (Pascal, BASIC, FORTRAN 77) two text of useful subroutines and the system linker used to link them editors (screen editor and line-oriented editor), a linker and to user programs. many useful utility programs. The system is written and main- tained in Pascal. The compiler generates code for an idealized processor known as the “pseudo-machine.” The “pseudo- Interpreters currently exist for Z80/8080, PDP 11 /LSI-1 1, code” (p-code) generated by the compiler is interpreted at 6800, 9900 and 6502 computers and are being developed for runtime by a program (known as the interpreter) which emu- other computers. Thus, software could be developed on an lates the pseudo-machine.
    [Show full text]
  • Computational PHYSICS Shuai Dong
    Computational physiCs Shuai Dong Evolution: Is this our final end-result? Outline • Brief history of computers • Supercomputers • Brief introduction of computational science • Some basic concepts, tools, examples Birth of Computational Science (Physics) The first electronic general-purpose computer: Constructed in Moore School of Electrical Engineering, University of Pennsylvania, 1946 ENIAC: Electronic Numerical Integrator And Computer ENIAC Electronic Numerical Integrator And Computer • Design and construction was financed by the United States Army. • Designed to calculate artillery firing tables for the United States Army's Ballistic Research Laboratory. • It was heralded in the press as a "Giant Brain". • It had a speed of one thousand times that of electro- mechanical machines. • ENIAC was named an IEEE Milestone in 1987. Gaint Brain • ENIAC contained 17,468 vacuum tubes, 7,200 crystal diodes, 1,500 relays, 70,000 resistors, 10,000 capacitors and around 5 million hand-soldered joints. It weighed more than 27 tons, took up 167 m2, and consumed 150 kW of power. • This led to the rumor that whenever the computer was switched on, lights in Philadelphia dimmed. • Input was from an IBM card reader, and an IBM card punch was used for output. Development of micro-computers modern PC 1981 IBM PC 5150 CPU: Intel i3,i5,i7, CPU: 8088, 5 MHz 3 GHz Floppy disk or cassette Solid state disk 1984 Macintosh Steve Jobs modern iMac Supercomputers The CDC (Control Data Corporation) 6600, released in 1964, is generally considered the first supercomputer. Seymour Roger Cray (1925-1996) The father of supercomputing, Cray-1 who created the supercomputer industry. Cray Inc.
    [Show full text]
  • Oral History Interview with John Brackett and Doug Ross
    An Interview with JOHN BRACKETT AND DOUG ROSS OH 392 Conducted by Mike Mahoney on 7 May 2004 Needham, Massachusetts Charles Babbage Institute Center for the History of Information Processing University of Minnesota, Minneapolis Copyright, Charles Babbage Institute John Brackett and Doug Ross Interview 7 May 2004 Oral History 392 Abstract Doug Ross and John Brackett focus on the background of SofTech and then its entry into the microcomputer software marketplace. They describe their original contact with the University of California at San Diego (UCSD) and licensing the p-System which had been developed there. They discuss the effort required to bring the program to production status and the difficulties in marketing it to the sets of customers. They talk about the transition from 8 bit to 16 bit machines and how that affected their market opportunities. They conclude with a review of the negotiations with IBM and their failure to get p-System to become a primary operating environment. That, and the high performance of Lotus 1-2-3, brought about the demise of the p- System. [John Brackett requested that the following information from Wikipedia, the free encyclopedia, be provided as an introduction to this oral history interview: “UCSD p-System or UCSD Pascal System was a portable, highly machine independent operating system based upon UCSD Pascal. The University of California, San Diego Institute for Information Systems developed it in 1978 to provide students with a common operating system that could run on any of the then available microcomputers as well as campus DEC PDP-11 minicomputers. UCSD p- System was one of three operating systems (along with PC-DOS and CP/M-86) that IBM offered for its original IBM PC.
    [Show full text]
  • Creating Ipsec and SSL/TLS Tunnels in Linux What's New
    FACEBOOK | WEBGOAT | TOR | DNS | SLEUTHKIT | PACKETFENCE LINUX JOURNAL ™ UU Getting the Most Out of GCC UU Securing Open-Source Phones SECURITY UU How to Store Passwords Safely UU New Column: Hack and / Since 1994: The Original Magazine of the Linux Community JANUARY 2008 | ISSUE 165 Facebook | WebGoat | Tor | DNS | Sleuthkit | PacketFence | GCC Qtopia SXE VPNs | DNS Sleuthkit PacketFence | Tor | WebGoat Facebook SECURITY UU Learn the Path to a More Secure System UU Use Autopsy and Sleuthkit to Analyse Security Breaches UU Discover Dangerous Flaws in Your DNS Infrastructure JANUARY www.linuxjournal.com 2008 Creating IPsec and SSL/TLS $5.99US $6.99CAN 01 ISSUE + Tunnels in Linux 165 What’s New with Eric Raymond? 0 74470 03102 4 lj023:lj018.qxd 11/12/2007 5:36 PM Page 1 The Straight Talk People SM SINCE 1991 ABERDEEN TRUE QUAD-CORE SERVERS. UP TO 16 INDIVIDUAL CORES. ABERDEEN STONEHAVEN A135 ABERDEEN STONEHAVEN A151 ABERDEEN STONEHAVEN A284 Four Quad-Cores 1U 3TB Quad Quad-Core HPC Server 1U 4TB Dual Quad-Core Server 2U 8TB Dual Quad-Core Server • Up to four Quad-Core AMD Opteron™ 8000 Series processors • Up to two Quad-Core AMD Opteron 2000 Series processors • Up to two Quad-Core AMD Opteron 2000 Series processors • nVIDIA nForce Pro Chipset with 64-Bit Support • nVIDIA nForce Pro Chipset with 64-Bit Support • nVIDIA nForce Pro Chipset with 64-Bit Support • Up to 64GB 667MHz ECC Registered DDR2 SDRAM • Up to 32GB 667MHz ECC Registered DDR2 SDRAM • Up to 64GB 667MHz ECC Registered DDR2 SDRAM • Up to 3 x 1TB (3TB Total) Hot-Swap SATA Hard
    [Show full text]
  • BULLETIN I of AVAILABLE TERAK SOFTWARE (Tugboats) the Terak User's Group Library Is a Clearing House Only; It Does Not Sell, Generate Or Test Prograns
    Vol. 2, Issue 1 01·Jan.·82 BULLETIN i OF AVAILABLE TERAK SOFTWARE (Tugboats) The Terak User's Group Library Is a clearing house only; It does not sell, generate or test prograns. All prograns and information are provided "AS IS". Terak User's Group and contributors of software disclaim all warranties on the prograns, Including without I Imitation, all Impl led warranties of merchantabtl ity and fitness. The description, service charges, and ayallabll tty of software available for the Terak User's Group Library are subject to change without notice. Copyright (C) 1982, Terak User's Group; Scottsdale, Arizona DEC, DECUS, RT-l1, PDP-l1 are all trademarks of DIgItal EquIpment CorporatIon. UCSD Pascal Is a trademark of the UnIversIty of CalIfornIa Board of Regents. Terak Is a trademark of the Terak CorporatIon. TABLE OF CONTENTS PAGE TOflCS Introduction •••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 1-1 TUGBOATS Updates •••••••••••••••••••••••••••••••••••••••••••••••••••••• 1-1 Ordering User Group Library Software •••••••••••••••••••••••••••••••••• 1-2 1. RT-ll Operating System •••••••••••••••••••••••••••••••••••••••••••••• 1-1 1.1 Languages •••••••••••••••••••••••••••••••••••••••••••••••••••••••• 1-1 1.2 Editors •••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 1-2 1.3 Device Handlers •••••••••••••••••••••••••••••••••••••••••••••••••• 1-3 1.4 Statistical Routines ••••••••••••••••••••••••••••••••••••••••••••• 1-4 1.5 Disk FormattIng •••••••••••••••••••••••••••••••••••••••••••••••••• 1-5 1.6 Utll Itfes ••••••••••••••••••••••••••••••••••••••••••••••••••••••••
    [Show full text]
  • A Port of the MINIX OS to the Powerpc Platform
    MinixPPC A port of the MINIX OS to the PowerPC platform Creating a programming model for architecture independency Master Thesis Computer Science Ingmar A. Alting September 15, 2006 First reader and supervisor: Andrew S. Tanenbaum Dept. of Computer Science Faculty of Sciences Vrije Universiteit De Boelelaan 1081A 1081 HV Amsterdam, the Netherlands e-mail: [email protected] Second reader: Herbert Bos Dept. of Computer Science Faculty of Sciences Vrije Universiteit Amsterdam De Boelelaan 1081A 1081 HV Amsterdam, the Netherlands e-mail: [email protected] Thesis by: Ingmar A. Alting Weth. W. de Boerstraat 18 1788AT Den Helder, the Netherlands email: [email protected] Abstract The main goal of this project is to indicate what it means to port an operating system from one architecture to another, and provide a programming paradigm that would make future ports easy and fast. The “natively” supported architecture of MINIX is the IBM PC compatible, that's built around the Intel architecture. This is a CISC architecture with hardware support for easy stack usage. The choice for the POWER architecture could not have been further away as this is a RISC architecture, and completely” different in many ways. This thesis will focuses on the model created for creating portable system code. Not to be confused with portable programs using a “standard” API. It will describe the changes made and problems faced porting the MINIX code base. The places where changes are made can be viewed as hotspots. For every new architecture compatibility problems are to be expected there. Some hotspots are used as example and the solution taken for MinixPPC is presented to the reader.
    [Show full text]
  • IT Acronyms.Docx
    List of computing and IT abbreviations /.—Slashdot 1GL—First-Generation Programming Language 1NF—First Normal Form 10B2—10BASE-2 10B5—10BASE-5 10B-F—10BASE-F 10B-FB—10BASE-FB 10B-FL—10BASE-FL 10B-FP—10BASE-FP 10B-T—10BASE-T 100B-FX—100BASE-FX 100B-T—100BASE-T 100B-TX—100BASE-TX 100BVG—100BASE-VG 286—Intel 80286 processor 2B1Q—2 Binary 1 Quaternary 2GL—Second-Generation Programming Language 2NF—Second Normal Form 3GL—Third-Generation Programming Language 3NF—Third Normal Form 386—Intel 80386 processor 1 486—Intel 80486 processor 4B5BLF—4 Byte 5 Byte Local Fiber 4GL—Fourth-Generation Programming Language 4NF—Fourth Normal Form 5GL—Fifth-Generation Programming Language 5NF—Fifth Normal Form 6NF—Sixth Normal Form 8B10BLF—8 Byte 10 Byte Local Fiber A AAT—Average Access Time AA—Anti-Aliasing AAA—Authentication Authorization, Accounting AABB—Axis Aligned Bounding Box AAC—Advanced Audio Coding AAL—ATM Adaptation Layer AALC—ATM Adaptation Layer Connection AARP—AppleTalk Address Resolution Protocol ABCL—Actor-Based Concurrent Language ABI—Application Binary Interface ABM—Asynchronous Balanced Mode ABR—Area Border Router ABR—Auto Baud-Rate detection ABR—Available Bitrate 2 ABR—Average Bitrate AC—Acoustic Coupler AC—Alternating Current ACD—Automatic Call Distributor ACE—Advanced Computing Environment ACF NCP—Advanced Communications Function—Network Control Program ACID—Atomicity Consistency Isolation Durability ACK—ACKnowledgement ACK—Amsterdam Compiler Kit ACL—Access Control List ACL—Active Current
    [Show full text]
  • The UCSD P-System STATUT ORIL Y EX E:M PT
    DOCfi!D(ov~ by NSA on 12-01-2011, Transparency Case# 5335]UNCLASSIFIED The UCSD p-System STATUT ORIL Y EX E:M PT This paper discusses the UCSD p-System, an operating system for small computers developed at the University of California at San Diego. The discussion includes the overall system, file managing, editing, and programming in Pascal on the system. INTRODUCTION The UCSD p-System was developed at the University of California at San Diego to support Pascal programming on microcomputers. Similar to MS-DOS, the p-System is an operating system for small computers but is, in many ways, very different. The p-System is written in Pascal and now supports not only Pascal, but also FORTRAN, COBOL, BASIC, and Modula-2. The concept was to have an operating system that, once it was implemented on a machine, allowed any program written under that operating system to be truly transportable from computer to computer. That is to say, the p-System compiler would not actually translate the program into a language that was specific for, say, an 8088 chip on the IBM-PC, but rather would translate it into a "pseudo" language that, when used with an operating system designed for the PC, would run correctly. Similarly, if the operating system were implemented on a Digital Equipment Corporation (DEC) computer, this same pseudo code would still work properly with no modifications. The particular version of UCSD p-System tested was written for the IBM-PC and requires two single-sided double-density disk drives and at least 128K of memory.
    [Show full text]