QuakeC bytecode docs?

[JasonX]

Is there any docs on the QuakeC bytecode? I'm writing a small language that compiles into QuakeC byte code as an experiment and could not find much info about it.

[Seven]

Hello JasonX,

I am not quite sure what you mean.
If you mean the different existing WRITEBYTE cases, please look into this interesting thread:
viewtopic.php?f=2&t=848
It also links to a site with a list of all variations.

Best regards,
Seven

[goldenboy]

I believe he means the stuff that comes out of a QC compiler, ie the format of the stuff in a progs.dat.

[Spike]

seven, no, he means the stuff generated by a qcc inside the progs.dat itself.

read pr_exec.c for 'docs', don't think anyone cared enough to properly document them.
mostly they're just A OP B->C
there's also 2-operand instructions (stores and unary operators) which take their input in A and store into B instead of C, and don't use C.
OP_GOTO stores an instruction count offset (signed) in its A operand. OP_IF/OP_IFNOT contain their condition boolean within A, and their instruction offset in B.

with fteqcc, you can use the -fwrasm commandline argument to get fteqcc to write out a 'qc.asm' file containing a text-based representation of the opcodes generated, if you want to see a readableish example.
you'll need to check the engine or a qcc to get the numerical value of each opcode.

note that you'll still need to figure out the globaldef, function, fielddef, etc sections too.

[JasonX]

Thanks, Spike. I didn't know about fwrasm. This will be very useful, since after crawling through qcc's source, i could not find a proper lexer structure to find my way into the opcodes.

[taniwha]

The "opcode table" is in pr_parse.c. Look for pr_opcodes. I consider that table to be an abomination, but then, that's part of why II almost completely re-wrote the compiler (qfcc)

[JasonX]

There are different opcodes for different types... float, vector, entity and function. This is very strange. But thank you for the file... i'm basing myself on ProQCC: https://github.com/lbsmith/ProQCC/blob/ ... /pr_comp.c

[taniwha]

Up until OP_BITOR (last qcc opcode), all compilers will generate the same opcodes, so it doesn't really matter which compiler you study. For that, anyway (eg, qfcc is radically different: flex lexer, bison parser, expression trees, statement blocks, Objective-QuakeC data-structures (in theory, compatible with Objective-C, but I suspect I may have broken a few things there), object files, linker, library files, cpp preprocessing...).

[Spike]

proqcc should be readable at least.
but yeah, the instruction set is the same regardless of qcc. qfcc and fteqcc both support (separate) extended opcodes for their respective engine, but engine support for these extra opcodes are somewhat rare, and likely not enabled by default.

the exact behavior of the opcodes is not the only thing you have to contend with, but also the function/globaldef/fielddef tables will need to be in place before you can really test anything.