[Suggestion] Ability to view generated bytecode

[rHermes]

This might be interessting to just a very few people, but I would personally very much like the ability to view the byte code that is generated from the code. Since its been stated that the compiler is still very
simple, it could help figure out what kind of code that makes it generate badily optimized instructions
and also how expensive certain function calls are.

A side note is that it would also help in the effort to report situations where the compiler could be improved, but I don't know if this is a priorty or not.

[linleyh]

it could help figure out what kind of code that makes it generate badily optimized instructions

Any kind of code makes it generate badly optimised instructions!

There's actually an undocumented compile-time function to do this, which I used to debug the compiler when I was writing it. If you uncomment the line
//#define PRINT_INTERCODE
at around line 3051 of c_compile.c, compiling will send the intermediate code (intercode, which reflects the bytecode pretty closely) to stdout in the format:
[intercode position][source line] opcode <operands>
There's a list of opcodes near the start of c_compile, although it's a little opaque at the moment. Also, the output gets a bit confusing with strings (which are output as lists of numbers) and "exit points" (which are jump destinations used for various purposes) everywhere.

Maybe I should clean this up a bit to make it more useful. Is fprintf to stdout a reasonable way to display the code?

[rHermes]

I don't have the ability to compile your project on Windows right now, so if there was a possibilty of making the PRINT_INTERCODE directive be an option in init.txt instead, I think that would be great.

In the short term fprintf to stdout is good enough for me, but I think an ingame display would be a neccecarry step for implementing the debugger described in issue #17, as you would need to display the code the proccess was executing to be able to see what is what doing.