| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 168.1 | Try to get there early | DENTON::AMARTIN | Alan H. Martin | Thu Mar 10 1988 08:44 | 4 |
| I've been informed that popular Apollo R&D seminars have a history of
being standing-room-only affairs. So, if you are going to attend, plan on
arriving early.
/AHM
|
| 168.2 | | EVER11::WAKE | | Thu Mar 10 1988 23:09 | 133 |
|
I attended the "Fast Compiler Technology" seminar at Apollo
and took a few notes.
The key idea is that by using certain techniques such as compilation
directly to memory, careful case analysis, and pre-compilation of
expressions, compilation speed can be improved by up to a factor of
500. Prof. McKeeman has a system based on a language of his own
design that applies these techniques. His goal is to get compilation
to be as fast as Unix "cat" ($TYPE for you DCL types).
The standard "lexer -> parser -> ... -> optimizer -> code generation"
costs about a factor of 10. A better organization is to run
everything through the editor (ala Turbo Pascal). Everything should
be kept in memory, as running off the disks can cost up to a factor
of 100.
"Hot code": compile into an array, cast the array into a function,
and call the function. This avoids linking.
Case analysis for code generation. Worth a factor of 2.
Encode the argument and operator types into an integer, and
use that integer as the control of a 'switch' or 'case' statement.
Using 'if' statements to decode things, jumping to one of 1000
routines will require about 10 tests. A 'case' statement can go
directly in one step.
System overview: all in memory.
|----------------|
|SVC - SuperVisor|
---->|Call - Runtime |
/ |support |
| |----------------|
|
V
|----| |----|
|User|<---------------->|User|
|Code| |Data|
|----| |----|
^ ^
| |
\----------------\ /---/
V
|------| |--------------|
|Editor|<------>| S | P | E |
|------| | C | A | M |
| | A | R | I |
| | N | S | T |
| | | E | |
| |--------------|
| | Compiler |
| |--------------|
V
[Linked list of program text]
Inside the editor:
|-----------------|
----->| X = Y + 1 ; |eos|
/ |-----------------|
^ |
| |
|-------------------------------------------------------|
| Next | Prev | Text | Tokens | Assignment code |
|-------------------------------------------------------|
| | |
V [ X] [code bytes then RTS]
|
[ =]
|
:
:
Compilation:
Code array:
|-------------------------------------------------------------|
| | instructions - mostly control flow | |
|Save registers | but also JSR to pre-compiled | RTS |
| | assignment subroutines | |
|-------------------------------------------------------------|
This is called as a function from the editor.
For support of things like "printf", generate code to push a SVC
request number and associated data on the stack, then a call to
the SVC handler, which is another big case statement.
To build an application,
- put code into a.out
- 'SVC' is the only external needed
- Link against SVC.OBJ
To suspend environment (mostly Unix-specific):
save current state by:
- Copy a.out to tmp
- Copy data including malloc (dynamically allocated storage) to tmp
- Fix up the header
- Feed to Unix ld (loader) to restart.
Other ideas:
Sneak-ahead: Do work behind the user's back.
- partial compilation to last character touched in editor
- compile changed lines when the cursor moves
- pre-load libraries, pre-link modules, pre-open files
Drag-along: Do hard work at night when user doesn't care how
long it takes.
- compile routines with optimizer
- compact fragmented workspace
- run lint, test suites, etc.
Optimization: Might improve code by a factor of 2, but is very
expensive in terms of time.
Parallelism: Can provide N speedup in both scanning and parsing
Interpreters: Run a factor of 40 slower, take a factor of 3 less
space, advantages for debugging.
|
| 168.3 | | TLE::BRETT | | Fri Mar 11 1988 07:55 | 3 |
| I'm glad I didn't waste my time going.
/Bevin
|
| 168.4 | | TALLIS::KOCH | Kevin Koch LTN1-2/B17 DTN226-6274 | Fri Mar 11 1988 09:12 | 5 |
| Doing things behind the user's back while editting is the best place
to optimize, since the human typing and thinking is the bandwidth-limiting
link. Not an earth-shattering concept. By interleaving thinking and
computing, you reduce user-perceived wall time at a cost of more computes.
I have such a tool written in TPU that partially assembles microcode.
|
| 168.5 | | AITG::VANROGGEN | | Fri Mar 11 1988 20:17 | 3 |
| Recast the terminology/ideas a bit and you have a description of a
lisp system from a decade ago implemented by a hacker (in the
perjorative sense of the word).
|
| 168.6 | | CASEE::LACROIX | Where did Lynyrd Skynyrd go? | Sat Apr 16 1988 09:30 | 7 |
| We are not really used to lightning fast compilers on mini systems or
workstations. It may change: Borland International announced this week
that they were porting TURBO C and TURBO PASCAL to Sun workstations.
Given their record, they stand a pretty good chance to achieve 50,000
to 100,000 lines compiled per minute on a SUN 4....
Denis
|
| 168.7 | Followup - talk 8/23 at ZKO | MLTVAX::WAKE | | Fri Aug 18 1989 11:51 | 47 |
|
Title: "RapidCASE - rapid turnaround for the DIGITAL programming environment"
Speakers: Bill McKeeman - Digital
Shota Aki - Digital
Scot Aurenz - Digital
Date: Wednesday, August 23, 1989
Time: 1:30 - 3:00 PM
Place: Babbage Auditorium, ZKO-1
The time required to realize a coding change--the edit/compile/link/run
turnaround--can be a significant productivity bottleneck for today's
software developers. In most environments available today, even a small
coding change requires recompilation of an entire module and relinking of
all modules.
The RapidCASE project is an effort in determining how to
provide very fast turnaround in the DIGITAL programming environment.
The goal is to minimize the time to make and test a
small change in a large program. RapidCASE combines editing, compiling,
linking, and test execution in a single environment. The approach
is summarized in the motto "Save and reuse rather than recompute."
Preliminary figures show the turnaround will be about 1000 times quicker
than the comparable tools commonly available under Unix.
RapidCASE is an advanced development project within the Technical
Languages & Environments (TLE) group. RapidCASE started in September
of 1988 with Bill McKeeman and Shota Aki as the principal investigators.
Since then, Scot Aurenz has joined the project, several patents have been
submitted, and a prototype has been produced.
This presentation will cover the motivations and goals of the
project, an introduction to the system, future directions for
the project, a description of the innovative features
applied in the incremental compiler and linker, and of course, a
demonstration of the prototype in action.
The presentation should be of interest to systems programmers.
Detailed knowledge of compilers is not required.
Technical Host: Glenn Lupton, Consulting Software Engineer TLE
- no reservations required -
|
| 168.8 | Summary | MLTVAX::WAKE | | Fri Aug 25 1989 15:26 | 73 |
|
RapidCASE
Talk and demo were given by Bill McKeeman and Shota Aki,
August 23, 1989, at ZKO.
SUMMARY:
RapidCASE is an environment for
improving turnaround time during the
compile & test phase of development.
RapidCASE is an advanced development project that
might someday become a product.
RapidCase is positioned against such tools as LightSpeedC and
Saber-C. Its improvements:
- supports multiple languages
- incremental make and link
- incremental compilation
- static & dynamic error checking
- support for unit testing
It is not a replacement for our current optimizing compilers,
but a tool to aid in the coding and early testing phases,
where such optimization doesn't matter.
The traditional model is a cycle: an edit, followed by
make, compile, link, run, and debugging. The RapidCASE tool
would bring about a 2000-fold improvement in turnaround, by
merging edit/make/compile/link, and focusing on improving the
interactive response.
The basic environment has a core called RCASE.
This will interface to editors, an object file transformer,
incremental compilers, the RTLs, and a debugger.
Improvements:
About 2000 times faster than pcc on UNIX.
(VAX C is about twice as fast as pcc.)
About half the savings is from incremental linking,
the other half from incremental compilation.
The initial compilation time is comparable to that of VAX C,
but succeeding compiles take less than 1% as long.
Data:
Requires a linear amount of virtual storage.
Re-build is basically proportional to the number of changed modules.
For a 50000 line program:
30 seconds for initial compilation
10 seconds for compilation if paged out
5 seconds if paged in
Incremental compiler:
Callable, can switch contexts.
Incremental scanning, code generation, and linking.
"Skip-scanning" and "skip-parsing" avoid duplicating effort.
Uses journals for tokens, symbol entries, and code constructs.
Uses nested lexical and semantic increments based on line structure.
Code is generated into an array. Each code fragment is
a mini-subroutine. (Simplified linking.)
Future:
Prototype (simplified C) is complete, ANSI C work is beginning.
Opportunity to add other languages, and to improve the configuration tool,
debugger, and object file converter. Could add browser and
lint capabilities as well. The RapidCASE team plans to document
its techniques for more general distribution.
(Summary prepared by Bill WHYVAX::Wake)
|
| 168.9 | OPS5 programmers have it now | RACHEL::BARABASH | Daddy I shrunk the company-F Wang | Mon Aug 28 1989 14:47 | 11 |
| Digital already sells a product like RapidCASE for OPS5. The VAX OPS5 V3.0
Development Environment has all these features in a DECwindows-based
system which lets you browse, edit, and debug. The incremental compiler
allows you to modify a running program on the fly, and the run-time system
lets you run the program backwards in case the changes you make don't work.
DECwindows server-client mode is supported.
For further information, see the VAX OPS5 Development Environment User's
Guide (available online in GUESS::OPS$KIT:OPSV3_ENVIRONMENT_UG.PS).
-- Bill B. (who owns a copy of McKeeman's XPL book)
|
| 168.10 | not only OPS5 | 16BITS::PUDER | Karl Puder, VAX APL Project Leader | Fri Sep 15 1989 19:20 | 12 |
| Yes, I was going to say (except that I was waiting to think of a
politer way to say it) that languages like OPS5, LISP, Smalltalk,
Trellis and APL already have an interactive development environment.
And most of those languages have compilers.� So what's the big deal?
(I'm not flaming, just curious). Are there that many people out there
who would rather fight their vendor for a better environment than
switch to a language that already has one? I suppose I should be a
realist and expect the answer "yes".
:Karl.
�Unfortunately, mine is the one that doesn't. :-(
|