[DGD]Type checking.

[Felix A. Croes]

Ludger Merkens <balduin at uni-paderborn.de> wrote:

> On Tue, 11 Apr 2000, Felix A. Croes wrote:
>[...]
> > LPC has some typechecking quirks that are hard to get around, mostly
> > due to the existence of the "mixed" type.  Also, doing runtime
> > typechecking of arrays can be quite expensive.  Java has solved this
> > in a way that avoids typechecking of each element of an array at
> > runtime, but unfortunately even Java cannot avoid expensive runtime
> > type checks altogether (though Sun has claimed that it does).
>
> How do they (try to) solve this problem ?

In LPC it is solved by runtime typechecking.  Almost every operation
in the virtual machine checks the types of its operands.  However, in
the case of an array or mapping, only the array-ness or mapping-ness
of the operand is verified.  The type of array elements is checked on
access.

The arithmetic types are treated specially.  The value ranges for int
and float do not include nil, and therefore those values are always
valid ints and floats, respectively.  In particular, integer values
have their type checked far less often and have their own range of
specialized operations -- for example, there is a general "add"
instruction which can add ints, floats, arrays and mappings, but there
is also a specialized add_int instruction which adds two integers
without bothering to check the value types.  The same thing could be
done for floats, but at present this remains unimplemented.

The precompiler especially takes advantage of the above.  Integer
operations in LPC are directly translated into integer operations in
C, with no typechecking at all.

In Java, compile-time typechecking is complete.  In theory, this would
allow runtime typechecking to be skipped, but in practise it doesn't
work out that way.  First, any object or array value can be a nil
pointer, and therefore has to be checked before being used.  Second,
there are cases where the type of an object is not fully known at
compile-time; all that is known is that its class inherits from a
given base class.  This means that some expensive object typechecking
has to be performed at runtime.  For a normal JVM, Java runtime
nil-checking/typechecking takes about as much as LPC typechecking.
However, since more is known about types at compile-time, JIT compilers
can generate code which checks less.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd