I''m working on an interpreted language. It has not specific purpose as of yet, I''m writing it ''just because''. I am at a stage where I need to design and then implement the VM that will run the code. I was toying with the idea of a ''high-level'' machine. Instead of creating instructions for expliciting load/storing or adding/subtracting, I keep everything high level so that much of the code is executed natively. For example: x = y*3+y^3/5; (^ is the power operator in my language) Instead of parsing that and generating VM code for all the multiplies, adds, divides, etc., I just have a high level VM instruction called eval which takes as parameters target register, and the expression to be evaluated. All the interpreting can be done natively, and of course the expression will be given in a format easily evaluated. ''If'' statements would become a test comparing the results of two ''eval'' instructions. Other control constructs have similar high level principles. Can anyone see potential problems with this approach? To me it seems easier, and possibly faster than some other designs I''ve seen (most of which have fairly closely mimicked hardware). Any insights welcome. I guess this is where most people put a famous quote... "Everything is funnier with monkey''s" - Unknown

Ok. Basically, at an high level, you do not have an virtual machine anymore: you have a server/client relationship, even tho'' the ''instructions'' are still being executed a line at a time. There''s nothing wrong with this, but the greatest problem is speed. How are you going to evaluate an expression?
//fake byte code:
EVAL REG1 REG2 MULT REG3 POW REG4
// blah blah.
well, the virtual machine must now do IN REAL TIME what the VM Compiler did IN COMPILER TIME.
It must take a stream of input (or language commands, in the VM Compilers case) and turn it into a value. I can imagine a long long switch case to evalueate a expression.
Would you like that in REAL TIME, or COMPILE TIME?
Thats why most VM''s stay comparatively close the real machine code. Of course, some instructions do not have this problem. In my old VM, it had a PRINT command:
PRINT REG2 ; reg 2 is a register pointing to a memory area that is 0 terminated.
Which would print out on the ''screen'' the message.

------------------------------
What should I put here? You tell me.

There are a number of degrees between the two of course. You could parse each expression into it''s Reverse Polish Notation, then have eval() work with that. It''s also sometimes usefull to compile to an explicit Abstract Syntax Tree. You can then flatten/constrain the tree as your output, and run from the flattend tree. The main advantage of working with an immediate interpreter is that debuging doesn''t get any simpler, and you can have your programming language act in a command line mode. A good example would be forth
something anyone doing language design should look at anyway.

Good luck with your project, there are a lot of nasty issues but keep codin, in the end its the only way to understand how languages work.

Hmm.... Well, the flattened/constrained tree I think is something like what I have right now. Though its just a guess because I''m not too familiar with the terminology.

Its not a huge switch statement, its implemented recursively...

If you''ve read the old "Lets Write a Compiler!" series by Jack Crenshaw you might know what I mean.

Anyway, I thank you for your input, you''ve (both) given me something to think about.

I''ll march forward and see what happens.

Ta.

Hmm.... Well, the flattened/constrained tree I think is something like what I have right now. Though its just a guess because I''m not too familiar with the terminology.

Its not a huge switch statement, its implemented recursively...

If you''ve read the old "Lets Write a Compiler!" series by Jack Crenshaw you might know what I mean.

Anyway, I thank you for your input, you''ve (both) given me something to think about.

I''ll march forward and see what happens.

Ta.