Probably not well enough for a game, no. But the Apple II[1] and even the Apollo Guidance Computer[2] used interpreted bytecode to make their programs more compact. (The AGC actually had near-seamless interworking between native code and bytecode!) Also Pascal P-code, Microsoft BASIC’s pretokenized source, almost every Forth implementation ever, etc. The performance cost was pretty significant as you’d expect, but the result was still fast enough for the task.
It was also pretty common to use more capable machines to get some headroom for development tools, either by compiling for one (DOOM on NeXT) or by cross-debugging the system under test from it (a still-in-progress Lisa when developing the Macintosh; a DEC minicomputer, IIUC, when developing MS-DOS). You still do the former when you run an x86-64 image in your Android emulator; you probably still do the latter if you are targeting a microcontroller.
Probably not well enough for a game, no. But the Apple II[1] and even the Apollo Guidance Computer[2] used interpreted bytecode to make their programs more compact. (The AGC actually had near-seamless interworking between native code and bytecode!) Also Pascal P-code, Microsoft BASIC’s pretokenized source, almost every Forth implementation ever, etc. The performance cost was pretty significant as you’d expect, but the result was still fast enough for the task.
It was also pretty common to use more capable machines to get some headroom for development tools, either by compiling for one (DOOM on NeXT) or by cross-debugging the system under test from it (a still-in-progress Lisa when developing the Macintosh; a DEC minicomputer, IIUC, when developing MS-DOS). You still do the former when you run an x86-64 image in your Android emulator; you probably still do the latter if you are targeting a microcontroller.
[1] https://en.wikipedia.org/wiki/SWEET16
[2] https://media.ccc.de/v/34c3-9064-the_ultimate_apollo_guidanc...