5

I'm implementing a stack-based virtual machine in C.

The following variables are used by pretty much every function:

  • memory array
  • various pointers to memory offsets
  • program counter
  • stack
  • stack pointer
  • frame pointer (less so)

Ordinarily, I'd avoid the use of globals. However, in this situation handing these around between functions seems cumbersome, particularly as I need to pass in a pointer to the pointers and counters to update them.

I could alternatively put them in a struct and hand that around.

This is by no means a performance constrained VM given the speeds of modern processors.

Would using globals be an acceptable or typical tradeoff in this particular scenario?

1
  • 3
    Whether it's acceptable or not is entirely up to you to decide. You're the only one who fully understands your design tradeoffs. Commented Nov 20, 2020 at 13:38

4 Answers 4

6

Usage of globals is a matter of scope of the program "around" them.

If this "stack-based virtual machine" is the whole program, and the statement "...variables are used by pretty much every function" is literally true (and not an exaggeration), then making those variables global is perfectly fine.

However, if this "stack-based virtual machine" is just a module of a larger program, I would recommend against making the mentioned variables globally visible.

In case the "stack-based virtual machine" is starting as one program, and becoming a module of a larger program at a later point in time, one should take the time and refactor any "globals" as soon as the second case can be foreseen.

1
  • It is indeed the whole program, running as an isolated process. The variables are accessed by the fetch->decode->execute loop continuously as the it executes. Thanks for the scope clarification. That helps a lot
    – retrodev
    Commented Nov 20, 2020 at 14:42
2

Since the entire purpose of your program is to emulate a system with a hardware-defined, unalterable set of globally available resources, modelling these as a fixed set of globally available resources is perfectly fine; it reflects the structure of the domain object accurately.

Of course, you might still want to encapsulate all of these at not quite the global level, but as members of a class that models one instance of the entire machine. After all, virtualization is everywhere these days, and you often end up using several instances of something that you'd have sworn would only ever be there once at a time. But since you say you're writing in C, which doesn't easily lend itself to creating classes like this, I'd say this would be over-engineering at the moment.

1

Look at the Factor language (wikipedia entry), implemented by Slava Pestov, which is a stack-based language having a virtual machine implemented in C. His language is most excellent, with many language features implementable by library. I believe that his small VM is written with globals, but I'm not sure. But it really doesn't matter because the language cannot access any of the internals of the vm (unless they've been purposely exposed in the language). You should be just fine using globals. A VM has to be performant, and using globals helps.

Another language to look at is pForth (Portable Forth), another stack-based language having a VM written in C, with the rest written in the Forth stack-based language, an excellent language (having a standardized version called ANS Forth).

0

If you ever intend for your virtual machine to support threads, you might consider using an object at least for thread state.

Nominally, each thread will need its own pc, stack, stack pointer.  Threads would probably share the global data and heap memory.

1
  • Similarly - if you intend for the VM to be embedded in some other program an global context object would be very useful. And required if you intend to have it be instantiated more than once in the same executable (with different scripts running with their disjoint (separate) state).
    – davidbak
    Commented Nov 21, 2020 at 1:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.