qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-11-10 15:22:04 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/libs/gamecode/Makemodule.am

98 lines
2.9 KiB
Text
Raw Normal View History

[gamecode] Add automated tests for store ops They even found a bug in the addressing mode functions :) (I'd forgotten that I wanted signed offsets from the pointer and thus forgot to cast st->b to short in order to get the sign extension)
2022-01-03 05:41:29 +00:00
include libs/gamecode/test/Makemodule.am
[build] Move to non-recursive make There's still some cleanup to do, but everything seems to be working nicely: `make -j` works, `make distcheck` passes. There is probably plenty of bitrot in the package directories (RPM, debian), though. The vc project files have been removed since those versions are way out of date and quakeforge is pretty much dependent on gcc now anyway. Most of the old Makefile.am files are now Makemodule.am. This should allow for new Makefile.am files that allow local building (to be added on an as-needed bases). The current remaining Makefile.am files are for standalone sub-projects.a The installable bins are currently built in the top-level build directory. This may change if the clutter gets to be too much. While this does make a noticeable difference in build times, the main reason for the switch was to take care of the growing dependency issues: now it's possible to build tools for code generation (eg, using qfcc and ruamoko programs for code-gen).
2020-06-21 14:15:17 +00:00
gc_deps=libs/util/libQFutil.la
noinst_LTLIBRARIES += libs/gamecode/libQFgamecode.la
libs_gamecode_libQFgamecode_la_LDFLAGS=
libs_gamecode_libQFgamecode_la_LIBADD= $(gc_deps)
libs_gamecode_libQFgamecode_la_DEPENDENCIES=$(gc_deps)
libs_gamecode_libQFgamecode_la_SOURCES= \
libs/gamecode/pr_builtins.c \
libs/gamecode/pr_edict.c \
libs/gamecode/pr_debug.c \
libs/gamecode/pr_exec.c \
libs/gamecode/pr_load.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
libs/gamecode/pr_opcode.c \
[build] Move to non-recursive make There's still some cleanup to do, but everything seems to be working nicely: `make -j` works, `make distcheck` passes. There is probably plenty of bitrot in the package directories (RPM, debian), though. The vc project files have been removed since those versions are way out of date and quakeforge is pretty much dependent on gcc now anyway. Most of the old Makefile.am files are now Makemodule.am. This should allow for new Makefile.am files that allow local building (to be added on an as-needed bases). The current remaining Makefile.am files are for standalone sub-projects.a The installable bins are currently built in the top-level build directory. This may change if the clutter gets to be too much. While this does make a noticeable difference in build times, the main reason for the switch was to take care of the growing dependency issues: now it's possible to build tools for code generation (eg, using qfcc and ruamoko programs for code-gen).
2020-06-21 14:15:17 +00:00
libs/gamecode/pr_parse.c \
libs/gamecode/pr_resolve.c \
libs/gamecode/pr_resource.c \
libs/gamecode/pr_strings.c \
[gamecode] Rename pr_opcode.c Just to make way for new tables :)
2022-01-04 11:45:45 +00:00
libs/gamecode/pr_v6p_opcode.c \
[build] Move to non-recursive make There's still some cleanup to do, but everything seems to be working nicely: `make -j` works, `make distcheck` passes. There is probably plenty of bitrot in the package directories (RPM, debian), though. The vc project files have been removed since those versions are way out of date and quakeforge is pretty much dependent on gcc now anyway. Most of the old Makefile.am files are now Makemodule.am. This should allow for new Makefile.am files that allow local building (to be added on an as-needed bases). The current remaining Makefile.am files are for standalone sub-projects.a The installable bins are currently built in the top-level build directory. This may change if the clutter gets to be too much. While this does make a noticeable difference in build times, the main reason for the switch was to take care of the growing dependency issues: now it's possible to build tools for code generation (eg, using qfcc and ruamoko programs for code-gen).
2020-06-21 14:15:17 +00:00
libs/gamecode/pr_zone.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
[gamecode] Add an extend instruction The extend instruction is for loading narrower data types into wider data types, eg, single element into 2, 3, or 4 element types, with a small set of extension schemes: 0, 1, -1, copy (for 1->any and 2 -> 4). Possibly most importantly, it works with unaligned data. Progress towards #30
2022-08-18 05:48:53 +00:00
noinst_PYTHON += \
$(opcodes_py) \
$(convert_py) \
${extend_py} \
$(hops_py) \
$(swizzle_py)
[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
opcodes_py = $(srcdir)/libs/gamecode/opcodes.py
pr_opcode_cinc = $(top_builddir)/libs/gamecode/pr_opcode.cinc
[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
pr_opcode_hinc = $(top_builddir)/include/QF/progs/pr_opcode.hinc
[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
pr_opcode_src = \
[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
${pr_opcode_cinc} \
${pr_opcode_hinc}
[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
libs/gamecode/pr_opcode.lo: libs/gamecode/pr_opcode.c ${pr_opcode_src}
[gamecode] Implement the conversion instructions Not all possibilities are supported because converting between int and uint, and long and ulong is essentially a no-op. However, thanks to Deek's suggestion, not only are all reasonable conversions available, conversions for all widths are available, so vector conversions are supported. The code for the conversions is generated.
2022-01-10 08:01:14 +00:00
convert_py = $(srcdir)/libs/gamecode/convert.py
pr_convert_cinc = $(top_builddir)/libs/gamecode/pr_convert.cinc
[gamecode] Add an extend instruction The extend instruction is for loading narrower data types into wider data types, eg, single element into 2, 3, or 4 element types, with a small set of extension schemes: 0, 1, -1, copy (for 1->any and 2 -> 4). Possibly most importantly, it works with unaligned data. Progress towards #30
2022-08-18 05:48:53 +00:00
extend_py = $(srcdir)/libs/gamecode/extend.py
pr_extend_cinc = $(top_builddir)/libs/gamecode/pr_extend.cinc
[gamecode] Implement the HOPS sub-instructions In the end, I decided any/all/none should be separate from the other horizontal ops, if I even do them (can be implemented by first converting to bool, then using the appropriate horizontal operation (& | etc).
2022-01-16 07:27:33 +00:00
hops_py = $(srcdir)/libs/gamecode/hops.py
pr_hops_cinc = $(top_builddir)/libs/gamecode/pr_hops.cinc
[simd] Use portable swizzles gcc and clang have rather different swizzle builtins, but both do a nice job of optimizing the intuitive initializer swizzle (I think gcc 8(?) didn't do such a good job thus my use of __builtin_shuffle).
2022-03-30 17:25:33 +00:00
swizzle_py = $(srcdir)/libs/gamecode/swizzle.py
pr_swizzle32_cinc = $(top_builddir)/libs/gamecode/pr_swizzle32.cinc
pr_swizzle64_cinc = $(top_builddir)/libs/gamecode/pr_swizzle64.cinc
[gamecode] Implement the HOPS sub-instructions In the end, I decided any/all/none should be separate from the other horizontal ops, if I even do them (can be implemented by first converting to bool, then using the appropriate horizontal operation (& | etc).
2022-01-16 07:27:33 +00:00
BUILT_SOURCES += \
$(pr_opcode_cinc) \
$(pr_opcode_hinc) \
$(pr_convert_cinc) \
[gamecode] Add an extend instruction The extend instruction is for loading narrower data types into wider data types, eg, single element into 2, 3, or 4 element types, with a small set of extension schemes: 0, 1, -1, copy (for 1->any and 2 -> 4). Possibly most importantly, it works with unaligned data. Progress towards #30
2022-08-18 05:48:53 +00:00
$(pr_extend_cinc) \
[simd] Use portable swizzles gcc and clang have rather different swizzle builtins, but both do a nice job of optimizing the intuitive initializer swizzle (I think gcc 8(?) didn't do such a good job thus my use of __builtin_shuffle).
2022-03-30 17:25:33 +00:00
$(pr_hops_cinc) \
$(pr_swizzle32_cinc) \
$(pr_swizzle64_cinc)
[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
Fix some distcheck issues Just keeping up with myself.
2022-03-01 01:12:50 +00:00
CLEANFILES += \
$(pr_opcode_cinc) \
$(pr_opcode_hinc) \
[gamecode] Clean up generated swizzle code
2022-03-31 17:14:05 +00:00
$(pr_convert_cinc) \
[gamecode] Add an extend instruction The extend instruction is for loading narrower data types into wider data types, eg, single element into 2, 3, or 4 element types, with a small set of extension schemes: 0, 1, -1, copy (for 1->any and 2 -> 4). Possibly most importantly, it works with unaligned data. Progress towards #30
2022-08-18 05:48:53 +00:00
$(pr_extend_cinc) \
Fix some distcheck issues Just keeping up with myself.
2022-03-01 01:12:50 +00:00
$(pr_hops_cinc) \
[gamecode] Clean up generated swizzle code
2022-03-31 17:14:05 +00:00
$(pr_swizzle32_cinc) \
$(pr_swizzle64_cinc)
Fix some distcheck issues Just keeping up with myself.
2022-03-01 01:12:50 +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
$(pr_opcode_cinc): $(opcodes_py)
[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
$(V_PY)$(PYTHON) $(opcodes_py) table > $(pr_opcode_cinc).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
$(am__mv) $(pr_opcode_cinc).t $(pr_opcode_cinc)
[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
$(pr_opcode_hinc): $(opcodes_py)
$(V_PY) mkdir -p `dirname $(pr_opcode_hinc)` &&\
$(PYTHON) $(opcodes_py) enum > $(pr_opcode_hinc).t && \
$(am__mv) $(pr_opcode_hinc).t $(pr_opcode_hinc)
[gamecode] Implement the conversion instructions Not all possibilities are supported because converting between int and uint, and long and ulong is essentially a no-op. However, thanks to Deek's suggestion, not only are all reasonable conversions available, conversions for all widths are available, so vector conversions are supported. The code for the conversions is generated.
2022-01-10 08:01:14 +00:00
$(pr_convert_cinc): $(convert_py)
$(V_PY)$(PYTHON) $(convert_py) table > $(pr_convert_cinc).t && \
$(am__mv) $(pr_convert_cinc).t $(pr_convert_cinc)
[gamecode] Implement the HOPS sub-instructions In the end, I decided any/all/none should be separate from the other horizontal ops, if I even do them (can be implemented by first converting to bool, then using the appropriate horizontal operation (& | etc).
2022-01-16 07:27:33 +00:00
[gamecode] Add an extend instruction The extend instruction is for loading narrower data types into wider data types, eg, single element into 2, 3, or 4 element types, with a small set of extension schemes: 0, 1, -1, copy (for 1->any and 2 -> 4). Possibly most importantly, it works with unaligned data. Progress towards #30
2022-08-18 05:48:53 +00:00
$(pr_extend_cinc): $(extend_py)
$(V_PY)$(PYTHON) $(extend_py) table > $(pr_extend_cinc).t && \
$(am__mv) $(pr_extend_cinc).t $(pr_extend_cinc)
[gamecode] Implement the HOPS sub-instructions In the end, I decided any/all/none should be separate from the other horizontal ops, if I even do them (can be implemented by first converting to bool, then using the appropriate horizontal operation (& | etc).
2022-01-16 07:27:33 +00:00
$(pr_hops_cinc): $(hops_py)
$(V_PY)$(PYTHON) $(hops_py) table > $(pr_hops_cinc).t && \
$(am__mv) $(pr_hops_cinc).t $(pr_hops_cinc)
[simd] Use portable swizzles gcc and clang have rather different swizzle builtins, but both do a nice job of optimizing the intuitive initializer swizzle (I think gcc 8(?) didn't do such a good job thus my use of __builtin_shuffle).
2022-03-30 17:25:33 +00:00
$(pr_swizzle32_cinc): $(swizzle_py)
$(V_PY)$(PYTHON) $(swizzle_py) case int > $(pr_swizzle32_cinc).t && \
$(am__mv) $(pr_swizzle32_cinc).t $(pr_swizzle32_cinc)
$(pr_swizzle64_cinc): $(swizzle_py)
$(V_PY)$(PYTHON) $(swizzle_py) case long > $(pr_swizzle64_cinc).t && \
$(am__mv) $(pr_swizzle64_cinc).t $(pr_swizzle64_cinc)
Reference in a new issue Copy permalink