Old Toolkit Release Notes
This page contains notes from previous releases of the toolkit.
Toolkit news for September, 1996
Mary Fernandez now has full-time responsibilities at AT&T, which
means she has very little time to devote to the toolkit.
Mary will continue to help maintain the toolkit, but unfortunately she
will not be able to be involved in new development to the extent that
she would like.
I (Norman Ramsey) have moved from Purdue to the University of
Virginia, where I am Research Assistant Professor in the Deparment of
Computer Science. My primary responsibility is my work on the
Zephyr project; we are working with Princeton, Stanford, and others to
build a National Compiler Infrastructure.
I expect to focus on machine descriptions,
including writing tools to process them, and I expect the toolkit work
to dovetail nicely with Zephyr.
The toolkit's home page has moved with me; it is
now at http://www.cs.virginia.edu/~nr/toolkit.
The contact address for questions and problems continues to be
toolkit@cs.princeton.edu,
and for now I intend to maintain the
toolkit-interest and toolkit-users mailing lists at
Purdue.
Name that language!
Mary and I would like to give the ``toolkit specification language'' a
real name.
We have a couple of ideas but no great ones, and we hope maybe you all
will have better ones.
Here's what we're hoping for:
- An acronym that says something about what the language is for:
encoding, decoding, assembly, and disassembly of machine
instructions (or other binary specifications).
- Something pronounceable!
- Ideally, we would like an acronym that works out to a concrete noun,
so we can have a picture of it, make a logo, put it on our web page,
etcetera.
This sort of nonsense helps visibility, which means it helps me beg
for money, which means I can spend more time improving the toolkit.
Send suggestions to toolkit@cs.princeton.edu.
Software news
In May I made several small changes and extensions to the toolkit,
including
- Fixed several bugs in handling matching statements and generating
decoders.
- Added more support for automatic generation of assemblers and
disassemblers.
I have not taken the time to build another official release, but if
you think you need these fixes or extensions, send me mail.
The big news is that work on version 1.0 is on underway.
Thanks to many interesting discussions with members of Dave MacQueen's
group at Bell Labs, I have a plan for re-implementing the toolkit in
Standard ML.
I have done some work already, reaching a point where
I can elaborate many constructor definitions, and I hope I will soon
be in a position to generate code.
It says here there the rewrite will have the following wonderful benefits:
- Better error messages, with better relationsihp to source locations.
The toolkit may no longer always halt after the first message.
- The toolkit will run faster.
- The toolkit may be more reliable.
- We should be able to support at least C, Modula-3, and Standard ML
without too much trouble.
- We should be able to support variations on code generation.
- The new implementation should be a much better vehicle for
research and future extension.
Thanks for your interest in the toolkit.
Changes in Version 0.4 (March 1996)
The toolkit is now in version 0.4.
The primary reason for this new release is to enable users to validate
specifications using the specification checker.
The release includes these changes:
- The checker described in our
overview paper is included.
- The reference manual now describes how to use the toolkit to emit
assembly language as well as binary. This feature was in the last
release but not in the manual.
- The examples directory now includes a rudimentary disassembler for
the SPARC. Thanks to
Cristina
Cifuentes for providing the impetus.
- We have validated our specifications and corrected a handful of
lingering bugs.
- It is now possible to use
_
in expressions as a true
``wildcard'' value.
Unlike in previous releases, different instances of _
are
really different, even if they appear in the same arm of a matching statement.
It works by representing a different, otherwise
unnameable variable at each instance.
Suggested uses include:
- We have better diagnostics to help you figure out what is wrong
when you write a matching statement and some arms never match.
- We have fixed some more bugs, including an insidious bug with
names in matching statements.
- We have added a few procedures to the toolkit's library.
- We have introduced new bugs.
We are now saving
release notes from previous versions of the
toolkit.
There is no ``upgrade path'' from earlier versions to 0.4.
Get new everything.
Changes in version 0.3 (December 1995)
The toolkit is now in version 0.3.
This is a major new release, incorporating the following changes:
- One no longer needs
noweb to use the
toolkit.
- We have changed the specification language:
- Field bindings can now be full expressions.
- As a result, the syntax for bit slicing has changed.
- Patterns can now include labels.
- As a result, the ``$pc hack'' is no more.
- We have a new, much more efficient treatment of relocation
closures, as described in
Relocating
machine instructions by currying.
Unfortunately, the searching required to get the efficiency into the
encoders increases the running time of the toolkit significantly.
- We have fixed many, many bugs.
- Constructor types in matching statements now work properly.
- Generated decoders use cleaner, more idiomatic, more efficient code.
- We have introduced a number of new features, including support for
assembly-language syntax:
- Specify syntax separately from constructors, if desired.
- Generate encoding procedures that emit assembly language.
- Preliminary work on generating a grammar that recognizes parts of
assembly language.
We wish we had a version of the toolkit library that emits
assembly language.
- We have introduced new bugs.
Changes in version 0.2
- The toolkit can now generate encoding procedures that emit assembly
language.
New assembly-syntax specs can change form of this assembly language.
- It is now legal to use expressions, not just identifiers,
in field bindings and constructor applications.
- To support wider use of expressions, we were forced to change the
syntax of the bit-slicing operation from, e.g., n[0:4] to n@[0:4].
- We now support unary minus in expressions.
- $pc is gone, having been replaced with a more general
mechanism: pattern labels.
- The toolkit now supports both little-endian and big-ending bit
numbering (but big-ending hasn't been tested).
- Integer literals can be written in octal or binary formats as well as
decimal and hexadecimal.
- Many bugs have been fixed. Many more remain.
- We changed the precedence of the pattern operators so it more
accurately reflects the normal form.