Interpreters

Then do they just insert opcodes into memory whilst the script is being read, and it executes them? Or what?

Help please, thanks.

No, nothing so low-level. Generally each opcode represents a function that gets called.

As for whether interpreted languages have a place in the ''real-time'' world, that depends on what your definition of real-time is.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

quote:

---

Original post by Khaos
Does it use some sort of emulating, virtual machine to execute code on? Or does it execute the instructions as it reads them, or they are inputted, and if so, how?

---

There are lots of different schemes for how the instructions will be despatched. All of those you mention are valid ways of doing it. In fact, there is a very blurred distinction between the meanings of interpreter' and compiler'.

For a simple scheme, you could write a primitive interpreter which despatches commands off to be executed as soon as a complete command (including its operands) has been found in the input. Suppose you invent a language which has commands set' for setting the value of a variable, add' for adding to the value of a variable, and `print' to print the value of a variable. We need to specify a grammar for how these statements might look. Here's something suitably primitive and easy to write an interpreter for...

program := statement+
statement := set-statement | add-statement | print-statement
set-statement := "set" var val
add-statement := "add" var val
print-statement := "print" var
  

This means that a program consists of a series of statements. A statement is either a set-statement, add-statement or print-statement. Each of those statements begins with a command which identifies what type of statement it is. That makes it very easy to write a parser since we don't need to look at any of the tokens after the command to figure out what type of command we are parsing.

So, here's some C++ code (rather crude, no error-recovery) which will interpret programs which adhere to the above grammar:

#include <vector>
#include <iostream>
#include <string>
#include <sstream>
#include <fstream>
#include <map>

std::map<std::string, int> vars;

void despatch_set(const std::string& var, int val)
{
	vars[var] = val;
}

void despatch_add(const std::string& var, int val)
{
	vars[var] += val;
}

void despatch_print(const std::string& var)
{
	std::cout << vars[var] << "\n";
}

bool despatcher(std::istream& input)
{
	std::string command;
	input >> command;
	if(input)
	{
		if(command == "set")
		{
			std::string var;
			int val;
			input >> var >> val;
			despatch_set(var, val);
		}
		else if(command == "add")
		{
			std::string var;
			int val;
			input >> var >> val;
			despatch_add(var, val);
		}
		else if(command == "print")
		{
			std::string var;
			input >> var;
			despatch_print(var);
		}
		else
			throw "Syntax error";
		return true;
	}
	else
		return false;
}

int main(int argc, char *argv[])
{
	if(argc < 2)
	{
		std::cerr << "Usage is " << argv[0] << " <script-name>\n";
		return EXIT_FAILURE;
	}
	std::ifstream ifs(argv[1]);
	while(despatcher(ifs))
		;
}

Compile this program, then create a script file for it to run. For example, create a file called script.txt with the following contents:

set i 0
print i
add i 5
print i
add i 7
print i  

Now invoke your program to run the script (if your program is runscript.exe, then type "runscript script.txt" at the command prompt). The contents of script.txt will be intepreted and executed as the program runs.

quote:

---

Do you believe interpreted languages have a place, in the real-time world, or no?

---

Obviously yes.


[edited by - SabreMan on October 17, 2003 9:45:47 AM]

quote:

---

Original post by Anonymous Poster

quote:

---

Original post by SabreMan
In fact, there is a very blurred distinction between the meanings of interpreter'' and compiler''.

---

Sorry, that isn''t true. An interpreter performs evaluation of a program while a compiler translates a program into a different language, most often times assembly. You could try to argue that an interpreter transforms a program into the value domain specified by the language, but that''s reaching. Interpretation and compilation are two very different things.

---

Actually that depends. Ever heard of DRs (dynamic-recompilers)?

quote:

---

Original post by Kylotan
No, nothing so low-level. Generally each opcode represents a function that gets called.

As for whether interpreted languages have a place in the ''real-time'' world, that depends on what your definition of real-time is.

---

It depends on whether or not you can bound the execution time of your interpreter, and that it''s fast enough to do the job. You could also say that a CPU is a RT interpreter, unless we should restrict the term interpreter to human-readable languages.

quote:

---

Anonymous Poster
An interpreter performs evaluation of a program while a compiler translates a program into a different language, most often times assembly. You could try to argue that an interpreter transforms a program into the value domain specified by the language, but that''s reaching. Interpretation and compilation are two very different things.

---

I concur; While they both perform translation, an interpreter executes the program, a compiler does not. I don''t see any ambiguity.

quote:

---

Original post by Khaos
Or does it execute the instructions as it reads them, or they are inputted, and if so, how?

---

The typical interpreter executes each instruction as it reads it. BASIC worked this way, among many others. Pre-compiling to byte-code is much more efficent (compiling is hard work), but less flexible. With an interpreter, you can make changes and run them right-there-and-then. With byte-code, you have to recompile.

quote:

---

How can you just translate the code to a low level and tell the computer to run it, without putting it into a file of sorts, or a location in memory, dealing with the operating system to allocate it and such?

---

Well you can't; you have to do all that. You don't have to actually create a PE or ELF, but you have to translate the commands to function your interpreter provides. Think of it as a data file on steriods. You open the text file, read in a line and start creating a program-state from what you read in. You make a symbol-table to look-up variables (where they are in memory), and have functions to add numbers and index arrays etc...

quote:

---

Do you believe interpreted languages have a place, in the real-time world, or no? Thoughts? Comments? Thanks!

---

No, I don't. For real-time code, you should use proven tools and produce machine code.

Most code does not need to be real-time though. Games are not real-time programs. The appropriate term, on-line, has fallen out of use, due to the confusion with the use of the term and the Internet. It’s on-line processing, as opposed to off-line processing. Can we get the job done and show it on the screen as it happens? Real-time means you *must* get the job done on time, or something bad happens (the missile misses the target, the Mars Lander becomes a scrap heap). With a game, you can tolerate an inconsistent fps. Real-time is more about consistency than throughput.

[edited by - Magmai Kai Holmlor on October 17, 2003 10:46:05 PM]

quote:

---

Original post by Anonymous Poster
Sorry, that isn''t true. An interpreter performs evaluation of a program while a compiler translates a program into a different language, most often times assembly.

---

An interpreter may compile instructions, which blurs the distinction.

quote:

---

Original post by Magmai Kai Holmlor
No, I don''t. For real-time code, you should use proven tools and produce machine code.

---

I don''t think you can support that statement, since you are effectively claiming that interpreted languages never have a place in real-time environments, which is clearly not the case. If a program gets its tasks complete in the allowed time, then it is completely irrelevant whether it is compiled or intepreted.

quote:

---

Real-time means you *must* get the job done on time, or something bad happens (the missile misses the target, the Mars Lander becomes a scrap heap).

---

That would be *hard* real-time. The meaning of just `real-time'' is a bit more permissive - it means that you are working with a time constraint (and even that is a little fuzzy... most real-world problems involve a time constraint).

quote:

---

Original post by Khaos
[...]Do you believe interpreted languages have a place, in the real-time world, or no? Thoughts? Comments? Thanks!

---

I believe they do - a good example would be the QuakeC used by quake 1. Its not interpreted text though, its compiled to bytecode and run from that. If quake 1 (a revolutionary game in its time) can manage software 3d rendering AND a bytecode language running in realtime on old machines I think most games(the most realtime kind of app I can think of) running on 3d cards and multi GHz machines with hundred(s) MB of ram can manage to use ''scripting languages'' for all the logic and some of the other stuff AT LEAST.

quote:

---

Does it use some sort of emulating, virtual machine to execute code on? Or does it execute the instructions as it reads them, or they are inputted, and if so, how?

---

Yes.

quote:

---

How can you just translate the code to a low level and tell the computer to run it, without putting it into a file of sorts, or a location in memory, dealing with the operating system to allocate it and such?

---

This is highly non-trivial.

Usually, 'intepreted' programs are not translated into machine code and directly executed, primarily because one of the reasons for having interpreted programs (but by no means the only one) is that they can be prevented from doing nasty stuff to your computer, which is handy if your game allows players to use mods.

quote:

---

How does an interpreter work, specifically? Any resources for constructing one?

---

I'm not aware of any obvious ones. However, note that you can get libraries for embedding scheme, perl, Python, Ruby, and many other 'scripting' languages in programs. There's no need for you to implement an interpreter.

quote:

---

Do you believe interpreted languages have a place, in the real-time world, or no?

---

Certainly they do. Of the top of my head, Quake, Quake 3, Unreal* and Severance all use (or can use, in the case of Quake 3) intepreted languages. They don't seem to be unreasonably slow for it.

---

The distinction between compilers and interpreters is a nonsensical one. It's like drawing a distinction between an engine and a steering wheel -- they aren't the same kind of thing, although they are part of a greater system.

An interpreter is a program which reads data which represents processing instructions, and executes those processing instructions. The most useful distinction to draw at the interpreter level is that some interpreters are implemented in hardware (my computer's CPU contains an interpreter that executes x86 binary instructions), whilst some are implemented in software (my computer contains an intepreter for Java bytecode).

What is usually called a compiler is properly termed a translator, and is a program that translates a program from one form to another. I have a translator that translates from C/C++ (source files) to assembly, and another that translates from assembly to machine code (object files). In addition, I have a program called a 'linker' that combines multiple object files into one, often executable, object archive. On most modern operating systems, the OS also performs further linking at run-time.

The relationship is easy to see with languages are usually used with software intepreters.

Python has an interpreter which incorportates a compiler. Python bytecode is generated for imported modules -- for foo.py, a compiled foo.pyc is produced.

Java has a compiler which generates foo.class from foo.java. foo.class is then executed with an interpreter.

With Scheme, there are other options. Scheme programs may be executed directly, compiled into bytecode, compiled into native code, or any combination of these, depending upon what your implementation supports.


[edited by - Mayrel on October 20, 2003 6:24:21 PM]

What do you think the possibility of a interpreted game would be? Not only something like Minesweeper or Pong/Tetris, but even something on the likes of A C&C real-time strategy game, or a Goldeneye-esque first person shooter, etc. Are interpreted games possible? Or is that something that greatly depends on the hardware?

Also, in languages like Ruby, are you running a virtual machine, a la Java? Or is that not the same thing as a console-based interpreter? I''m not really sure of the difference. And also when, in Ruby, you say: puts "hello"; is that calling a DOS-based text output routine (in C++), such as: cout << "hello"? Does the language you build it in shine right through as the basis for all commands? Or is there a custom routine that does not use ANY OS-specific code to [output text]?

Excuse the questions, I know there are many. Please, take a stab at anything you understood me asking, and can answer. Any help is appreciated. Thank you! And thank you for the previous replies. They have helped very much in compiling information on this subject.

quote:

---

Original post by Khaos
What do you think the possibility of a interpreted game would be? Not only something like Minesweeper or Pong/Tetris, but even something on the likes of A C&C real-time strategy game, or a Goldeneye-esque first person shooter, etc. Are interpreted games possible? Or is that something that greatly depends on the hardware?

---

Nothing wrong with the idea, in principle. However, it is likely that bottlenecks in the code will need to be reimplemented in a native-code language.

quote:

---

Also, in languages like Ruby, are you running a virtual machine, a la Java? Or is that not the same thing as a console-based interpreter? I''m not really sure of the difference.

---

I presume that Ruby uses a virtual machine. I''d imagine that Ruby commands you type interactively are compiled or at least partially compiled, to some degree. However, it''s all intepreted, which ever way you look at it. I can''t imagine that a Ruby module, loaded non-interactively would not be bytecode compiled.

quote:

---

And also when, in Ruby, you say: puts "hello"; is that calling a DOS-based text output routine (in C++), such as: cout << "hello"? Does the language you build it in shine right through as the basis for all commands? Or is there a custom routine that does not use ANY OS-specific code to [output text]?

---

Not for Ruby, there isn''t, and rightly so. Internally, puts "hello"; will use the OS to write to the screen.

quote:

---

They have helped very much in compiling information on this subject.

---

Pun intentional?