3 ms·
It actually does interpret bytecode, you can see the opcode definitions here https://github.com/chrismaltby/gb-studio/blob/1f995a976bd3aa5579ed86678912f59ed3a42
by ehaliewicz2 3y ago
It actually does interpret bytecode, you can see the opcode definitions here https://github.com/chrismaltby/gb-studio/blob/1f995a976bd3aa5579ed86678912f59ed3a42ddb/appData/src/gb/include/vm.i#L52 https://github.com/chrismaltby/gb-studio/blob/1f995a976bd3aa...
The trick is that a lot of the heavier stuff is implemented in assembly and this is mostly used for scripting (from what I understand).
- djxfade 3y agoYes exactly. It's not a zero cost abstraction, but it's a very simple format, each byte code oppose maps directly to function and passes its args. So it's basically just a conditional jump
- Waterluvian 3y agoOh wow. So surprised this is viable on a 4 (1, really) MHz processor. Thanks for clarifying and sharing, you both!
- kmill 3y agoYou might also like the fact that the Apollo Guidance Computer (which ran at a similar speed) was also programmed using something like bytecodes. It didn't have to drive a graphical display though, only a spaceship.
- Waterluvian 3y ago“Only a space ship.” yawns Ahahaha. But my understanding was that they wanted it to be somewhat field programmable? You can tediously write in a program with all the VERB NOUN stuff?
- kmill 3y agoThe verb/noun stuff I understand was the UI for the astronauts (the DSKY). There was also the native instruction set for the CPU as well as an interpreter with a richer instruction set built on top of that, and they used this to more easily write complex navigation programs. Wikipedia mentions some of this at https://en.wikipedia.org/wiki/Apollo_Guidance_Computer https://en.wikipedia.org/wiki/Apollo_Guidance_Computer around the phrase "virtual machine." I'm not sure it being interpreted code would aid in field reprogrammability, since it would have been woven into the rope memory just like the rest of the software.