Map
Index
Random
Help
th

QuoteRef: auslM6_1982

topics > all references > ThesaHelp: references a-b



ThesaHelp:
ACM references a-e
Topic:
register allocation by graph coloring
Topic:
register allocation
Topic:
intermediate representation of code
Topic:
code optimization by special case analysis
Topic:
type-safe and secure languages
Topic:
dynamic type checking
Topic:
programming language standards
Topic:
machine code and assembly language
Topic:
code optimization
Topic:
code optimization by flow analysis
Topic:
boolean values, binary numbers, and bit strings
Group:
conditional control
Topic:
code optimization by code rewrite
Topic:
automated testing
Topic:
bugs
Topic:
compiler
Topic:
code optimization by instruction reordering or scheduling
Group:
code generation
Topic:
object code linkers and loaders
Topic:
type reflection and introspection
Topic:
function call
Topic:
consistency testing
Topic:
software portability

Reference

Auslander, M., Hopkins, M., "An overview of the PL.8 compiler", Proceedings of the ACM SIGPLAN '82 Conference on Compiler Construction, June 1982, SIGPLAN Notices, 17, 6, pp. 22-31. Google

Other Reference

reprinted, p. 38-48 in 20 Years of the ACM/SIGPLAN Conference of Programming Language Design and Implementation (1979-1999): A selection, ACM SIGPLAN 39.4, April 2004.

Quotations
retrospective ;;Quote: except for spilling, graph coloring register allocation did well; avoided spilling by doubling hardware registers to 32
retrospective ;;Quote: optimize addressing and housekeeping computations through the intermediate language; necessary for efficiency
retrospective ;;Quote: PL.8 not standardized despite being a fully-checked language; enforcement of language rules cost less than 10%
39 ;;Quote: 32-bit, register-based intermediate language for PL.8; similar to target machines
39+;;Quote: PL.8 used intermediate language for optimization
40 ;;Quote: PL.8 intermediate language uses a status register for compares and conditional jumps; no source language control structures
40 ;;Quote: PL.8 intermediate language has string operations and symbolic registers; optimized
40 ;;Quote: generate intermediate code bottom up, independent of context
40 ;;Quote: replicate loop test at head and tail of loop; optimization eliminates the first test if constant operands
41 ;;Quote: all PL.8 data accessed from the stack frame; may be optimized to a register
41 ;;Quote: value numbering allows common subexpression elimination over assignments within an extended basic block
41 ;;Quote: dead store elimination eliminates stored values that are not used
41 ;;Quote: combine basic blocks by eliminating unnecessary branches; called straightening
41 ;;Quote: trap elimination moves bounds tests from loops by modifying the loop termination test
41 ;;Quote: consolidate constant values for a loop by rearranging expressions within loops; called reassociation
42 ;;Quote: PL.8 optimizer bugs produce catastrophic results since optimizer applies to all code; regression test of 150 self-checking programs
42 ;;Quote: instead of moving code out of a loop, insert a duplicate copy; common subexpression elimination to remove the original copy
42+;;Quote: simplify an optimization by depending on common subexpression elimination and other standard optimizations
42 ;;Quote: optimize complex operations, then expand the operation and reoptimize; e.g., max and min, boolean expressions, and function calls
43 ;;Quote: graph coloring allocator developed for PL.8; simplified the compiler
45 ;;Quote: PL.8 compiler was written in PL.8
45+;;Quote: 32 registers eliminated most spill code from PL.8; with sixteen registers about half of the routines used spill code
43 ;;Quote: instruction scheduling moves loads away from stores; conditions from branch; etc.
43+;;Quote: perform instruction scheduling before and after register allocation
43 ;;Quote: generate machine code after register allocation; table-driven, destructive operations, addressability, external references
44 ;;Quote: PL.8 generated type metadata for every external variable; used for link edit and load-time type checking
44 ;;Quote: condition codes difficult to optimize; use values instead and generate condition codes at final assembly; uses peephole optimization
44 ;;Quote: final assembly generates function prologs and epilogs; handles stack frame, preserved registers
44 ;;Quote: PL.8 guarantees that all array and offset references are within bounds; optimizes run-time checks; checking costs 5-10%
45 ;;Quote: self-test of compiler by fixed points; compile the compiler, then recompile; the two results should be identical; also recompile the runtime library for each machine
45+;;Quote: PL.8 was highly portable; most bugs occurred on all machines


Related Topics up

ThesaHelp: ACM references a-e (259 items)
Topic: register allocation by graph coloring (21 items)
Topic: register allocation (28 items)
Topic: intermediate representation of code (31 items)
Topic: code optimization by special case analysis (22 items)
Topic: type-safe and secure languages (43 items)
Topic: dynamic type checking (43 items)
Topic: programming language standards (10 items)
Topic: machine code and assembly language (49 items)
Topic: code optimization (54 items)
Topic: code optimization by flow analysis (47 items)
Topic: boolean values, binary numbers, and bit strings (44 items)
Group: conditional control   (7 topics, 142 quotes)
Topic: code optimization by code rewrite (30 items)
Topic: automated testing (25 items)
Topic: bugs (66 items)
Topic: compiler (18 items)
Topic: code optimization by instruction reordering or scheduling (16 items)
Group: code generation   (30 topics, 593 quotes)
Topic: object code linkers and loaders (31 items)
Topic: type reflection and introspection (28 items)
Topic: function call (28 items)
Topic: consistency testing (60 items)
Topic: software portability (43 items)

Collected barberCB 6/04
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.