[345] in Coldmud discussion meeting

Re: floating point

daemon@ATHENA.MIT.EDU (Fri Jun 3 19:11:28 1994 )

To: rti@mcs.com (Crispin Bivans)
Cc: deforest@netcom.com (Robert de Forest), coldstuff@MIT.EDU
In-Reply-To: Your message of Fri, 03 Jun 94 17:35:38 -0500.
             <m0q9hpy-000BcdC@mercury.mcs.com> 
Date: Fri, 03 Jun 94 19:04:20 EDT
From: Greg Hudson <ghudson@MIT.EDU>


> Question: Is the C-- code 'compiled' or interpreted during 'runtime'?

The source is converted into a series of opcodes, interpreted by a
short loop that does nothing except check the tick count, dereference
the opcode table, and call the opcode handler.  (It should become
unnecessary to check the tick count with a good design.)

A feature of this kind of interpretation is that low-level operations
tend to be dominated by interpretation overhead, while high-level
operations tend to be dominated by the work they accomplish.  For
instance, "a + b" involves two local variable lookups and an addition,
probably between 50 and 100 machine instructions, as opposed to one to
three machine instructions in C code.  On the other hand, a string
table lookup is probably only 10% slower in Coldmud.

Also, message dispatch is particularly slow in Coldmud relative to
function calls in C.  This and other factors tend to discourage
procedural abstraction.  To mitigate this, Coldmud should probably
include private functions which aren't part of an object's exported
interface.  It should be easy to arrange the implementation so that
calling such functions is quick (dereferencing a table and creating a
call frame, maybe 50-100 machine instructions, as opposed to tens of
thousands for a message dispatch).

Unfortunately, simulations tend to involve a lot of arithmetic
operations, and you want the ability to dynamically update the
algorithms which involve heavy computation, so building them into the
server doesn't help much.  The solution is a good, widely-ported
run-time machine code generation package; I'm afraid that none exists
right now.

--GBH