Solve : What type of VM or interpreter would this be??

1.	Solve : What type of VM or interpreter would this be??
Answer» I was just thinking about possibly designing a new version of my scripting language. I know that there are two types of programming language interpreters. There's the kind the decodes the syntax in real time as it's executing (like mine) and then there is the kind like Java or .NET that compiles to byte code. I am also aware that there are two types of byte code interpreters (stack based and register based). My question is what would you call an interpreter that uses byte code, but does not use a stack or registers? It would simply have a byte or two to represent each command and then each command would have a few bytes after it that represent the location in memory of the parameters for that command. If the command had math in the parameters, then it would just point to a string containing the math and then the interpreter would execute it. To me it seems like this type of interpreter would be a lot faster than the ones that use an actual virtual machine code. Would this be better, or is there something I'm overlooking? I hope you understand what I mean because it's pretty hard for me to explain this stuff clearly.Quote from: Linux711 on FEBRUARY 01, 2013, 03:25:52 PM To me it seems like this type of interpreter would be a lot faster than the ones that use an actual virtual machine code. You are overlooking this: Quote then it would just point to a string containing the math and then the interpreter would execute it. And how does it "execute" the string? By interpreting it. Your method only really 'compiles' the highest level, where everything LOWER down is STILL in the original form, and needs to be interpreted later. So you don't think there'd be any added speed by using this method? Why would an actual VM be faster than this? Isn't reading the syntax and then deciding what to do the slowest part? I figured by eliminating that step, it would make it much faster.My idea is that if you condense the actual syntax into a byte code that I explained, and then use the interpreter to execute that, then most of the actual processing is done on the real CPU itself and only the big picture concepts (the commands) are emulated. With an actual VM every little step has to be interpreted any finally executed as native code rather than just the 'big picture' commands.Quote from: Linux711 on February 01, 2013, 03:25:52 PM a string containing the math and then the interpreter would execute it. censored! If only I had KNOWN it was that simple! Quote censored! If only I had known it was that simple! Yes, I could have been more specific on that, but it doesn't matter because that's not the point. (Not trying to be mean if you were just pointing that out for fun.) My latest post most accurately describes my point.Quote With an actual VM every little step has to be interpreted any finally executed as native code rather than just the 'big picture' commands. First, the .NET CLR as well as the JVM use a of JIT(Just in Time) Compilation. That is, once it executed a block of code, that piece is compiled and that compiled bit is used from then onwards if that code is executed again. And that isn't to touch on the other optimizations that they both make, such as Sealed methods in public classes no longer requiring virtual dispatching, which would normally be required to call the appropriate method implementation. I think you are seriously underestimating just how much experience and understanding the people that work on these Virtual Machine implementations have. Very few languages today- with the possible exception of ruby and PHP- are truly interpreted 'in place'. Otherwise, the most "basic" implementation is generally to build an Abstract Syntax Tree for the language tokens. This is almost exactly what you are describing. Quote from: Linux711 on February 01, 2013, 04:31:04 PM So you don't think there'd be any added speed by using this method? Why would an actual VM be faster than this? Isn't reading the syntax and then deciding what to do the slowest part? I figured by eliminating that step, it would make it much faster. "reading the syntax and deciding what to do" are two completely disparate tasks. "reading the syntax" would consist of building an Abstract Syntax tree. Deciding what to do involves executing that tree. Of course Virtual Machines also compile to Native code on the fly as they execute the Bytecode (Implementations of bytecode interpreters in other languages sometimes take this approach as well). The reason I pointed out the "a string containing the math and then the interpreter would execute it." You are basically saying "I think the easiest way to interpret some script is to have it in a string and then have an interpreter execute it"... it doesn't actually say anything but what you plan to do. It's not an algorithm. It's like saying "I think the best way to sort a list is to have a list and have a function sort it".Quote from: BC_Programmer on February 01, 2013, 05:39:53 PM The reason I pointed out the "a string containing the math and then the interpreter would execute it." You are basically saying "I think the easiest way to interpret some script is to have it in a string and then have an interpreter execute it"... it doesn't actually say anything but what you plan to do. It's not an algorithm. It's like saying "I think the best way to sort a list is to have a list and have a function sort it". This is what I was getting at.

Answer»

I was just thinking about possibly designing a new version of my scripting language. I know that there are two types of programming language interpreters. There's the kind the decodes the syntax in real time as it's executing (like mine) and then there is the kind like Java or .NET that compiles to byte code. I am also aware that there are two types of byte code interpreters (stack based and register based). My question is what would you call an interpreter that uses byte code, but does not use a stack or registers? It would simply have a byte or two to represent each command and then each command would have a few bytes after it that represent the location in memory of the parameters for that command. If the command had math in the parameters, then it would just point to a string containing the math and then the interpreter would execute it. To me it seems like this type of interpreter would be a lot faster than the ones that use an actual virtual machine code. Would this be better, or is there something I'm overlooking? I hope you understand what I mean because it's pretty hard for me to explain this stuff clearly.Quote from: Linux711 on FEBRUARY 01, 2013, 03:25:52 PM

To me it seems like this type of interpreter would be a lot faster than the ones that use an actual virtual machine code.

You are overlooking this:

Quote

then it would just point to a string containing the math and then the interpreter would execute it.

And how does it "execute" the string? By interpreting it. Your method only really 'compiles' the highest level, where everything LOWER down is STILL in the original form, and needs to be interpreted later.

So you don't think there'd be any added speed by using this method? Why would an actual VM be faster than this? Isn't reading the syntax and then deciding what to do the slowest part? I figured by eliminating that step, it would make it much faster.My idea is that if you condense the actual syntax into a byte code that I explained, and then use the interpreter to execute that, then most of the actual processing is done on the real CPU itself and only the big picture concepts (the commands) are emulated. With an actual VM every little step has to be interpreted any finally executed as native code rather than just the 'big picture' commands.Quote from: Linux711 on February 01, 2013, 03:25:52 PM

a string containing the math and then the interpreter would execute it.

*censored*! If only I had KNOWN it was that simple!
Quote

*censored*! If only I had known it was that simple!

Yes, I could have been more specific on that, but it doesn't matter because that's not the point. (Not trying to be mean if you were just pointing that out for fun.)

My latest post most accurately describes my point.Quote

With an actual VM every little step has to be interpreted any finally executed as native code rather than just the 'big picture' commands.

First, the .NET CLR as well as the JVM use a of JIT(Just in Time) Compilation. That is, once it executed a block of code, that piece is compiled and that compiled bit is used from then onwards if that code is executed again. And that isn't to touch on the other optimizations that they both make, such as Sealed methods in public classes no longer requiring virtual dispatching, which would normally be required to call the appropriate method implementation.

I think you are seriously underestimating just how much experience and understanding the people that work on these Virtual Machine implementations have. Very few languages today- with the possible exception of ruby and PHP- are truly interpreted 'in place'. Otherwise, the most "basic" implementation is generally to build an Abstract Syntax Tree for the language tokens. This is almost exactly what you are describing.

Quote from: Linux711 on February 01, 2013, 04:31:04 PM

So you don't think there'd be any added speed by using this method? Why would an actual VM be faster than this? Isn't reading the syntax and then deciding what to do the slowest part? I figured by eliminating that step, it would make it much faster.

"reading the syntax and deciding what to do" are two completely disparate tasks. "reading the syntax" would consist of building an Abstract Syntax tree. Deciding what to do involves executing that tree. Of course Virtual Machines also compile to Native code on the fly as they execute the Bytecode (Implementations of bytecode interpreters in other languages sometimes take this approach as well).

The reason I pointed out the "a string containing the math and then the interpreter would execute it." You are basically saying "I think the easiest way to interpret some script is to have it in a string and then have an interpreter execute it"... it doesn't actually say anything but what you plan to do. It's not an algorithm. It's like saying "I think the best way to sort a list is to have a list and have a function sort it".Quote from: BC_Programmer on February 01, 2013, 05:39:53 PM

The reason I pointed out the "a string containing the math and then the interpreter would execute it." You are basically saying "I think the easiest way to interpret some script is to have it in a string and then have an interpreter execute it"... it doesn't actually say anything but what you plan to do. It's not an algorithm. It's like saying "I think the best way to sort a list is to have a list and have a function sort it".

This is what I was getting at.

Solve : What type of VM or interpreter would this be??

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment