Note on BC and type assertions

[Bryce McKinlay]

Andrew Haley wrote:

>Bryce McKinlay writes:
> > Andrew Haley wrote:
> > 
> > > > There may be other assertion types we need to handle as well, a pass
> > > > through the verifier looking for them is warranted.
> > >
> > >That's why I wanted to generate code for the assertions.  Then you can
> > >assert anything you want.
> > >  
> > Using a table of bytecodes with up to 2 utf8 operands we could assert 
> > pretty much anything we wanted.
>
>I don't quite understand your point here.
>  
>
Suppose we have a table of assertions for a given class. There is one 
entry for each assertion, and each entry consists of 3 fields:

struct assertion_table_entry
{
  int assertion_opcode;
  Utf8Const *operand_a;
  Utf8Const *operand_b;
}

#define assert_type_compatible 1  // operand A is type compatible with 
(assignable to) operand B
#define assert_is_instantiable 2 // Operand A is a class that is not 
abstract or an interface

This way, if and when we discovered additional corner cases that 
required an assertion to be emitted, we can just add a new assertion 
type code and add support for that code to the runtime. Backwards 
compatibility (new code on older runtime) could even be possible by 
having the runtime ignore assertion types that it doesn't understand.

This would, IMO, provide a simpler ABI between the compiler and runtime, 
and probably also reduce executable size. The runtime is free to 
implement the assertions any way it wants without being constrained by 
what the compiler emitted.

Regards

Bryce