Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!hybrid!scifi!bywater!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.arch
Subject: Re: It looks like he's at it again!
Summary: Not necessarily so.
Message-ID: <1232@s8.Morgan.COM>
Date: 13 Jul 90 15:11:29 GMT
References: <2328@l.cc.purdue.edu> <1990Jul10.072443.4844@cs.UAlberta.CA> <24358@estelle.udel.EDU>
Organization: Morgan Stanley & Co. NY, NY
Lines: 27

In article <24358@estelle.udel.EDU>, new@udel.EDU (Darren New) writes:
> Sure.  Any inner-interpreter type of code is easiest in assembler. Things
> like Forth threading are harder to do in C than assembler because Forth assumes
> is really big on treating addresses as data and vica versa. In addition,
> it is usually only 3-6 instructions to do an inner-interpreter step
> and the more speed you can get, the better.          -- Darren

Well, speed is a _big_ issue, for example in our* APL interpreter.
However, we seem to have come to the idea that only things which are
impossible to do in C are done in assembler. A good reason for this
is that development of the interpreter is simultaneous for more than
one platform. We have generally been able to find C code which can
be compiled into nearly fastest possible on more than one machine.
Given that these are different architectures, this is surprising.
It would be unbelievable in assembler. (I.e. different solutions for
the different machines would almost certainly result.) I think the
only thing assembler is used for is to deal with integer overflow
and this results in a single routine on one of the platforms being
written in assembler. Those who have seen the description of the
performance of the interpreter (e.g. see APL90 proceedings,) know
that this approach has resulted in a _very_ fast interpreter.

Later,
Andrew Mullhaupt

*our = Morgan Stanley, but the prinicpal author of the APL interpreter
is Arthur Whitney.