[Emerson-general] (no subject)

[<af...@en...>]

Agreed, so we can leave out the new class and static-call opcodes.

As for arrays, making them objects instead of some kind of special case is a
better idea. We should try to box as much as possible within c++ objects so we
don't have all these weird scenarios we have to deal with later. So in our
situation, arrays are just classes?

I'll make a formal instruction set reference specification later, probably this
weekend.

Are we supporting pointers/"unsafe code"?

-Alex.

Quoting Lucas Magder <luc...@ro...>:

> 
> That looks good but why do we need a new class opcode? Didn't we decide that
> metadata would describe types not code itself. Also we don't need two call
> opcodes, if we treat a class as an instance of a metaclass that is
> instantiated when the class definition is loaded, then we only need a
> non-static call opcode, you call it from a different thing. Also, can't we
> just make arrays objects instead of having a special case?, plus you
> shouldn't be able to mess with threading. It should be completely automatic.
> If it's not, then someone could, for example, purposely leave out lock
> opcodes in hand coded asm to cause a data corruption attack. 
> 
> As for adding opcodes, we need assignment, flat function calls, and a return
> 
> opcode at least.
> 
> -Lucas


----------------------------------------
This mail sent through www.mywaterloo.ca