Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

VM instruction implementation without huge switch()?

Name: Anonymous 2014-06-09 23:26

How would one go about making a virtual machine without using a huge and clumsy switch( opcode ) statement?

The architecture I'm implementing (DCPU-16) has about 35-40 different instructions.

Name: Anonymous 2016-10-24 15:56

First we familiarize ourselves with https://en.wikipedia.org/wiki/Visitor_pattern and refactor the bindings into container classes which would be dependently injected in polymorphic virtual functions using the https://en.wikipedia.org/wiki/Command_pattern encapsulated inside safe AbstractFactory methods.

Name: Anonymous 2016-10-24 17:32

You write the VM in something other than C.

Name: mentifex 2016-10-24 18:29

>>1

Why not make an array with function pointers? Enumerate each instruction and then lookup the function pointer and pass it the auxiliary data.

Name: mentifex 2016-10-24 18:37

Or better yet, write it in vhdl, compile it with ghdl and you have your processor ready for fpga and a nice event based simulation in C.

Name: Anonymous 2016-10-25 1:43

>>41

You're insane. Or joking. One of the two.

>>1

As far as maintainability and whatnot go, branch tables using arrays of function pointers are the way to go. But the compiler can't optimize as well.

Better yet, write a perl script that takes an input file mapping opcodes to functions and generates the switch table for you.

This is a great idea, and totally can't go wrong in literally 100s of ways.

Name: Anonymous 2016-10-25 2:02

>>45
How exactly are arrays of function pointers more maintainable than a switch statement?

Name: Anonymous 2016-10-25 2:14

>>46 Its easy, you use the techniques described in >>41

Name: Anonymous 2016-10-25 13:20

>>47

Not at all. It's just that you're using less verbose code, and it reads cleaner, IMHO, which counts for a lot.

Name: Anonymous 2016-10-25 20:20

write it in assembly code instead of c.

then you can compute your jumps with arithemtic!

Name: Anonymous 2016-10-26 1:05

So when I write a big switch with like 100 or so branches, like this:
switch(op) {
case 0: /*...*/ break;
case 1: /*...*/ break;
case 2: /*...*/ break;
case 3: /*...*/ break;
...
case 100: /*...*/ break;
}
with the conditions always incrementing and being in order, won't a modern compiler optimize it for me?

Name: Anonymous 2016-10-26 1:19

>>50
won't a modern compiler optimize it for me?
Microsoft C converts these to jump table and HexRays then has problems decompiling it properly, thinking that jumps are funcalls.

Name: Anonymous 2016-10-26 1:21

>>50

Also, for smaller tables, it can be much more efficient to use if/else, because of CPU branch prediction.

Name: Anonymous 2016-10-26 1:30

http://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables

Name: Anonymous 2016-10-26 2:51

>>52
Why wouldn't branch prediction apply to switch statements? They're still just conditional jumps in machine code.

Name: Anonymous 2016-10-26 3:14

>>54
It is harder to predict table[opcode]() than to predict if (opcode==1) {...} else {...}. Unconditional jump can be predicted only when it usually resolves to some single function.

Name: Anonymous 2016-10-26 4:09

>>54
he's an idiot/liar. nothing he says is correct. He's just guessing to try to sound smart at the smart peoples table (/prog/).

This shit never used to happen on old /prog/, we just knew that everybody only spoke when they had something of value to contribute and nobody would recommend anything if they had not actually done it themselves and performed the measurements.

Todays nu-/prog/ is full of the same cancer that filled up IRC channels on freenode. Casuals that make 'witty' little remarks with no content to look smart in front of everybody else. The real wizards are long gone. What a tragedy.

Name: Anonymous 2016-10-26 4:34

>>56
enjoy being trolled like a dolt.

Name: Anonymous 2016-10-26 8:11

>>53
Yeah, I've already seen that. I just prefer to write C89, not GNU C.
But the article does indeed explain my question: apparently switch has to do some additional bounds checking (C89 3.6.4.2).

Name: Cudder !cXCudderUE 2016-10-26 10:59

>>45
That is what those infected with the disease of ENTERPRISE will seriously say.

Just use a switch. 35-40 cases is not at all large for a switch. Many 8-bit emulators will have 256, and the VNVM I'm analysing at the moment has around 270.

Name: Anonymous 2016-10-26 17:42

>>4
this, or a hash table that references function pointers

Name: Anonymous 2016-10-27 1:28

>>59
40 cases is not at all large for a switch

Name: xD !sDNR5LgF8Y 2016-10-27 5:20

>>60,61

le pedophile sage

Name: Cudder !cXCudderUE 2016-10-29 3:43

>>61
Considering the C89 standard requires up to 257 (default + one for each byte, think of state machines), and C99 increased that to 1023 (no idea of the rationale for that one), 40 is certainly not large at all. C++ increased that even more to 16K(!)

Name: Anonymous 2016-10-29 8:06

COMMODORE 64 GET

Name: Anonymous 2016-10-29 15:28

>>63
C99 increased that to 1023
Probably related to the compiler having to store a jump table with that much entries, not byte size.

C++ increased that [...] to 16K
That's just wasteful.
Remember that a C89 compiler can be implemented for a machine with like 1MiB of RAM (probably the biggest culprit: #defines: up to 1024*(499+31) bytes).

Polite sage for offtopic.

Name: Anonymous 2016-10-29 17:27

Dubs check dubs

Name: Anonymous 2016-10-29 17:43

>>66
Nice dubz, bro!

Name: Anonymous 2016-10-29 20:08

>>65
Remember that a C89 compiler can be implemented for a machine with like 1MiB of RAM
A PL/I compiler can run in 32 KB of RAM and the compiled programs can run on even smaller machines. I'd rather use PL/I than any C-based or dynamically typed language any day.

Name: Anonymous 2016-10-30 1:20

Check em

Name: Anonymous 2016-10-30 6:12

Why dcpu 16? Notch is never making that game
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -