qf
/
quakeforge
mirror of https://git.code.sf.net/p/quake/quakeforge
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
quakeforge/libs/gamecode/opcodes.py

659 lines
18 KiB
Python
Raw Normal View History

[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
bitmap_txt = """
0 0000 mmss load
0 0001 mmss store
0 0010 mmss push
0 0011 mmss pop
0 1ccc ttss compare
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
0 0000 00nn
[gamecode] Add instructions for stack adjust, nop, and ldconst ldconst isn't implemented yet but the plan is to load various constants (eg, 0, 1, 2, pi, e, ...). Stack adjust is useful for adding an offset to the stack pointer without having to worry about finding it (and it checks for alignment). nop is just that :)
2022-01-21 09:44:51 +00:00
0 0000 0000 noop
0 0000 0001 adjstk
0 0000 0010 constant
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
0 1011 nnnn
0 1111 nnnn
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
1 0ooo ttss mathops
1 011r tuss shiftops
1 0110 o1oo string
1 1ccc t0ss compare2
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
1 1t00 ooss bitops
1 1001 01mm jump
1 1001 11mm call (return specified st->c)
1 1001 1100 return (size in st->c)
1 1010 t1ss scale
1 1010 t100 swizzle
1 1011 tooo vecops
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
1 1101 01oo move
1 1101 11oo memset
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
1 1101 c111 statef
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
1 1110 c1cc branch
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
1 1110 c111 stated
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
1 1111 00mm lea
1 1111 01td vecops2
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
1 1111 10nn
1 1111 1100 convert (conversion mode in st->b)
1 1111 1101 with (mode in st->a, value in st->b, reg in st->c)
1 1111 1110
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
1 1111 1111 hops
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"""
[gamecode] Generate the new opcodes enum too It turns out I'll be tweaking it more than I expected.
2022-01-08 16:04:51 +00:00
import copy
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
address_mode = "ABCD"
address_types = [
"ev_void, ev_invalid",
"ev_entity, ev_field",
"ev_ptr, ev_short",
"ev_ptr, ev_int",
]
[gamecode] Correct the widths for load, store and lea The different addressing modes complicate the width calculations, and lea is particularly fun in that it doesn't care what the width of value is.
2022-01-20 07:33:04 +00:00
address_widths = [
[ "1, 0", "1, 1", "1, 0", "1, 1", ],
[ "2, 0", "1, 1", "1, 0", "1, 1", ],
[ "3, 0", "1, 1", "1, 0", "1, 1", ],
[ "4, 0", "1, 1", "1, 0", "1, 1", ],
[ "-1, 0", "1, 1", "1, 0", "1, 1", ],
]
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
#store, pop and lea
store_fmt = [
"%ga",
"%Ga.%Gb(%Ea)",
"*(%Ga + %sb)",
"*(%Ga + %Gb)",
]
# load and push
[gamecode] Fix incorrect entity load format Had a typo in load and forgot to edit lea, but now they share the formats (like they should have in the first place).
2022-01-06 02:51:38 +00:00
load_fmt = [
"*%Ga, %gc",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"%Ga.%Gb(%Ea)",
"*(%Ga + %sb)",
"*(%Ga + %Gb)",
[gamecode] Fix incorrect entity load format Had a typo in load and forgot to edit lea, but now they share the formats (like they should have in the first place).
2022-01-06 02:51:38 +00:00
]
branch_fmt = [
[gamecode] Fix some more operand formats With and relative branches.
2022-01-06 13:27:09 +00:00
"branch %sa (%Oa)",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"*%Ga",
"%Ga[%sb]",
"%Ga[%Gb]",
]
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
compare_ccc = [ "eq", "lt", "gt", None, "ne", "ge", "le", None]
type_tt = ['I', 'F', 'L', 'D']
[gamecode] Rename ev_integer to ev_int And other related fields so integer is now int (and uinteger is uint). I really don't know why I went with integer in the first place, but this will make using macros easier for dealing with types.
2022-01-18 04:21:06 +00:00
etype_tt = ["ev_int", "ev_float", "ev_long", "ev_double"]
unsigned_t = ["ev_uint", "ev_ulong"]
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
float_t = ["ev_float", "ev_double"]
[gamecode] Fix incorrect entity load format Had a typo in load and forgot to edit lea, but now they share the formats (like they should have in the first place).
2022-01-06 02:51:38 +00:00
[gamecode] Add instructions for stack adjust, nop, and ldconst ldconst isn't implemented yet but the plan is to load various constants (eg, 0, 1, 2, pi, e, ...). Stack adjust is useful for adding an offset to the stack pointer without having to worry about finding it (and it checks for alignment). nop is just that :)
2022-01-21 09:44:51 +00:00
adjstk_formats = {
"opcode": "OP_ADJSTK",
"mnemonic": "adjstk",
"opname": "adjstk",
"format": "%sa, %sb",
"widths": "0, 0, 0",
"types": "ev_short, ev_short, ev_invalid",
}
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
bitops_formats = {
[gamecode] Drop bool ops in favor of long bit ops I realized that being able to do bit-wise operations with 64-bit values (and 256-bit vectors) is far more important than some convenient boolean logic operators. The logic ops can be handled via the bit-wise ops so long as the values are all properly boolean, and I plan on adding some boolean conversion ope, so no real loss.
2022-01-13 05:24:11 +00:00
"opcode": "OP_{op_bit[oo].upper()}_{bit_type[t]}_{ss+1}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"mnemonic": "{op_bit[oo]}",
"opname": "{op_bit[oo]}",
"format": "{bit_fmt[oo]}",
[gamecode] Correct types and widths for bitnot bitnot is the only unary operator in the bitops group and thus needs special handling.
2022-01-27 01:21:48 +00:00
"widths": "{ss+1}, { oo < 3 and ss+1 or 0}, {ss+1}",
"types": "{bit_types[t]}, {oo < 3 and bit_types[t] or 'ev_invalid'}, {bit_types[t]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
whitespace
2022-01-07 12:48:02 +00:00
"op_bit": ["bitand", "bitor", "bitxor", "bitnot"],
[gamecode] Drop bool ops in favor of long bit ops I realized that being able to do bit-wise operations with 64-bit values (and 256-bit vectors) is far more important than some convenient boolean logic operators. The logic ops can be handled via the bit-wise ops so long as the values are all properly boolean, and I plan on adding some boolean conversion ope, so no real loss.
2022-01-13 05:24:11 +00:00
"bit_type": ["I", "L"],
[gamecode] Rename ev_integer to ev_int And other related fields so integer is now int (and uinteger is uint). I really don't know why I went with integer in the first place, but this will make using macros easier for dealing with types.
2022-01-18 04:21:06 +00:00
"bit_types": ["ev_int", "ev_long"],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"bit_fmt": [
"%Ga, %Gb, %gc",
"%Ga, %Gb, %gc",
"%Ga, %Gb, %gc",
"%Ga, %gc",
],
},
}
branch_formats = {
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"opcode": "OP_{op_cond[c*4+cc].upper()}",
"mnemonic": "{op_cond[c*4+cc]}",
"opname": "{op_cond[c*4+cc]}",
"format": "{cond_fmt[c*4+cc]}{branch_fmt[0]}",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "0, 0, 1",
[gamecode] Correct some ruamoko instruction meta data There were some errors in instruction names and operand types resulting in unsearchable instructions.
2022-01-20 04:02:12 +00:00
"types": "ev_short, ev_invalid, ev_int",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
"op_mode": "ABCD",
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"op_cond": ["ifz", "ifb", "ifa", None,
"ifnz", "ifae", "ifbe", None],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"branch_fmt": branch_fmt,
[gamecode] Rearrange the branch instructions Now they're in a much more consistent arrangement, in particular with the comparison opcodes if the conditional branch instructions are considered to be fast comparisons with zero (ifnot -> ifeq, if -> ifne, etc). Unconditional jump and call fill in the gaps. The goal was to get them all in an arrangement that would work as a small enum for qfcc: it can use the enum directly for the ruamoko IS, and a small map array for v6p (except for call).
2022-01-08 16:07:23 +00:00
"cond_fmt": ["%Gc ", "%Gc ", "%Gc ", "", "%Gc ", "%Gc ", "%Gc ", ""],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
[gamecode] Rework call and return instructions The call1-8 instructions have been removed as they are really not needed (they were put in when I had plans of simple translation of v6p progs to ruamoko, but they joined the dinosaurs). The call instruction lost mode A (that is now return) and its mode B is just the regular function access. The important thing is op_c (with support for with-bases) specifies the location of the return def. The return instruction packs both its addressing mode and return value size into st->c as a 3.5 value: 3 bits for the mode (it supports all five addressing modes with entity.field being mode 4) and 5 for the size, limiting return sizes to 32 words, which is enough for one 4x4 double matrix. This, especially with the following convert patch, frees up a lot of instructions.
2022-01-10 02:38:21 +00:00
call_formats = {
"opcode": "OP_CALL_{op_mode[mm]}",
"mnemonic": "call",
"opname": "call",
"format": "{call_fmt[mm]}",
[qfcc] Set the return of Ruamoko calls Of course, I had the width of opc wrong :P. But with this, it seems that unoptimized calls should work once I get the stack frame working.
2022-01-21 04:50:21 +00:00
"widths": "{call_widths[mm]}, -1",
[gamecode] Correct call's operator types
2022-01-21 01:07:35 +00:00
"types": "{call_types[mm]}, ev_void",
[gamecode] Rework call and return instructions The call1-8 instructions have been removed as they are really not needed (they were put in when I had plans of simple translation of v6p progs to ruamoko, but they joined the dinosaurs). The call instruction lost mode A (that is now return) and its mode B is just the regular function access. The important thing is op_c (with support for with-bases) specifies the location of the return def. The return instruction packs both its addressing mode and return value size into st->c as a 3.5 value: 3 bits for the mode (it supports all five addressing modes with entity.field being mode 4) and 5 for the size, limiting return sizes to 32 words, which is enough for one 4x4 double matrix. This, especially with the following convert patch, frees up a lot of instructions.
2022-01-10 02:38:21 +00:00
"args": {
"op_mode": ".BCD",
"call_fmt": [
None, # return handled seprately
"%Ga, %gc",
"%Ga[%sb], %gc",
"%Ga[%Gb], %gc",
],
[gamecode] Correct call's operator types
2022-01-21 01:07:35 +00:00
"call_types": [
None,
"ev_void, ev_invalid",
"ev_ptr, ev_short",
"ev_ptr, ev_int",
],
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"call_widths": [ None, "1, 0", "1, 0", "1, 1" ]
[gamecode] Rework call and return instructions The call1-8 instructions have been removed as they are really not needed (they were put in when I had plans of simple translation of v6p progs to ruamoko, but they joined the dinosaurs). The call instruction lost mode A (that is now return) and its mode B is just the regular function access. The important thing is op_c (with support for with-bases) specifies the location of the return def. The return instruction packs both its addressing mode and return value size into st->c as a 3.5 value: 3 bits for the mode (it supports all five addressing modes with entity.field being mode 4) and 5 for the size, limiting return sizes to 32 words, which is enough for one 4x4 double matrix. This, especially with the following convert patch, frees up a lot of instructions.
2022-01-10 02:38:21 +00:00
},
}
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
compare_formats = {
"opcode": "OP_{op_cmp[ccc].upper()}_{cmp_type[tt]}_{ss+1}",
"mnemonic": "{op_cmp[ccc]}.{cmp_type[tt]}",
"opname": "{op_cmp[ccc]}",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "{ss+1}, {ss+1}, {ss+1}",
[gamecode] Rename ev_integer to ev_int And other related fields so integer is now int (and uinteger is uint). I really don't know why I went with integer in the first place, but this will make using macros easier for dealing with types.
2022-01-18 04:21:06 +00:00
"types": "{cmp_types[tt]}, {cmp_types[tt]}, ev_int",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
"op_cmp": compare_ccc,
whitespace
2022-01-07 12:48:02 +00:00
"cmp_type": type_tt,
"cmp_types": etype_tt,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
compare2_formats = {
"opcode": "OP_{op_cmp[ccc].upper()}_{cmp_type[t]}_{ss+1}",
"mnemonic": "{op_cmp[ccc]}.{cmp_type[t]}",
"opname": "{op_cmp[ccc]}",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "{ss+1}, {ss+1}, {ss+1}",
[gamecode] Rename ev_integer to ev_int And other related fields so integer is now int (and uinteger is uint). I really don't know why I went with integer in the first place, but this will make using macros easier for dealing with types.
2022-01-18 04:21:06 +00:00
"types": "{cmp_types[t]}, {cmp_types[t]}, ev_int",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
"op_cmp": compare_ccc,
whitespace
2022-01-07 12:48:02 +00:00
"cmp_type": ['u', 'U'],
"cmp_types": unsigned_t,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
[gamecode] Add instructions for stack adjust, nop, and ldconst ldconst isn't implemented yet but the plan is to load various constants (eg, 0, 1, 2, pi, e, ...). Stack adjust is useful for adding an offset to the stack pointer without having to worry about finding it (and it checks for alignment). nop is just that :)
2022-01-21 09:44:51 +00:00
constant_formats = {
"opcode": "OP_LDCONST",
"mnemonic": "ldconst",
"opname": "ldconst",
"format": "%sa, %sb, %gc",
"widths": "0, 0, -1",
"types": "ev_short, ev_short, ev_void",
}
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
convert_formats = {
[gamecode] Compact the convert instructions into one Thanks to Deek for the suggestion: the mode (ie, src and dst types) are encoded in st->b. Actual code not written yet, but this frees up 13 instructions: now have 74 available for really interesting stuff :)
2022-01-10 02:53:57 +00:00
"opcode": "OP_CONV",
"mnemonic": "conv",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"opname": "conv",
[gamecode] Compact the convert instructions into one Thanks to Deek for the suggestion: the mode (ie, src and dst types) are encoded in st->b. Actual code not written yet, but this frees up 13 instructions: now have 74 available for really interesting stuff :)
2022-01-10 02:53:57 +00:00
"format": "%Ga %Cb %gc",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "-1, 0, -1",
[gamecode] Compact the convert instructions into one Thanks to Deek for the suggestion: the mode (ie, src and dst types) are encoded in st->b. Actual code not written yet, but this frees up 13 instructions: now have 74 available for really interesting stuff :)
2022-01-10 02:53:57 +00:00
"types": "ev_void, ev_short, ev_void",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
}
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
hops_formats = {
"opcode": "OP_HOPS",
"mnemonic": "hops",
"opname": "hops",
"format": "%Ga %Hb %gc",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "-1, 0, 1",
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"types": "ev_void, ev_short, ev_void",
}
jump_formats = {
"opcode": "OP_JUMP_{op_mode[mm]}",
"mnemonic": "jump",
"opname": "jump",
[gamecode] Correct some ruamoko instruction meta data There were some errors in instruction names and operand types resulting in unsearchable instructions.
2022-01-20 04:02:12 +00:00
"format": "{jump_fmt[mm]}",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "{jump_widths[mm]}, 0",
[gamecode] Correct some ruamoko instruction meta data There were some errors in instruction names and operand types resulting in unsearchable instructions.
2022-01-20 04:02:12 +00:00
"types": "{jump_types[mm]}",
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"args": {
"op_mode": "ABCD",
[gamecode] Correct some ruamoko instruction meta data There were some errors in instruction names and operand types resulting in unsearchable instructions.
2022-01-20 04:02:12 +00:00
"jump_fmt": branch_fmt,
"jump_types": [
"ev_short, ev_invalid, ev_invalid",
"ev_ptr, ev_invalid, ev_invalid",
"ev_ptr, ev_short, ev_invalid",
"ev_ptr, ev_int, ev_invalid",
],
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"jump_widths": [ "0, 0", "1, 0", "1, 0", "1, 1" ]
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
},
}
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
lea_formats = {
"opcode": "OP_LEA_{op_mode[mm]}",
"mnemonic": "lea",
"opname": "lea",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"format": "{lea_fmt[mm]}, %gc",
[gamecode] Correct the widths for load, store and lea The different addressing modes complicate the width calculations, and lea is particularly fun in that it doesn't care what the width of value is.
2022-01-20 07:33:04 +00:00
"widths": "{lea_widths[mm]}, 1",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"types": "{lea_types[mm]}, ev_ptr",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"op_mode": address_mode,
"lea_fmt": store_fmt,
"lea_types": address_types,
[gamecode] Correct the widths for load, store and lea The different addressing modes complicate the width calculations, and lea is particularly fun in that it doesn't care what the width of value is.
2022-01-20 07:33:04 +00:00
"lea_widths": address_widths[4],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
load_formats = {
"opcode": "OP_LOAD_{op_mode[mm]}_{ss+1}",
"mnemonic": "load",
"opname": "load",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"format": "{load_fmt[mm]}, %gc",
[gamecode] Correct the widths for load, store and lea The different addressing modes complicate the width calculations, and lea is particularly fun in that it doesn't care what the width of value is.
2022-01-20 07:33:04 +00:00
"widths": "{load_widths[ss][mm]}, {ss+1}",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"types": "{load_types[mm]}, ev_void",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"op_mode": address_mode,
[gamecode] Fix incorrect entity load format Had a typo in load and forgot to edit lea, but now they share the formats (like they should have in the first place).
2022-01-06 02:51:38 +00:00
"load_fmt": load_fmt,
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"load_types": address_types,
[gamecode] Correct the widths for load, store and lea The different addressing modes complicate the width calculations, and lea is particularly fun in that it doesn't care what the width of value is.
2022-01-20 07:33:04 +00:00
"load_widths": address_widths,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
mathops_formats = {
"opcode": "OP_{op_math[ooo].upper()}_{math_type[tt]}_{ss+1}",
"mnemonic": "{op_math[ooo]}.{math_type[tt]}",
"opname": "{op_math[ooo]}",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "{ss+1}, {ss+1}, {ss+1}",
"types": "{math_types[tt]}, {math_types[tt]}, {math_types[tt]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
"op_math": ["mul", "div", "rem", "mod", "add", "sub", None, None],
whitespace
2022-01-07 12:48:02 +00:00
"math_type": type_tt,
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"math_types": etype_tt,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
memset_formats = {
"opcode": "OP_MEMSET_{op_memset[oo].upper()}",
"mnemonic": "memset.{op_memset[oo]}",
[gamecode] Correct types and opname for memset and move
2022-01-26 03:26:12 +00:00
"opname": "memset{op_memset[oo]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"format": "{memset_fmt[oo]}",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "{memset_widths[oo]}",
[gamecode] Correct types and opname for memset and move
2022-01-26 03:26:12 +00:00
"types": "{memset_types[oo]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"op_memset": ["i", "p", "pi", None],
"memset_fmt": ["%Ga, %sb, %gc", "%Ga, %Gb, %Gc", "%Ga, %sb, %Gc", None],
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"memset_widths": [
"1, 0, -1",
"1, 1, 1",
"1, 0, 1",
None,
],
[gamecode] Correct types and opname for memset and move
2022-01-26 03:26:12 +00:00
"memset_types": [
"ev_void, ev_short, ev_void",
"ev_ptr, ev_int, ev_ptr",
"ev_ptr, ev_short, ev_ptr",
],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
move_formats = {
"opcode": "OP_MOVE_{op_move[oo].upper()}",
[gamecode] Correct types and opname for memset and move
2022-01-26 03:26:12 +00:00
"mnemonic": "move.{op_move[oo]}",
"opname": "move{suff_move[oo]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"format": "{move_fmt[oo]}",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "{move_widths[oo]}",
[gamecode] Correct types and opname for memset and move
2022-01-26 03:26:12 +00:00
"types": "{move_types[oo]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"op_move": ["i", "p", "pi", None],
[gamecode] Correct types and opname for memset and move
2022-01-26 03:26:12 +00:00
"suff_move": ["", "p", "p", None],
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"move_fmt": ["%Ga, %sb, %gc", "%Ga, %Gb, %Gc", "%Ga, %sb, %Gc", None],
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"move_widths": [
"-1, 0, -1",
"1, 1, 1",
"1, 0, 1",
None,
],
[gamecode] Correct types and opname for memset and move
2022-01-26 03:26:12 +00:00
"move_types": [
"ev_void, ev_short, ev_void",
"ev_ptr, ev_int, ev_ptr",
"ev_ptr, ev_short, ev_ptr",
],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
[gamecode] Add instructions for stack adjust, nop, and ldconst ldconst isn't implemented yet but the plan is to load various constants (eg, 0, 1, 2, pi, e, ...). Stack adjust is useful for adding an offset to the stack pointer without having to worry about finding it (and it checks for alignment). nop is just that :)
2022-01-21 09:44:51 +00:00
noop_formats = {
"opcode": "OP_NOP",
"mnemonic": "nop",
"opname": "nop",
"format": "there were plums...",
"widths": "0, 0, 0",
"types": "ev_invalid, ev_invalid, ev_invalid",
}
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
push_formats = {
"opcode": "OP_PUSH_{op_mode[mm]}_{ss+1}",
"mnemonic": "push",
"opname": "push",
"format": "{push_fmt[mm]}",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "{ss+1}, 0, 0",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"types": "{push_types[mm]}, ev_invalid",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"op_mode": address_mode,
"push_fmt": load_fmt,
"push_types": address_types,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
pushregs_formats = {
"opcode": "OP_PUSHREGS",
"mnemonic": "pushregs",
"opname": "pushregs",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "0, 0, 0",
"types": "ev_invalid, ev_invalid, ev_invalid",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"format": None,
}
pop_formats = {
"opcode": "OP_POP_{op_mode[mm]}_{ss+1}",
"mnemonic": "pop",
"opname": "pop",
"format": "{pop_fmt[mm]}",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "{ss+1}, 0, 0",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"types": "{pop_types[mm]}, ev_invalid",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"op_mode": address_mode,
"pop_fmt": store_fmt,
"pop_types": address_types,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
popregs_formats = {
"opcode": "OP_POPREGS",
"mnemonic": "popregs",
"opname": "popregs",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "0, 0, 0",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"format": None,
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"types": "ev_invalid, ev_invalid, ev_invalid",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
}
scale_formats = {
"opcode": "OP_SCALE_{scale_type[t]}_{ss+1}",
"mnemonic": "scale.{scale_type[t]}",
"opname": "scale",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "{ss+1}, 1, {ss+1}",
"types": "{scale_types[t]}, {scale_types[t]}, {scale_types[t]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"scale_type": ['F', 'D'],
"scale_types": float_t,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
shiftops_formats = {
"opcode": "OP_{op_shift[u*2+r].upper()}_{shift_type[u*2+t]}_{ss+1}",
"mnemonic": "{op_shift[u*2+r]}.{shift_type[u*2+t]}",
"opname": "{op_shift[u*2+r]}",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "{ss+1}, {ss+1}, {ss+1}",
"types": "{shift_types[t][u]}, {shift_types[t][0]}, {shift_types[t][u]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
"op_shift": ["shl", "asr", "shl", "shr"],
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"shift_type": ['I', 'L', 'u', 'U'],
"shift_types": [
[gamecode] Rename ev_integer to ev_int And other related fields so integer is now int (and uinteger is uint). I really don't know why I went with integer in the first place, but this will make using macros easier for dealing with types.
2022-01-18 04:21:06 +00:00
["ev_int", "ev_uint"],
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
["ev_long", "ev_ulong"],
],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
statef_formats = {
"opcode": "OP_STATE_{state[c]}",
"mnemonic": "state.{state[c]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"opname": "state",
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
"format": "{state_fmt[c]}",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "1, 1, {c}",
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
"types": "ev_float, ev_func, {state_types[c]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
"state": ["ft", "ftt"],
"state_fmt": ["%Ga, %Gb", "%Ga, %Gb, %Gc"],
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"state_types": ["ev_invalid", "ev_float"],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
stated_formats = {
"opcode": "OP_STATE_{state[c]}",
"mnemonic": "state.{state[c]}",
"opname": "state",
"format": "{state_fmt[c]}",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "1, 1, {c}",
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
"types": "ev_float, ev_func, {state_types[c]}",
"args": {
"state": ["dt", "dtt"],
"state_fmt": ["%Ga, %Gb", "%Ga, %Gb, %Gc"],
"state_types": ["ev_invalid", "ev_double"],
},
}
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
store_formats = {
"opcode": "OP_STORE_{op_mode[mm]}_{ss+1}",
[gamecode] Correct some ruamoko instruction meta data There were some errors in instruction names and operand types resulting in unsearchable instructions.
2022-01-20 04:02:12 +00:00
"mnemonic": "{store_op[mm]}",
"opname": "{store_op[mm]}",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"format": "%Gc, {store_fmt[mm]}",
[gamecode] Correct the widths for load, store and lea The different addressing modes complicate the width calculations, and lea is particularly fun in that it doesn't care what the width of value is.
2022-01-20 07:33:04 +00:00
"widths": "{store_widths[ss][mm]}, {ss+1}",
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"types": "{store_types[mm]}, ev_void",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"op_mode": address_mode,
"store_fmt": store_fmt,
[gamecode] Correct some ruamoko instruction meta data There were some errors in instruction names and operand types resulting in unsearchable instructions.
2022-01-20 04:02:12 +00:00
"store_op": ["assign", "store", "store", "store"],
[gamecode] Change address mode B to entity.field It turned out that address mode B was redundant as C with 0 offset (immediate) was the same (except for the underlying C code of course, but adding st->b is very cheap). This allowed B to be used for entity.field for all transfer operations. Thus instructions 0-3 are now free as load E became load B, and other than the specifics of format codes for statement printing, transfers+lea are unified.
2022-01-20 05:55:29 +00:00
"store_types": address_types,
[gamecode] Correct the widths for load, store and lea The different addressing modes complicate the width calculations, and lea is particularly fun in that it doesn't care what the width of value is.
2022-01-20 07:33:04 +00:00
"store_widths": address_widths,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
string_formats = {
"opcode": "OP_{op_str[o*4+oo].upper()}_S",
"mnemonic": "{op_str[o*4+oo]}.s",
"opname": "{op_str[o*4+oo]}",
"format": "{str_fmt[o*4+oo]}",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "1, {(o*4+oo)<7 and 1 or 0}, 1",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"types": "{str_types[o*4+oo]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
"op_str": ["eq", "lt", "gt", "add", "cmp", "ge", "le", "not"],
"str_fmt": [
"%Ga, %Gb, %gc",
"%Ga, %Gb, %gc",
"%Ga, %Gb, %gc",
"%Ga, %Gb, %gc",
"%Ga, %Gb, %gc",
"%Ga, %Gb, %gc",
"%Ga, %Gb, %gc",
"%Ga, %gc",
],
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"str_types": [
[gamecode] Rename ev_integer to ev_int And other related fields so integer is now int (and uinteger is uint). I really don't know why I went with integer in the first place, but this will make using macros easier for dealing with types.
2022-01-18 04:21:06 +00:00
"ev_string, ev_string, ev_int",
"ev_string, ev_string, ev_int",
"ev_string, ev_string, ev_int",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"ev_string, ev_string, ev_string",
[gamecode] Rename ev_integer to ev_int And other related fields so integer is now int (and uinteger is uint). I really don't know why I went with integer in the first place, but this will make using macros easier for dealing with types.
2022-01-18 04:21:06 +00:00
"ev_string, ev_string, ev_int",
"ev_string, ev_string, ev_int",
"ev_string, ev_string, ev_int",
"ev_string, ev_invalid, ev_int",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
swizzle_formats = {
"opcode": "OP_SWIZZLE_{swiz_type[t]}",
"mnemonic": "swizzle.{swiz_type[t]}",
"opname": "swizzle",
"format": "%Ga %sb %gc",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "4, 0, 4",
"types": "{swizzle_types[t]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"swiz_type": ['F', 'D'],
"swizzle_types": float_t,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
return_formats = {
[gamecode] Rework call and return instructions The call1-8 instructions have been removed as they are really not needed (they were put in when I had plans of simple translation of v6p progs to ruamoko, but they joined the dinosaurs). The call instruction lost mode A (that is now return) and its mode B is just the regular function access. The important thing is op_c (with support for with-bases) specifies the location of the return def. The return instruction packs both its addressing mode and return value size into st->c as a 3.5 value: 3 bits for the mode (it supports all five addressing modes with entity.field being mode 4) and 5 for the size, limiting return sizes to 32 words, which is enough for one 4x4 double matrix. This, especially with the following convert patch, frees up a lot of instructions.
2022-01-10 02:38:21 +00:00
"opcode": "OP_RETURN",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"mnemonic": "return",
"opname": "return",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "-1, -1, 0", # width specified by st->c
[gamecode] Rework call and return instructions The call1-8 instructions have been removed as they are really not needed (they were put in when I had plans of simple translation of v6p progs to ruamoko, but they joined the dinosaurs). The call instruction lost mode A (that is now return) and its mode B is just the regular function access. The important thing is op_c (with support for with-bases) specifies the location of the return def. The return instruction packs both its addressing mode and return value size into st->c as a 3.5 value: 3 bits for the mode (it supports all five addressing modes with entity.field being mode 4) and 5 for the size, limiting return sizes to 32 words, which is enough for one 4x4 double matrix. This, especially with the following convert patch, frees up a lot of instructions.
2022-01-10 02:38:21 +00:00
"format": "FIXME",
"types": "ev_void, ev_void, ev_void",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
}
vecops_formats = {
"opcode": "OP_{op_vop[ooo].upper()}_{vop_type[t]}",
"mnemonic": "{op_vop[ooo]}.{vop_type[t]}",
"opname": "{op_vop[ooo]}",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "{vec_widths[ooo]}",
"types": "{vec_types[t]}, {vec_types[t]}, {vec_types[t]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Rearrange vector instructions This allows the dot products to be consistent with their sizes: cdot is really dot_2, vdot dot_3, and qdot dot_4.
2022-01-10 02:16:55 +00:00
"op_vop": ["cross", "cdot", "vdot", "qdot",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"cmul", "qvmul", "vqmul", "qmul"],
"vop_type": ['F', 'D'],
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"vec_widths": [
"2, 2, 2",
"3, 3, 3",
"4, 4, 4",
"3, 3, 3",
"2, 2, 2",
"4, 3, 3",
"3, 4, 3",
"4, 4, 4",
],
"vec_types": float_t,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
vecops2_formats = {
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"opcode": "OP_{op_vop[d].upper()}_{vop_type[t]}",
"mnemonic": "{op_vop[d]}.{vop_type[t]}",
"opname": "{op_vop[d]}",
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"widths": "4, 4, 4",
"types": "{vec_types[t]}, {vec_types[t]}, {vec_types[t]}",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"args": {
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"op_vop": ["qv4mul", "v4qmul"],
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"vop_type": ['F', 'D'],
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
"vec_types": float_t,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
},
}
with_formats = {
"opcode": "OP_WITH",
"mnemonic": "with",
"opname": "with",
[gamecode] Fix some more operand formats With and relative branches.
2022-01-06 13:27:09 +00:00
"format": "%sa, %sb, %sc",
[gamecode] Audit the widths of rest of the instructions I can't test them properly until I get qfcc up and running with basic ruamoko code, but they are at least more correct than they were.
2022-01-20 08:27:56 +00:00
"widths": "0, -1, 0",
"types": "ev_short, ev_void, ev_short",
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
}
group_map = {
[gamecode] Add instructions for stack adjust, nop, and ldconst ldconst isn't implemented yet but the plan is to load various constants (eg, 0, 1, 2, pi, e, ...). Stack adjust is useful for adding an offset to the stack pointer without having to worry about finding it (and it checks for alignment). nop is just that :)
2022-01-21 09:44:51 +00:00
"adjstk": adjstk_formats,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"bitops": bitops_formats,
"branch": branch_formats,
[gamecode] Rework call and return instructions The call1-8 instructions have been removed as they are really not needed (they were put in when I had plans of simple translation of v6p progs to ruamoko, but they joined the dinosaurs). The call instruction lost mode A (that is now return) and its mode B is just the regular function access. The important thing is op_c (with support for with-bases) specifies the location of the return def. The return instruction packs both its addressing mode and return value size into st->c as a 3.5 value: 3 bits for the mode (it supports all five addressing modes with entity.field being mode 4) and 5 for the size, limiting return sizes to 32 words, which is enough for one 4x4 double matrix. This, especially with the following convert patch, frees up a lot of instructions.
2022-01-10 02:38:21 +00:00
"call": call_formats,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"compare": compare_formats,
"compare2": compare2_formats,
[gamecode] Add instructions for stack adjust, nop, and ldconst ldconst isn't implemented yet but the plan is to load various constants (eg, 0, 1, 2, pi, e, ...). Stack adjust is useful for adding an offset to the stack pointer without having to worry about finding it (and it checks for alignment). nop is just that :)
2022-01-21 09:44:51 +00:00
"constant": constant_formats,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"convert": convert_formats,
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
"hops": hops_formats,
"jump": jump_formats,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"lea": lea_formats,
"load": load_formats,
"mathops": mathops_formats,
"memset": memset_formats,
"move": move_formats,
[gamecode] Add instructions for stack adjust, nop, and ldconst ldconst isn't implemented yet but the plan is to load various constants (eg, 0, 1, 2, pi, e, ...). Stack adjust is useful for adding an offset to the stack pointer without having to worry about finding it (and it checks for alignment). nop is just that :)
2022-01-21 09:44:51 +00:00
"noop": noop_formats,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"push": push_formats,
"pushregs": pushregs_formats,
"pop": pop_formats,
"popregs": popregs_formats,
"scale": scale_formats,
"shiftops": shiftops_formats,
[gamecode] Add double time state instructions This has been a long-held wishlist item, really, and I thought I might as well take the opportunity to add the instructions. The double versions of STATE require both the nextthink field and time global to be double (but they're not resolved properly yet: marked with "FIXME double time" comments). Also, the frame number for double time state is integer rather than float.
2022-01-16 10:32:47 +00:00
"statef": statef_formats,
"stated": stated_formats,
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
"store": store_formats,
"string": string_formats,
"swizzle": swizzle_formats,
"return": return_formats,
"vecops": vecops_formats,
"vecops2": vecops2_formats,
"with": with_formats,
}
def parse_bits(bit_string):
bits = [""]
isbit = bit_string[0] in ['0', '1']
lastbit = bit_string[0]
while bit_string:
bit = bit_string[0]
bit_string = bit_string[1:]
if isbit and bit in ['0', '1']:
bits[-1] = bits[-1] + bit
elif lastbit == bit:
bits[-1] = bits[-1] + bit
else:
bits.append(bit)
lastbit = bit
isbit = bit in ['0', '1']
return bits
opcodes = [None] * 512
def expand_opcodes(bits, group, num=0):
if not bits:
opcodes[num] = group
return
block = bits[0]
bits = bits[1:]
num <<= len(block)
if block[0] in ['0', '1']:
num |= int(block, 2)
expand_opcodes(bits, group, num)
else:
for n in range(1<<len(block)):
if group is not None:
expand_opcodes(bits, group + f",{block}={n}", num | n)
else:
expand_opcodes(bits, group, num | n)
def process_opcode(opcode, group):
data = group.split(',')
params = {}
for d in data[1:]:
p = d.split('=')
params[p[0]] = int(p[1])
gm = group_map[data[0]]
if "args" in gm:
params.update(gm["args"])
inst = {}
opcodes[opcode] = inst
[gamecode] Rearrange several instructions ANY/ALL/NONE have been temporarily removed until I implement the HOPS (horizontal operations) sub-instructions, which will all both 32-bit and 64-bit operands and several other operations (eg, horizontal add). All the fancy addressing modes for the conditional branch instructions have been permanently removed: I decided the gain was too little for the cost (24 instructions vs 6). JUMP and CALL retain their addressing modes, though. Other instructions have been shuffled around a little to fill most of the holes in the upper block of 256 instructions: just a single small 7-instruction hole. Rearrangements in the actual engine are mostly just to keep the code organized. The only real changes were the various IF statements and dealing with the resulting changes in their addressing.
2022-01-16 05:22:04 +00:00
#print(f"{opcode:03x}", group)
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
inst["op"] = eval(f'''f"{gm['opcode']}"''', params)
mn = eval(f'''f"{gm['mnemonic']}"''', params)
inst["mn"] = f'"{mn}"'
on = eval(f'''f"{gm['opname']}"''', params)
inst["on"] = f'"{on}"'
fmt = "%Ga, %Gb, %gc"
if "format" in gm:
if gm["format"] is not None:
fmt = eval(f'''f"{gm['format']}"''', params)
else:
fmt = None
if fmt is None:
fmt = "0"
else:
fmt = f'"{fmt}"'
inst["fmt"] = fmt
[gamecode] Generate instruction widths and types Not everything is correct, but this is enough to get started on supporting disassembly in the various tools and code generation in qfcc.
2022-01-05 13:33:59 +00:00
inst["wd"] = "{%s}" % eval(f'''f"{gm['widths']}"''', params)
inst["ty"] = "{%s}" % eval(f'''f"{gm['types']}"''', params)
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
[gamecode] Generate the new opcodes enum too It turns out I'll be tweaking it more than I expected.
2022-01-08 16:04:51 +00:00
import sys
if len (sys.argv) < 2 or sys.argv[1] not in ["enum", "table"]:
sys.stderr.write ("specify output type: enum or table\n")
sys.exit(1)
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
lines = bitmap_txt.split('\n')
for l in lines:
[gamecode] Rework call and return instructions The call1-8 instructions have been removed as they are really not needed (they were put in when I had plans of simple translation of v6p progs to ruamoko, but they joined the dinosaurs). The call instruction lost mode A (that is now return) and its mode B is just the regular function access. The important thing is op_c (with support for with-bases) specifies the location of the return def. The return instruction packs both its addressing mode and return value size into st->c as a 3.5 value: 3 bits for the mode (it supports all five addressing modes with entity.field being mode 4) and 5 for the size, limiting return sizes to 32 words, which is enough for one 4x4 double matrix. This, especially with the following convert patch, frees up a lot of instructions.
2022-01-10 02:38:21 +00:00
l = l.strip()
if not l or l[0] == '#':
[gamecode] Generate the new opcode table As I expect to be tweaking things for a while, it's part of the build process. This will make it a lot easier to adjust mnemonics and argument formats (tweaking the old table was a pain when conventions changed). It's not quite done as it still needs arg widths and types.
2022-01-05 10:09:07 +00:00
continue
c = l.split(' ')
bits = "".join(c[0:3])
group = c[3:] and c[3] or None
descr = ' '.join(c[4:])
#print(bits, group, descr)
#print(parse_bits(bits))
expand_opcodes(parse_bits(bits), group)
for i, group in enumerate(opcodes):
if group is not None:
process_opcode (i, group)
[gamecode] Generate the new opcodes enum too It turns out I'll be tweaking it more than I expected.
2022-01-08 16:04:51 +00:00
if sys.argv[1] == "enum":
N = 4
W = 15
for i in range(len(opcodes)//N):
row = opcodes[i * N:i * N + N]
#row = map(lambda op: (op and op["op"] or f"OP_spare_{i}"), row)
row = [(op and op["op"] or f"OP_spare_{i*N+x}")
for x, op in enumerate(row)]
row = map(lambda op: f"%-{W}.{W}s" % (op + ','), row)
if sys.argv[2:3] == ["debug"]:
print("%03x" % (i << 3), " ".join(row))
else:
print(" ".join(row))
elif sys.argv[1] == "table":
for i, group in enumerate(opcodes):
if group is not None:
print(eval('f"[{op}] = {{\\n'
'\\t.opname = {on},\\n'
'\\t.mnemonic = {mn},\\n'
'\\t.widths = {wd},\\n'
'\\t.types = {ty},\\n'
'\\t.fmt = {fmt},\\n'
'}},"', group))