<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: Optimizing Squeak</title></head><body>
<div>Don't forget that the simple Forth like stack machine which the
native byte codes use is very compatible with a FRISC (Fast RISC) see <a
href="http://inp.cie.rpi.edu/research/mcdonald/frisc/slides/index.html"
>http://inp.cie.rpi.edu/research/mcdonald/frisc/slides/index.html</a><br
>
It's a 500ps 32 bit stack machine<br>
</div>
<div>the simplicity of the Smalltalk stack design implies byte code
portability<br>
</div>
<div>IBM'ers should note that the FRISC design should be
re-implemented in the Burlington SiGe process and hung onside a
3090<br>
</div>
<div>Have you considered doing a DAG for the bytecodes and producing
an optimizing debugging decompiler which eliminates dead code and data
and emits machine specific instructions?<br>
</div>
<div>One could also translate the DAG to C++ (have class info) or
Java.<br>
</div>
<div>Better yet re-emit the Smalltalk you thought you typed in<br>
</div>
<div>tedc<br>
</div>
<div>johnm@wdi.disney.com wrote:<br>
</div>
<blockquote type="cite" cite>Jan Bottorff <janb@pmatrix.com>
wrote:<br>
> A few years ago I did<br>
> a bunch of research on alternative Smalltalk bytecode sets and
concluded<br>
> the "classic" bytecode set could not be much worse from
an interpreter<br>
> overhead viewpoint.<br>
</blockquote>
<blockquote type="cite" cite>Jan,<br>
</blockquote>
<blockquote type="cite" cite>Did you ever write up your analysis? It
sounds like it would make a terrific<br>
OOPSLA or PLDI paper. I agree that one could probably find a bytecode
set that<br>
is a better match to today's processor architectures than the BlueBook
bytecode<br>
set. The BlueBook bytecode set designed in the 70's when memory and
processor<br>
speeds were pretty well matched, so a stack architecture was pretty
efficient.<br>
Also, the minicomputers of that day, such as the PDP-11 and Data
General Nova,<br>
had fewer general purpose registers than modern processors.<br>
</blockquote>
<blockquote type="cite" cite>Note that part of Smalltalk/V's
impressive speed for a simple interpreter was<br>
based on a carefully designed bytecode set. I've never been able to
find out<br>
much about this bytecode set. It may be that Digitalk considered it
trade secret,<br>
which would explain why they hid the compiler classes from the
user.<br>
</blockquote>
<blockquote type="cite" cite>
-- John</blockquote>
</body>
</html>