From: bobp@hal.com (Bob Pendleton)
Subject: Re: SCI: Object behavior in VR
Originator: hlab@stein.u.washington.edu
Organization: HaL Computer Systems, Inc.
Date: Tue, 13 Oct 1992 15:18:38 GMT


>From article <1992Oct13.045240.21281@u.washington.edu>, by marc%remarque.Berkel
ey.EDU@ucbvax.Berkeley.EDU (Marc DeGroot):

I agree with just about avery thing you've said, but...

> If that's the case, then what language should the code be written in?
> Dave, I believe you'd agree that C is not the correct answer.  Even with
> the compilation times you can get on a fast 486, the application argues
> heavily for pre-compiled code that is interpreted.  Pre-compiled because
> there really isn't time to compile the downloaded code, and interpreted
> for portability and consistency across multiple platforms.

You probably have already considered these points, but, I haven't seen
them stated in this discussion.

Since you can't resolve references to standard system services, or
even to named objects that you've previously sent over, you can only
really compile down to the the level of a linkable file.  This means
you still have to munge through the code that is sent over and do a
good part of the "compilation" process on the receiving side.

A lot of "pre-compiled" formats are larger than the original source
code. Consider that the "+" is one byte, but a plus operation compiled
to a threaded interpreted code may be 2, 4, or more bytes.

You're getting into the problem of sending binary data between
machines with different word sizes and byte orders. There are ways
araound this, but generally it means either agreeing on a standard
network byte ordering (so that wrong endian machines have to swap and
right endian machines don't) or the endianness is communicated between
machines and swapping only has to be done when different endian
machines talk to each other.

Are you making the assumption that you will always want to interpret
the code? Forth, and many other languages, can be compiled on the fly
to native machine code just as quickly as they can be compiled to more
traditional thread formats with little, if any, increase in code size,
and a dramatic improvement in execution speed.

How much precompiling are you planning to do?  If the source language
contains lots of long key words, programmers use lots of long symbol
names, and there are lots of long numeric constants in typical code,
then tokenizing the code can compress the code significantly and make
processing it on the receiving end simpler. But, if typical usage
varies from that pattern, tokenizing can increase the size.

I'd expect a tokenized form to start with a symbol table followed by a
sequence of 1 to n byte token encodings. Key words would be encoded as
single byte values, symbol references would be converted to a symbol
tag byte followed by an index into the symbol table, constants could
be converted to a type flag byte followed by the value.

Oh well, that's what I've been thinking would be a good way to
communicate between VR "decks."

                                Bob P.

-- 
Bob Pendleton             | As an engineer I hate to hear:
bobp@hal.com              |   1) You've earned an "I told you so."
Speaking only for myself. |   2) Our customers don't do that.
                   <<< Odin, after the well of Mimir. >>>
Newsgroups: sci.virtual-worlds