The industry has spent the past
30 years building CPUs optimized
for running languages such as C, because people who needed fast code
used C (because people who designed
processors optimized them for C, because...). Maybe the time has come
to start exploring better built-in support for common operations in other
languages. The RISC project was born
from looking at the instructions that
a primitive compiler generated from
compiling C code. What would we
end up with if we started by looking
compiler would emit?
The Robustness Principle Reconsidered
Erlang for Concurrent Programming
The Rise and Fall of CORBA
1. allen, s. redline smalltalk. Presented at the
International smalltalk Conference (2011).
2. boehm, h.-j. simple garbage-collector-safety. ACM
SIGPLAN Notices 31, 5 (1996), 89–98.
3. boehm, h.-j. and weiser, m. garbage collection in an
uncooperative environment. Software Practice and
Experience 18, 9 (1988), 807–820.
4. bothner, P. and tromey, t. java/C++ integration
CnI01.pdf/ and http://gcc.gnu.org/java/papers/
5. Chisnall, d. 2012. smalltalk in a C world. In
Proceedings of the International Workshop on
Smalltalk Technologies (2012), 4:1–4: 12.
6. Chisnall, d. a new objective-C runtime: from research
to production. ACM Queue, (2012); http://queue.acm.
7. geoffray, n., thomas, g., lawall, j., muller, g. and folliot,
b. Vmkit: a substrate for managed runtime environments.
ACM SIGPLAN Notices 45, 7 (2010), 51–62.
8. Paz, h., Petrank, e., bacon, d. f., kolodner, e.k.,
rajan, V.t. an efficient on-the-fly cycle collection.
In Proceedings of the 14th International Conference
on Compiler Construction. springer-Verlag, berlin,
heidelberg, 2001, 156–171.
Portions of this work were sponsored by the defense
advanced research Projects agency (darPa) and
air force research laboratory (afrl) under contract
fa8750-10-C-0237. the views, opinions, and/or findings
contained in this article are those of the author and should
not be interpreted as representing the official views or
policies, either expressed or implied, of darPa or the u.s.
department of defense.
David Chisnall is a researcher at the university of
Cambridge, where he works on programming language
design and implementation. he spent several years
consulting, during which time he also wrote books on Xen
and the objective-C and go programming languages. he
also contributes to the llVm, Clang, freebsd, gnustep,
and Étoilé open source projects.
© 2013 aCm 0001-0782/13/12 $15.00
ports four billion lines of C code, and
around 1. 5 billion each of C++ and
Java. While other languages such as
Scala (almost six million lines of code
tracked by Ohloh.net) run in JVM,
legacy low-level languages do not.
Worse, calling native code from Java
is so cumbersome (both in terms of
cognitive and runtime overhead) that
developers end up writing applications
in C++ rather than face calling into a
C++ library from Java. Microsoft’s CLR
did a little better, allowing code written in a subset of C++ to run; it makes
calling out to native libraries easier but
still provides a wall.
This approach has been a disaster
for languages such as Smalltalk that
do not have large companies backing
them. The Smalltalk VM provides some
advantages that neither CLR nor JVM
provides in the form of a persistence
model and reflective development
environment, but it also forms a very
large PLIB (programming language interoperability barrier) by dividing the
world into things that are inside and
things that are outside the box.
This gets even more complex once
you have two or more VMs and now
have the problem of source-language
interoperability and the (very similar)
problem of interoperability between
the two VMs, which are typically very
low-level programming languages.
the Path forward
Many years ago the big interoperability question of the day was C and Pascal—two languages with an almost
identical abstract machine model.
The problem was that Pascal compilers pushed their parameters onto the
stack left to right (because that required fewer temporaries), whereas C
compilers pushed them right to left (to
ensure the first ones were at the top of
the stack for variadic functions).
This interoperability problem was
largely solved by the simple expedient of defining calling conventions as
part of the platform application binary
interface (ABI). No virtual machine or
intermediate target was required, nor
was any source-to-source translation.
The equivalent of the virtual machine
is defined by the ABI and the target machine’s ISA.
Objective-C provides another use-
ful case study. Methods in Objective-
C use the C calling convention, with
two hidden parameters (the object
and the selector, which is an abstract
form of the method name) passed
first. All parts of the language that do
not trivially map to the target ABI or
ISA are factored out into library calls.
A method invocation is implemented
as a call to the objc _ msgSend()
function, which is implemented as a
short assembly routine. All of the in-
trospection works via the mechanism
of calls to the runtime library.
We have used GNUstep’s Objective-C runtime to implement front ends for
LanguageKit. This uses LLVM, but only
because having a low-level intermediate representation permits optimizations to be reused between compilers:
the interoperability happens in the native code. This runtime also supports
the blocks ABI defined by Apple; therefore, closures can be passed between
Smalltalk and C code.
Boehm garbage collector (GC) and
Apple AutoZone both aimed to provide
garbage collection in a library form,
with different requirements. Can concurrent compacting collectors be exposed as libraries, with objects individually marked as nonmovable when
they are passed out to low-level code?
Is it possible to enforce mutability and
concurrency guarantees in an ABI or
library? These are open problems, and
the availability of mature libraries for
compiler design makes them interesting research questions.
Perhaps more interesting is the
question of how many of these can
be sunk down into the hardware. In
Crash-worthy Trustworthy Systems
R&D (CTSRD), a joint project between
SRI International and the University
of Cambridge Computer Laboratory,
researchers have been experimenting
with expressing fine-grained memory
protection into the hardware, which
they hope will provide more efficient
ways of expressing certain language
memory models. This is a start, but
there is a lot more potential for providing richer feature sets for high-level
languages in silicon, something that
was avoided in the 1980s because transistors were scarce and expensive resources. Now transistors are plentiful
but power is scarce, so the trade-offs in
CPU design are very different.