🚀 go-pugleaf

In article <1991Apr19.132239.9252@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes:
>In article <1991Apr17.173651.23103@visix.com> amanda@visix.com (Amanda Walker) writes:
>>
>>However, you can certainly *implement* dynamic typing in C, with as
>>low an overhead as you can get in any other language.
>>
>
>This is not true.  A C implementation of dynamic typing will be slower.
>A compiler for a dynamic language can take advantage of its knowledge of
>datatype representations to generate faster code.
>
>Two simple examples:
>
>  1) tag operations for type discrimination
>
>     A compiler for a dynamically typed language can dedicate a register to
>     hold a bitmask that will speed type tag operations.  A C program would
>     either use an immediate value or a global variable, either of which is
>     slower and bulkier on many architectures.
I have tried this in my Smalltalk VM. On both 68020 & SPARC there is no
significant difference in performance attributable to dedicating a register
to tag detection. Add a register here loose it there.
>
>  2) generic arithmetic
>
>     Suppose the dynamic language includes generic arithmetic on integers of
>     arbitrary size.  In lisp this would give two types of integer, fixnum
>     and bignum.  A lisp compiler can add two fixnums inline and branch on
>     the overflow flag to a bignum routine if the sum of the fixnums is too
>     large.  C blithely ignores integer overflow.  In addition, some CPU
>     architectures have special instructions to speed tagged arithmetic
>     (notably the Sparc).  I would be surprised if C compilers were able to
>     use that instruction for generic arithmetic.
>
>... and there are numerous other type representation hacks that an
>implementation of a dynamically-typed language system can exploit.

If you use gcc which has a) global register variables & b) a powerful
trap-door to assembler you can certainly produce as efficient a dynamic binder
in C as you could in any system.  I've written a quick threaded-code
Smalltalk VM in C with minimal assembler (the direct threaded code jump).
It would be easy to define Smalltalk objects at the C level.

I accept that using (or at least specifying a language in terms of) an abstract
machine leads to a concise design at one level.  This does not imply that
such a solution will be implementable more efficiently.

With persistence (& perversity) one can get C to compile to very efficient
machine code. With good compiler support (gcc) less persistence is required :-).
Using C as an assembler is becomming more & more popular because it works not
just because its relatively easy to do.
-- 
Eliot Miranda			email:	eliot@dcs.qmw.ac.uk
Dept of Computer Science	ARPA:	eliot%dcs.qmw.ac.uk@nsf.ac.uk
Queen Mary Westfield College	UUCP:	eliot@qmw-dcs.uucp
Mile End Road			Fax:	081 980 6533 (+44 81 980 6533)
LONDON E1 4NS			Tel:	071 975 5229 (+44 71 975 5229)