Stack issues

In my first attempt I used the .Net stack and did a direct translation from the LSO ByteCode. I found that there are a couple of problems related to that.

First of all is the obvious problem that I stated earlier, I don’t know what datatype is in the stack – but many (most) .Net commands requires me to know that. Wherever LSO can provide datatype for me it is ok, but in many cases LSO is not providing me with that datatype. For example during casting.

Next is the problem that .Net wants the stack served like “classlocation, param1, param2, call to command in classlocation”. This means that I need to predict commands before PUSH’ing anything to the stack. Way to complex. I could of course juggle the stack, but not so cool.

So I’ve made a few changes.

First of all I’m now inheriting the compiled .Net assembly from a baseclass. In this baseclass I’ve added my own Stack(object), and created my own (generic) PUSH/POP/POPToStack commands. (PUSH to my stack, POP from my stack and POP from my stack to .Net’s stack)

Secondly I’m creating most OPCODES as commands in C# (the base class) that is called from the converted LSO ByteCode. This way I have full control of both stack and OPCODE behaviour.

The bonus is that my stack now is in a single object that can be serialized.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: