qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-11-27 14:42:07 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/libs/gamecode/pr_exec.c

3556 lines
125 KiB
C
Raw Normal View History

initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
/*
pr_exec.c
(description)
Copyright (C) 1996-1997 Id Software, Inc.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
*/
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
re-arrange things so __attribute__ and __builtin_expect are properly autoconfiscated so rcsid will continue to work with gcc 3.3
2003-01-15 15:31:36 +00:00
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
#ifdef HAVE_STRING_H
# include <string.h>
#endif
#ifdef HAVE_STRINGS_H
# include <strings.h>
#endif
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
#include <signal.h>
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
#include <stdarg.h>
move the api headers into include/QF and clean up (most of) the resulting mess. target specific files that I don't build won't compile yet. just put QF/ infront of the offending headers. Also move ver_check into libqfutils
2001-03-27 20:33:07 +00:00
#include "QF/cvar.h"
fix missed header commit
2002-09-14 07:51:53 +00:00
#include "QF/dstring.h"
LordHavoc's VectorIsNull changes from 0.3 but as VectorIsZero (no such thing as a `null' vector) plus a couple of other bits from his patch.
2001-09-11 05:18:15 +00:00
#include "QF/mathlib.h"
move the api headers into include/QF and clean up (most of) the resulting mess. target specific files that I don't build won't compile yet. just put QF/ infront of the offending headers. Also move ver_check into libqfutils
2001-03-27 20:33:07 +00:00
#include "QF/progs.h"
#include "QF/sys.h"
pr_comp.h: add OP_ADD_S. WARNING!!! this /will/ move. progs.h: add prototype for PR_PrintStatement pr_edict.c: add OP_ADD_S support in the progs checker pr_exec.c: implement OP_ADD_S tools/qfcc/include/.gitignore: add config.h.in qfcc.h: nuke PR_NameImmediate and change PR_ParseImmediate's prototype (see pr_imm.c) pr_comp.c: add ADD_S, adjust for PR_ParseImmediate's prototype, make PR_ParseExpression work with non-sequential opcodes (slow, will work on that next). Fix up initialised global parsing. pr_imm.c: nuke PR_NameImmediate. didn't work well and wasn't such a good idea anyway. PR_ParseImmediate now accepts a def_t * arg. if null, will allocate a new global def, otherwise it will initialize the def passed in. qwaq/main.c: sports some debugging code (dumps info about the progs it's running) qwaq/main.qc: better ADD_S testing
2001-06-03 17:36:49 +00:00
#include "QF/zone.h"
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
#include "QF/simd/vec2d.h"
#include "QF/simd/vec2f.h"
#include "QF/simd/vec2i.h"
#include "QF/simd/vec4d.h"
#include "QF/simd/vec4f.h"
#include "QF/simd/vec4i.h"
pr_comp.h: add OP_ADD_S. WARNING!!! this /will/ move. progs.h: add prototype for PR_PrintStatement pr_edict.c: add OP_ADD_S support in the progs checker pr_exec.c: implement OP_ADD_S tools/qfcc/include/.gitignore: add config.h.in qfcc.h: nuke PR_NameImmediate and change PR_ParseImmediate's prototype (see pr_imm.c) pr_comp.c: add ADD_S, adjust for PR_ParseImmediate's prototype, make PR_ParseExpression work with non-sequential opcodes (slow, will work on that next). Fix up initialised global parsing. pr_imm.c: nuke PR_NameImmediate. didn't work well and wasn't such a good idea anyway. PR_ParseImmediate now accepts a def_t * arg. if null, will allocate a new global def, otherwise it will initialize the def passed in. qwaq/main.c: sports some debugging code (dumps info about the progs it's running) qwaq/main.qc: better ADD_S testing
2001-06-03 17:36:49 +00:00
#include "compat.h"
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
[gamecode] Add debug event name strings Makes it easier to print nice debug event messages.
2022-01-03 05:39:32 +00:00
const char *prdebug_names[] = {
[prd_none] = "none",
[prd_trace] = "trace",
[prd_breakpoint] = "breakpoint",
[prd_watchpoint] = "watchpoint",
[prd_subenter] = "subenter",
[prd_subexit] = "subexit",
[prd_begin] = "begin",
[prd_terminate] = "terminate",
[prd_runerror] = "runerror",
[prd_error] = "error",
};
rhamph's deadbeaf locals patch as-is :)
2001-08-13 20:29:33 +00:00
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
/*
PR_RunError
Aborts the currently executing function
*/
the big dso visibility patch :). Sure, we have to have unique names for static builds, but with controlled visibitly we should get faster program loads (although this isn't C++, so it's not as bad) and complex plugins are cleaner.
2007-03-10 12:00:59 +00:00
VISIBLE void
fear the mighty const correct patch
2001-07-15 07:04:17 +00:00
PR_RunError (progs_t * pr, const char *error, ...)
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
{
[gamecode] Add a param pointer to debug_handler I decided I want events for VM enter/exit but enter needs to somehow pass the function which will be executed (even if a builtin). A generic void * param seemed the best idea, which meant the error string could be passed via the param instead of a "global" string in the progs struct.
2020-03-26 02:44:02 +00:00
dstring_t *string = dstring_new ();//FIXME leaks when debugging
move the debug related stuff from pr_exec.c to pr_debug.c
2002-10-23 20:42:02 +00:00
va_list argptr;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
va_start (argptr, error);
move the debug related stuff from pr_exec.c to pr_debug.c
2002-10-23 20:42:02 +00:00
dvsprintf (string, error, argptr);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
va_end (argptr);
[gamecode] Add debug hooks to the VM engine While there was a breakpoint hook, it was for only breakpoints and more was needed. Now there's a generic hook that is called for tracing, breakpoints, watch points, runtime errors and VM errors, with the "event" type passed as the first parameter and a data pointer in the second.
2020-03-24 06:35:42 +00:00
if (pr->debug_handler) {
[gamecode] Add a param pointer to debug_handler I decided I want events for VM enter/exit but enter needs to somehow pass the function which will be executed (even if a builtin). A generic void * param seemed the best idea, which meant the error string could be passed via the param instead of a "global" string in the progs struct.
2020-03-26 02:44:02 +00:00
pr->debug_handler (prd_runerror, string->str, pr->debug_data);
[gamecode] Add debug hooks to the VM engine While there was a breakpoint hook, it was for only breakpoints and more was needed. Now there's a generic hook that is called for tracing, breakpoints, watch points, runtime errors and VM errors, with the "event" type passed as the first parameter and a data pointer in the second.
2020-03-24 06:35:42 +00:00
// not expected to return, but if so, behave as if there was no handler
}
move the debug related stuff from pr_exec.c to pr_debug.c
2002-10-23 20:42:02 +00:00
Sys_Printf ("%s\n", string->str);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
Print the error message before the state dump. Normally, the order doesn't matter, but when tracing code, it becomes very difficult to tell where the trace ends and the dump begins. Printing the message first puts the message between the trace and the dump: much easier :)
2012-12-16 03:27:15 +00:00
PR_DumpState (pr);
break out the backtrace code from PR_RunError into PR_DumpState and use PR_DumpState instead of PR_RunError in seg_fault_handler so we get both a progs trace /and/ a core file (ulimit allowing)
2001-10-08 03:46:44 +00:00
// dump the stack so PR_Error can shutdown functions
Massive whitespace cleanup. Lots of trailing whitespace and otherwise blank lines.
2012-05-21 23:23:22 +00:00
pr->pr_depth = 0;
Dump locals stack when dumping main stack Any shutdown functions in progs will need locals too.
2020-02-25 06:18:15 +00:00
pr->localstack_used = 0;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
move the debug related stuff from pr_exec.c to pr_debug.c
2002-10-23 20:42:02 +00:00
PR_Error (pr, "Program error: %s", string->str);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
Allow nested use of PR_SaveParams() PR_SaveParams() is required for implementing the +initialize diversion used by Objective-QuakeC because builtins do not have local def spaces (of course, a normal stack calling convention would help). However, it is entirely possible for a call to +initialize to trigger another call to +initialize, thus the need for stacking parameter stashes. As a bonus, this implementation cleans up some fields in progs_t.
2020-02-25 05:30:26 +00:00
VISIBLE pr_stashed_params_t *
_PR_SaveParams (progs_t *pr, pr_stashed_params_t *params)
correctly save and restore the parameters when calling +initialize. fixes the segfault in the qwaq test.
2007-06-09 13:44:06 +00:00
{
int i;
int size = pr->pr_param_size * sizeof (pr_type_t);
Allow nested use of PR_SaveParams() PR_SaveParams() is required for implementing the +initialize diversion used by Objective-QuakeC because builtins do not have local def spaces (of course, a normal stack calling convention would help). However, it is entirely possible for a call to +initialize to trigger another call to +initialize, thus the need for stacking parameter stashes. As a bonus, this implementation cleans up some fields in progs_t.
2020-02-25 05:30:26 +00:00
params->param_ptrs[0] = pr->pr_params[0];
params->param_ptrs[1] = pr->pr_params[1];
correctly save and restore the parameters when calling +initialize. fixes the segfault in the qwaq test.
2007-06-09 13:44:06 +00:00
pr->pr_params[0] = pr->pr_real_params[0];
pr->pr_params[1] = pr->pr_real_params[1];
for (i = 0; i < pr->pr_argc; i++) {
Allow nested use of PR_SaveParams() PR_SaveParams() is required for implementing the +initialize diversion used by Objective-QuakeC because builtins do not have local def spaces (of course, a normal stack calling convention would help). However, it is entirely possible for a call to +initialize to trigger another call to +initialize, thus the need for stacking parameter stashes. As a bonus, this implementation cleans up some fields in progs_t.
2020-02-25 05:30:26 +00:00
memcpy (params->params + i * pr->pr_param_size,
correctly save and restore the parameters when calling +initialize. fixes the segfault in the qwaq test.
2007-06-09 13:44:06 +00:00
pr->pr_real_params[i], size);
Allow nested use of PR_SaveParams() PR_SaveParams() is required for implementing the +initialize diversion used by Objective-QuakeC because builtins do not have local def spaces (of course, a normal stack calling convention would help). However, it is entirely possible for a call to +initialize to trigger another call to +initialize, thus the need for stacking parameter stashes. As a bonus, this implementation cleans up some fields in progs_t.
2020-02-25 05:30:26 +00:00
if (i < 2) { //XXX FIXME what the what?!?
memcpy (pr->pr_real_params[i], params->param_ptrs[0], size);
}
correctly save and restore the parameters when calling +initialize. fixes the segfault in the qwaq test.
2007-06-09 13:44:06 +00:00
}
Allow nested use of PR_SaveParams() PR_SaveParams() is required for implementing the +initialize diversion used by Objective-QuakeC because builtins do not have local def spaces (of course, a normal stack calling convention would help). However, it is entirely possible for a call to +initialize to trigger another call to +initialize, thus the need for stacking parameter stashes. As a bonus, this implementation cleans up some fields in progs_t.
2020-02-25 05:30:26 +00:00
params->argc = pr->pr_argc;
return params;
correctly save and restore the parameters when calling +initialize. fixes the segfault in the qwaq test.
2007-06-09 13:44:06 +00:00
}
VISIBLE void
Allow nested use of PR_SaveParams() PR_SaveParams() is required for implementing the +initialize diversion used by Objective-QuakeC because builtins do not have local def spaces (of course, a normal stack calling convention would help). However, it is entirely possible for a call to +initialize to trigger another call to +initialize, thus the need for stacking parameter stashes. As a bonus, this implementation cleans up some fields in progs_t.
2020-02-25 05:30:26 +00:00
PR_RestoreParams (progs_t *pr, pr_stashed_params_t *params)
correctly save and restore the parameters when calling +initialize. fixes the segfault in the qwaq test.
2007-06-09 13:44:06 +00:00
{
int i;
int size = pr->pr_param_size * sizeof (pr_type_t);
Allow nested use of PR_SaveParams() PR_SaveParams() is required for implementing the +initialize diversion used by Objective-QuakeC because builtins do not have local def spaces (of course, a normal stack calling convention would help). However, it is entirely possible for a call to +initialize to trigger another call to +initialize, thus the need for stacking parameter stashes. As a bonus, this implementation cleans up some fields in progs_t.
2020-02-25 05:30:26 +00:00
pr->pr_params[0] = params->param_ptrs[0];
pr->pr_params[1] = params->param_ptrs[1];
pr->pr_argc = params->argc;
for (i = 0; i < pr->pr_argc; i++) {
correctly save and restore the parameters when calling +initialize. fixes the segfault in the qwaq test.
2007-06-09 13:44:06 +00:00
memcpy (pr->pr_real_params[i],
Allow nested use of PR_SaveParams() PR_SaveParams() is required for implementing the +initialize diversion used by Objective-QuakeC because builtins do not have local def spaces (of course, a normal stack calling convention would help). However, it is entirely possible for a call to +initialize to trigger another call to +initialize, thus the need for stacking parameter stashes. As a bonus, this implementation cleans up some fields in progs_t.
2020-02-25 05:30:26 +00:00
params->params + i * pr->pr_param_size, size);
}
correctly save and restore the parameters when calling +initialize. fixes the segfault in the qwaq test.
2007-06-09 13:44:06 +00:00
}
the big dso visibility patch :). Sure, we have to have unique names for static builds, but with controlled visibitly we should get faster program loads (although this isn't C++, so it's not as bad) and complex plugins are cleaner.
2007-03-10 12:00:59 +00:00
VISIBLE inline void
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
PR_PushFrame (progs_t *pr)
{
prstack_t *frame;
[gamecode] Tweak some docs and macro names And fix an incorrect definition for RETURN_QUAT. Prefixed MAX_STACK_DEPTH and LOCALSTACK_SIZE (and LOCALSTACK_SIZE got an extra _). The rest is just edits to documentation comments.
2022-01-22 01:57:26 +00:00
if (pr->pr_depth == PR_MAX_STACK_DEPTH)
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
PR_RunError (pr, "stack overflow");
frame = pr->pr_stack + pr->pr_depth++;
[gamecode] Rename fields in pr_stack_t s and f are a little too succinct.
2020-04-02 06:00:01 +00:00
frame->staddr = pr->pr_xstatement;
[gamecode] Save and restore data stack in call stack This fixes the issue of the data stack not being restored properly because the returning function needs to return a value from its local variables (stored on the stack) and accessing stack data below the stack pointer is a bad idea (sure, no interrupts yet, but who knows...).
2022-01-17 05:45:14 +00:00
if (pr->globals.stack) {
frame->stack_ptr = *pr->globals.stack;
}
[gamecode] Preserve base registers across calls With this, functions can call other functions without having to worry about whether the base registers they set up are still valid.
2022-01-17 06:08:58 +00:00
frame->bases = pr->pr_bases;
[gamecode] Rename fields in pr_stack_t s and f are a little too succinct.
2020-04-02 06:00:01 +00:00
frame->func = pr->pr_xfunction;
frame->tstr = pr->pr_xtstr;
[gamecode] Preserve the return pointer across calls This required delaying the setting of the return pointer by call until after the current pointer had been saved, and thus passing the desired pointer into PR_CallFunction (which does have some advantages for C functions calling progs functions, but some dangers too (should ensure a 128 byte (32 word) buffer when calling untrusted code (which is any, really)).
2022-01-17 10:12:28 +00:00
frame->return_ptr = pr->pr_return;
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
[gamecode] Add function PR_PushTempString This "pushes" a temp string onto the callee's stack frame after removing it from the caller's stack frame. This is so builtins can pass auto-freed memory to called progs code. No checking is done, but mayhem is likely to ensue if a string is pushed that was allocated in an earlier frame.
2020-03-09 14:36:09 +00:00
pr->pr_xtstr = pr->pr_pushtstr;
pr->pr_pushtstr = 0;
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
pr->pr_xfunction = 0;
}
the big dso visibility patch :). Sure, we have to have unique names for static builds, but with controlled visibitly we should get faster program loads (although this isn't C++, so it's not as bad) and complex plugins are cleaner.
2007-03-10 12:00:59 +00:00
VISIBLE inline void
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
PR_PopFrame (progs_t *pr)
{
prstack_t *frame;
if (pr->pr_depth <= 0)
PR_Error (pr, "prog stack underflow");
if (pr->pr_xtstr)
PR_FreeTempStrings (pr);
[gamecode] Add function PR_PushTempString This "pushes" a temp string onto the callee's stack frame after removing it from the caller's stack frame. This is so builtins can pass auto-freed memory to called progs code. No checking is done, but mayhem is likely to ensue if a string is pushed that was allocated in an earlier frame.
2020-03-09 14:36:09 +00:00
// normally, this won't happen, but if a builtin pushed a temp string
// when calling a function and the callee was another builtin that
// did not call a progs function, then the push strings will still be
// valid because PR_EnterFunction was never called
[gamecode] Be more careful with temp strings If a temp string is found in the return slot, PR_FreeTempStrings won't delete the string. However, PR_PopFrame was blindly stomping on the possibly surviving temp string with the push strings, which would cause a leak.
2020-03-09 18:24:31 +00:00
// however, not if a temp string survived: better to hold on to the push
// strings a little longer than lose one erroneously
if (!pr->pr_xtstr && pr->pr_pushtstr) {
[gamecode] Add function PR_PushTempString This "pushes" a temp string onto the callee's stack frame after removing it from the caller's stack frame. This is so builtins can pass auto-freed memory to called progs code. No checking is done, but mayhem is likely to ensue if a string is pushed that was allocated in an earlier frame.
2020-03-09 14:36:09 +00:00
pr->pr_xtstr = pr->pr_pushtstr;
pr->pr_pushtstr = 0;
PR_FreeTempStrings (pr);
}
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
// up stack
frame = pr->pr_stack + --pr->pr_depth;
[gamecode] Preserve the return pointer across calls This required delaying the setting of the return pointer by call until after the current pointer had been saved, and thus passing the desired pointer into PR_CallFunction (which does have some advantages for C functions calling progs functions, but some dangers too (should ensure a 128 byte (32 word) buffer when calling untrusted code (which is any, really)).
2022-01-17 10:12:28 +00:00
pr->pr_return = frame->return_ptr;
[gamecode] Rename fields in pr_stack_t s and f are a little too succinct.
2020-04-02 06:00:01 +00:00
pr->pr_xfunction = frame->func;
pr->pr_xstatement = frame->staddr;
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
pr->pr_xtstr = frame->tstr;
[gamecode] Preserve base registers across calls With this, functions can call other functions without having to worry about whether the base registers they set up are still valid.
2022-01-17 06:08:58 +00:00
pr->pr_bases = frame->bases;
[gamecode] Save and restore data stack in call stack This fixes the issue of the data stack not being restored properly because the returning function needs to return a value from its local variables (stored on the stack) and accessing stack data below the stack pointer is a bad idea (sure, no interrupts yet, but who knows...).
2022-01-17 05:45:14 +00:00
// restore data stack (discard any locals)
if (pr->globals.stack) {
*pr->globals.stack = frame->stack_ptr;
}
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
}
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
static __attribute__((pure)) long
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
align_offset (long offset, dparmsize_t paramsize)
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
{
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
int mask = (1 << paramsize.alignment) - 1;
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
return (offset + mask) & ~mask;
}
static void
copy_param (pr_type_t *dst, pr_type_t *src, size_t size)
{
while (size--) {
memcpy (dst++, src++, sizeof (pr_type_t));
}
}
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
/** Setup the stackframe prior to calling a progs function. Saves all local
data the called function will trample on and copies the parameters used
by the function into the function's local data space.
\param pr pointer to progs_t VM struct
\param f pointer to the descriptor for the called function
\note Passing a descriptor for a builtin function will result in
undefined behavior.
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
*/
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
static void
Fix the access alignment bug on 64 bit archs.
2007-04-07 01:41:23 +00:00
PR_EnterFunction (progs_t *pr, bfunction_t *f)
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
{
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
pr_int_t i;
[gamecode] Rename MAX_PARMS to PR_MAXPARAMS
2022-01-23 05:17:25 +00:00
pr_type_t *dstParams[PR_MAX_PARAMS];
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t paramofs = 0;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
[gamecode] Hide trace messages when debugger is attached
2020-03-31 15:09:34 +00:00
if (pr->pr_trace && !pr->debug_handler) {
[gamecode] Be more informative with function calls PR_EnterFunction and PR_LeaveFunction now print the entered/left/returned function when tracing. Makes debugging obj code much easier.
2020-03-24 04:24:55 +00:00
Sys_Printf ("Entering function %s\n",
[gamecode] Remove the wart from def and function names I never liked the leading s_ (though I guess it means one is supposed to interpret the int as a string pointer, but meh).
2021-12-31 06:02:31 +00:00
PR_GetString (pr, f->descriptor->name));
[gamecode] Be more informative with function calls PR_EnterFunction and PR_LeaveFunction now print the entered/left/returned function when tracing. Makes debugging obj code much easier.
2020-03-24 04:24:55 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
PR_PushFrame (pr);
[gamecode] Return early if the entered function has no locals As even the simplest v6p functions that take parameters but have no local or temporary variables still have locals for the local copy of the parameters, this is a both a good check for for the Ruamoko ISA as its functions never have locals (everything's on the progs data stack), and an optimization for v6p functions that have no params or locals (simple getters (very rare?), most .ctor, etc).
2022-01-22 12:41:35 +00:00
//Sys_Printf("%s:\n", PR_GetString(pr,f->name));
pr->pr_xfunction = f;
pr->pr_xstatement = f->first_statement - 1; // offset the st++
[gamecode] Use version instead of locals count It turned out I need locals count and params_start for debugging, so use the progs version instead to bail early from PR_EnterFunction and PR_LeaveFunction (which I had forgotten anyway, oops).
2022-01-27 02:24:00 +00:00
if (pr->progs->version == PROG_VERSION) {
[gamecode] Return early if the entered function has no locals As even the simplest v6p functions that take parameters but have no local or temporary variables still have locals for the local copy of the parameters, this is a both a good check for for the Ruamoko ISA as its functions never have locals (everything's on the progs data stack), and an optimization for v6p functions that have no params or locals (simple getters (very rare?), most .ctor, etc).
2022-01-22 12:41:35 +00:00
return;
}
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
if (f->numparams > 0) {
paramofs = f->params_start;
for (i = 0; i < f->numparams; i++) {
paramofs = align_offset (paramofs, f->param_size[i]);
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
dstParams[i] = pr->pr_globals + paramofs;
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
paramofs += f->param_size[i].size;
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
if (pr->pr_params[i] != pr->pr_real_params[i]) {
copy_param (pr->pr_real_params[i], pr->pr_params[i],
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
f->param_size[i].size);
[gamecode] Replace lost parameter auto-reset rcallN messes with the progs parameter pointers and not resetting them can cause incorrect data to be copied into the called function.
2020-03-11 10:38:50 +00:00
pr->pr_params[i] = pr->pr_real_params[i];
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
}
heh, slight oversight when implementing rcall using the param pointer trick. ran into the exact same problem as passing addresses of locals to QC functions. well, actually, that's exactly what it was, but done in the engine. anyway, wound up potentially overwriting the params passed to the function. fortunatly, due to how rcall works, only the first two params are an issue.
2005-06-14 13:40:34 +00:00
}
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
} else if (f->numparams < 0) {
paramofs = f->params_start + 2; // argc and argv
for (i = 0; i < -f->numparams - 1; i++) {
paramofs = align_offset (paramofs, f->param_size[i]);
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
dstParams[i] = pr->pr_globals + paramofs;
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
paramofs += f->param_size[i].size;
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
if (pr->pr_params[i] != pr->pr_real_params[i]) {
copy_param (pr->pr_real_params[i], pr->pr_params[i],
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
f->param_size[i].size);
[gamecode] Replace lost parameter auto-reset rcallN messes with the progs parameter pointers and not resetting them can cause incorrect data to be copied into the called function.
2020-03-11 10:38:50 +00:00
pr->pr_params[i] = pr->pr_real_params[i];
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
}
heh, slight oversight when implementing rcall using the param pointer trick. ran into the exact same problem as passing addresses of locals to QC functions. well, actually, that's exactly what it was, but done in the engine. anyway, wound up potentially overwriting the params passed to the function. fortunatly, due to how rcall works, only the first two params are an issue.
2005-06-14 13:40:34 +00:00
}
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
dparmsize_t paramsize = { pr->pr_param_size, pr->pr_param_alignment };
paramofs = align_offset (paramofs, paramsize );
[gamecode] Rename MAX_PARMS to PR_MAXPARAMS
2022-01-23 05:17:25 +00:00
if (i < PR_MAX_PARAMS) {
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
dstParams[i] = pr->pr_globals + paramofs;
heh, slight oversight when implementing rcall using the param pointer trick. ran into the exact same problem as passing addresses of locals to QC functions. well, actually, that's exactly what it was, but done in the engine. anyway, wound up potentially overwriting the params passed to the function. fortunatly, due to how rcall works, only the first two params are an issue.
2005-06-14 13:40:34 +00:00
}
Copy only the necessary number of vararg parameters
2020-02-16 09:00:29 +00:00
for (; i < pr->pr_argc; i++) {
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
if (pr->pr_params[i] != pr->pr_real_params[i]) {
copy_param (pr->pr_real_params[i], pr->pr_params[i],
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
paramsize.size);
[gamecode] Replace lost parameter auto-reset rcallN messes with the progs parameter pointers and not resetting them can cause incorrect data to be copied into the called function.
2020-03-11 10:38:50 +00:00
pr->pr_params[i] = pr->pr_real_params[i];
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
}
heh, slight oversight when implementing rcall using the param pointer trick. ran into the exact same problem as passing addresses of locals to QC functions. well, actually, that's exactly what it was, but done in the engine. anyway, wound up potentially overwriting the params passed to the function. fortunatly, due to how rcall works, only the first two params are an issue.
2005-06-14 13:40:34 +00:00
}
}
use memcpy instead of ugly casts to transfer locals
2001-06-05 23:57:51 +00:00
// save off any locals that the new function steps on
[gamecode] Tweak some docs and macro names And fix an incorrect definition for RETURN_QUAT. Prefixed MAX_STACK_DEPTH and LOCALSTACK_SIZE (and LOCALSTACK_SIZE got an extra _). The rest is just edits to documentation comments.
2022-01-22 01:57:26 +00:00
if (pr->localstack_used + f->locals > PR_LOCAL_STACK_SIZE)
correct the function names in PR_EnterFunction and PR_LeaveFunction
2002-05-21 21:14:32 +00:00
PR_RunError (pr, "PR_EnterFunction: locals stack overflow");
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
use memcpy instead of ugly casts to transfer locals
2001-06-05 23:57:51 +00:00
memcpy (&pr->localstack[pr->localstack_used],
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
&pr->pr_globals[f->params_start],
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
sizeof (pr_type_t) * f->locals);
pr->localstack_used += f->locals;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
[gamecode] Rearrange bfunction_t in preparation for param offsets The builtin and progs function data is overlaid so the extra data doesn't cause too much memory to be used (it's actually 8 bytes smaller now). The plan is to pre-compute the offsets based on the parameter size and alignment data.
2022-01-23 15:13:44 +00:00
if (pr_deadbeef_locals->int_val) {
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
for (pr_uint_t i = f->params_start;
i < f->params_start + f->locals; i++) {
[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
pr->pr_globals[i].int_var = 0xdeadbeef;
[gamecode] Rearrange bfunction_t in preparation for param offsets The builtin and progs function data is overlaid so the extra data doesn't cause too much memory to be used (it's actually 8 bytes smaller now). The plan is to pre-compute the offsets based on the parameter size and alignment data.
2022-01-23 15:13:44 +00:00
}
}
rhamph's deadbeaf locals patch as-is :)
2001-08-13 20:29:33 +00:00
Whitespace.
2001-09-10 12:56:23 +00:00
// copy parameters
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
if (f->numparams >= 0) {
for (i = 0; i < f->numparams; i++) {
copy_param (dstParams[i], pr->pr_params[i], f->param_size[i].size);
vararg functions can now be imlemented in qc using @argc (number of params passed through ...) and @argv (array of vectors, one for each ... param)
2002-05-22 20:43:29 +00:00
}
} else {
Copy only the necessary number of vararg parameters
2020-02-16 09:00:29 +00:00
int copy_args;
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
pr_type_t *argc = &pr->pr_globals[f->params_start + 0];
pr_type_t *argv = &pr->pr_globals[f->params_start + 1];
for (i = 0; i < -f->numparams - 1; i++) {
copy_param (dstParams[i], pr->pr_params[i], f->param_size[i].size);
vararg functions can now be imlemented in qc using @argc (number of params passed through ...) and @argv (array of vectors, one for each ... param)
2002-05-22 20:43:29 +00:00
}
Copy only the necessary number of vararg parameters
2020-02-16 09:00:29 +00:00
copy_args = pr->pr_argc - i;
[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
argc->int_var = copy_args;
argv->int_var = dstParams[i] - pr->pr_globals;
[gamecode] Rename MAX_PARMS to PR_MAXPARAMS
2022-01-23 05:17:25 +00:00
if (i < PR_MAX_PARAMS) {
Copy only the necessary number of vararg parameters
2020-02-16 09:00:29 +00:00
memcpy (dstParams[i], pr->pr_params[i],
(copy_args * pr->pr_param_size) * sizeof (pr_type_t));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
}
}
make gcc more anal about prototypes, string constants and function visibility (ie, global functions must have a prototype)
2003-01-06 18:28:13 +00:00
static void
[gamecode] Be more informative with function calls PR_EnterFunction and PR_LeaveFunction now print the entered/left/returned function when tracing. Makes debugging obj code much easier.
2020-03-24 04:24:55 +00:00
PR_LeaveFunction (progs_t *pr, int to_engine)
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
{
Fix the access alignment bug on 64 bit archs.
2007-04-07 01:41:23 +00:00
bfunction_t *f = pr->pr_xfunction;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
add PR_PushFrame and PR_PopFrame so temp strings are easy to use for parameters to progs functions. double the progs stack sizes (call depth of 32? eek) allow one extra call on the progs stack :) misc minor cleanups
2004-01-05 07:10:32 +00:00
PR_PopFrame (pr);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
[gamecode] Hide trace messages when debugger is attached
2020-03-31 15:09:34 +00:00
if (pr->pr_trace && !pr->debug_handler) {
[gamecode] Be more informative with function calls PR_EnterFunction and PR_LeaveFunction now print the entered/left/returned function when tracing. Makes debugging obj code much easier.
2020-03-24 04:24:55 +00:00
Sys_Printf ("Leaving function %s\n",
[gamecode] Remove the wart from def and function names I never liked the leading s_ (though I guess it means one is supposed to interpret the int as a string pointer, but meh).
2021-12-31 06:02:31 +00:00
PR_GetString (pr, f->descriptor->name));
[gamecode] Be more informative with function calls PR_EnterFunction and PR_LeaveFunction now print the entered/left/returned function when tracing. Makes debugging obj code much easier.
2020-03-24 04:24:55 +00:00
if (to_engine) {
Sys_Printf ("Returning to engine\n");
} else {
bfunction_t *rf = pr->pr_xfunction;
[gamecode] Fix some silly errors I forgot to compile-test :(
2020-03-24 14:16:25 +00:00
if (rf) {
Sys_Printf ("Returning to function %s\n",
[gamecode] Remove the wart from def and function names I never liked the leading s_ (though I guess it means one is supposed to interpret the int as a string pointer, but meh).
2021-12-31 06:02:31 +00:00
PR_GetString (pr, rf->descriptor->name));
[gamecode] Fix some silly errors I forgot to compile-test :(
2020-03-24 14:16:25 +00:00
}
[gamecode] Be more informative with function calls PR_EnterFunction and PR_LeaveFunction now print the entered/left/returned function when tracing. Makes debugging obj code much easier.
2020-03-24 04:24:55 +00:00
}
}
[gamecode] Use version instead of locals count It turned out I need locals count and params_start for debugging, so use the progs version instead to bail early from PR_EnterFunction and PR_LeaveFunction (which I had forgotten anyway, oops).
2022-01-27 02:24:00 +00:00
if (pr->progs->version == PROG_VERSION) {
return;
}
Whitespace.
2001-09-10 12:56:23 +00:00
// restore locals from the stack
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
pr->localstack_used -= f->locals;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
if (pr->localstack_used < 0)
correct the function names in PR_EnterFunction and PR_LeaveFunction
2002-05-21 21:14:32 +00:00
PR_RunError (pr, "PR_LeaveFunction: locals stack underflow");
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
[gamecode] Rename parm to param That misspelling bothered me from the very beginning, I'd always have trouble getting the name right when trying to access one of those fields.
2022-01-27 01:55:06 +00:00
memcpy (&pr->pr_globals[f->params_start],
Implement parameter alignment in the engine The engine now requires non-v6 progs to store the log2 alignment for the param struct in .param_alignment. PR_EnterFunction is clearer and possibly more efficient.
2020-02-16 08:13:45 +00:00
&pr->localstack[pr->localstack_used],
sizeof (pr_type_t) * f->locals);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
Really nail down the args param in rua_obj_msg_sendv().
2010-01-13 06:36:16 +00:00
VISIBLE void
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
PR_BoundsCheckSize (progs_t *pr, pr_ptr_t addr, unsigned size)
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
{
[gamecode] Use an explicit size for the null page It's currently only 4 (or even 3 for v6) words, but this fixes false positives when checking for null pointers in Ruamoko progs due to pr_return pointing to the return buffer and thus outside the progs memory map resulting in an impossible to exceed value.
2022-02-01 07:43:29 +00:00
if (addr < pr->null_size)
Check for null VM pointer accesses. Currently only four words of "null pointer protection" are available, but it's a start.
2012-12-22 05:24:11 +00:00
PR_RunError (pr, "null pointer access");
Change pointer_t to unsigned and clean up the mess. It doesn't make sense to have negative pointers. The size of the commit is from enabling gcc's -Wtype-limits warning and cleaning up that mess too.
2012-12-21 12:53:13 +00:00
if (addr >= pr->globals_size
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
|| size > (unsigned) (pr->globals_size - addr))
PR_RunError (pr, "invalid memory access: %d (0 to %d-%d)", addr,
pr->globals_size, size);
Add improved memory checking to progs. With pr_boundscheck >= 2, pointer access will be checked against allocated blocks (qfvalgrind?:). Currently extremely basic, but it seems to work.
2012-11-19 11:03:21 +00:00
if (pr_boundscheck->int_val >= 2
&& PR_GetPointer (pr, addr + size) > (pr_type_t *) pr->zone) {
void *mem = (void *) PR_GetPointer (pr, addr);
Z_CheckPointer (pr->zone, mem, size * sizeof (pr_type_t));
}
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
Really nail down the args param in rua_obj_msg_sendv().
2010-01-13 06:36:16 +00:00
VISIBLE void
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
PR_BoundsCheck (progs_t *pr, int addr, etype_t type)
{
PR_BoundsCheckSize (pr, addr, pr_type_size[type]);
}
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
#define OPA(type) (*((pr_##type##_t *) (op_a)))
#define OPB(type) (*((pr_##type##_t *) (op_b)))
#define OPC(type) (*((pr_##type##_t *) (op_c)))
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
make float != 0 tests work on alpha for when the value is actually an integer (works fine on intel, but on alpha the denormals either produce an exception or true zero: not quite desirable:)
2001-11-19 17:51:31 +00:00
/*
This gets around the problem of needing to test for -0.0 but denormals
causing exceptions (or wrong results for what we need) on the alpha.
*/
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
#define FNZ(x) ((x) & ~0x80000000u)
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
static int
signal_hook (int sig, void *data)
{
progs_t *pr = (progs_t *) data;
Massive whitespace cleanup. Lots of trailing whitespace and otherwise blank lines.
2012-05-21 23:23:22 +00:00
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
if (sig == SIGFPE && pr_faultchecks->int_val) {
dstatement_t *st;
pr_type_t *op_a, *op_b, *op_c;
st = pr->pr_statements + pr->pr_xstatement;
op_a = pr->pr_globals + st->a;
op_b = pr->pr_globals + st->b;
op_c = pr->pr_globals + st->c;
switch (st->op) {
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_DIV_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
if ((OPA(int) & 0x80000000)
^ (OPB(int) & 0x80000000))
OPC(int) = 0xff7fffff;
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
else
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = 0x7f7fffff;
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
return 1;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_DIV_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
if (OPA(int) & 0x80000000)
OPC(int) = -0x80000000;
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
else
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = 0x7fffffff;
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
return 1;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MOD_I_v6p:
case OP_MOD_F_v6p:
case OP_REM_I_v6p:
case OP_REM_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = 0x00000000;
handle x % 0 by giving a 0 result
2004-02-20 00:25:08 +00:00
return 1;
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
default:
break;
}
}
PR_DumpState (pr);
Ensure stdout is flushed in the progs signal_hook()
2011-03-20 04:34:28 +00:00
fflush (stdout);
sys.[ch]: handle SIGFPE and allow the registered signal handler to do recovery rather than bail progs.h, pr_exec.c, pr_load.c: if pr_faultchecks is 1 (0 is default), handle division by 0 gracefully by loading the maximum representable number into the answer Closes: #58 the rest: kill the SIGFPE stuff
2002-11-13 19:26:44 +00:00
return 0;
}
Allow Sys_Error to be hooked. This makes debugging builtins that wrap normal functions a little easier by giving a progs dump when such an error occurs.
2016-01-03 14:04:00 +00:00
static void
error_handler (void *data)
{
progs_t *pr = (progs_t *) data;
PR_DumpState (pr);
fflush (stdout);
}
the big dso visibility patch :). Sure, we have to have unique names for static builds, but with controlled visibitly we should get faster program loads (although this isn't C++, so it's not as bad) and complex plugins are cleaner.
2007-03-10 12:00:59 +00:00
VISIBLE int
[gamecode] Rename func_t to pr_func_t Even more consistency.
2022-01-18 06:32:43 +00:00
PR_CallFunction (progs_t *pr, pr_func_t fnum, pr_type_t *return_ptr)
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
{
Fix the access alignment bug on 64 bit archs.
2007-04-07 01:41:23 +00:00
bfunction_t *f;
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
if (!fnum)
PR_RunError (pr, "NULL function");
[gamecode] Use a buffer for discarded return values Due to how OP_RETURN works, a destination is required for any function returning data, but the caller may not have allocated any space for the value. Thus the VM maintains a buffer into which the data can be put and ignored. It also makes a good place for return values when the engine calls Ruamoko code as trusting progs code with return sizes seems like a recipe for disaster, especially if the return location is on the C stack.
2022-01-21 01:09:02 +00:00
if (!return_ptr || return_ptr == pr->pr_globals) {
return_ptr = pr->pr_return_buffer;
}
Fix the access alignment bug on 64 bit archs.
2007-04-07 01:41:23 +00:00
f = pr->function_table + fnum;
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
if (f->first_statement < 0) {
// negative statements are built in functions
[gamecode] Use PR_SetupParameters for rua called builtins It's a bit heavy-handed as it sets all the param pointers, but simple (no varargs) functions are working nicely in Ruamoko.
2022-01-24 07:46:49 +00:00
if (pr->progs->version == PROG_VERSION) {
PR_SetupParams (pr, 0, 0);
}
[gamecode] Hide trace messages when debugger is attached
2020-03-31 15:09:34 +00:00
if (pr->pr_trace && !pr->debug_handler) {
Indicate calls to builtins when tracing. This makes following progs traces a little easier.
2016-01-03 07:13:59 +00:00
Sys_Printf ("Calling builtin %s @ %p\n",
[gamecode] Remove the wart from def and function names I never liked the leading s_ (though I guess it means one is supposed to interpret the int as a string pointer, but meh).
2021-12-31 06:02:31 +00:00
PR_GetString (pr, f->descriptor->name), f->func);
Indicate calls to builtins when tracing. This makes following progs traces a little easier.
2016-01-03 07:13:59 +00:00
}
[gamecode] Preserve the return pointer across calls This required delaying the setting of the return pointer by call until after the current pointer had been saved, and thus passing the desired pointer into PR_CallFunction (which does have some advantages for C functions calling progs functions, but some dangers too (should ensure a 128 byte (32 word) buffer when calling untrusted code (which is any, really)).
2022-01-17 10:12:28 +00:00
pr_type_t *saved_return = pr->pr_return;
[gamecode] Skip return ptr restore if depth changed When calling a builtin, normally the return pointer needs to be restored, but if the builtin changes the call depth (usually by effecting "return foo()" as in support for objects, but possibly setjmp/longjmp when they are implemented), then the return pointer must not be restored. This gets vkgen past object allocation, but it dies when trying to send messages to super. This appears to be a compiler bug.
2022-01-31 07:51:46 +00:00
int builtin_depth = pr->pr_depth;
[gamecode] Preserve the return pointer across calls This required delaying the setting of the return pointer by call until after the current pointer had been saved, and thus passing the desired pointer into PR_CallFunction (which does have some advantages for C functions calling progs functions, but some dangers too (should ensure a 128 byte (32 word) buffer when calling untrusted code (which is any, really)).
2022-01-17 10:12:28 +00:00
pr->pr_return = return_ptr;
[gamecode] Pass registered data pointer to builtins This is the bulk of the work for recording the resource pointer with with builtin data. I don't know how much of a difference it makes for most things, but it's probably pretty big for qwaq-curses due to the very high number of calls to the curses builtins. Closes #26
2022-02-14 03:28:38 +00:00
f->func (pr, f->data);
[gamecode] Count calls to builtins in profile It's a bit disconcerting seeing a builtin in the top 10 when builtins are counted by call while progs functions are counted by instruction. Also, show the total profile after the function top-10 list.
2022-02-04 12:49:59 +00:00
f->profile++; // to show number times the builtin is called
[gamecode] Skip return ptr restore if depth changed When calling a builtin, normally the return pointer needs to be restored, but if the builtin changes the call depth (usually by effecting "return foo()" as in support for objects, but possibly setjmp/longjmp when they are implemented), then the return pointer must not be restored. This gets vkgen past object allocation, but it dies when trying to send messages to super. This appears to be a compiler bug.
2022-01-31 07:51:46 +00:00
if (builtin_depth == pr->pr_depth) {
pr->pr_return = saved_return;
[gamecode] Save return ptr for chained calls It turns out the return pointer still needs to be saved even when a builtin sets up a chain call to progs, but rather than the pointer being simply restored, it needs to be saved in the call stack exactly as if the function was called directly by progs. This fixes the invalid self issue quite thoroughly: parameter state seems to be correct across all calls now. I should set up an automated test now that I know and understand the situation.
2022-01-31 14:32:38 +00:00
} else if (builtin_depth < pr->pr_depth) {
pr->pr_stack[builtin_depth].return_ptr = saved_return;
[gamecode] Skip return ptr restore if depth changed When calling a builtin, normally the return pointer needs to be restored, but if the builtin changes the call depth (usually by effecting "return foo()" as in support for objects, but possibly setjmp/longjmp when they are implemented), then the return pointer must not be restored. This gets vkgen past object allocation, but it dies when trying to send messages to super. This appears to be a compiler bug.
2022-01-31 07:51:46 +00:00
}
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
return 0;
} else {
PR_EnterFunction (pr, f);
[gamecode] Preserve the return pointer across calls This required delaying the setting of the return pointer by call until after the current pointer had been saved, and thus passing the desired pointer into PR_CallFunction (which does have some advantages for C functions calling progs functions, but some dangers too (should ensure a 128 byte (32 word) buffer when calling untrusted code (which is any, really)).
2022-01-17 10:12:28 +00:00
pr->pr_return = return_ptr;
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
return 1;
}
}
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
static void
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
check_stack_pointer (progs_t *pr, pr_ptr_t stack, int size)
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Rework PR_RESET_PARAMS to use PR_SetupParams PR_SetupParams is new and sets up the parameter pointers so older code that expects only up to 8 parameter will work with both v6p and Ruamoko progs without having to check what progs are running. PR_SetupParams is useful even when Ruamoko progs are expected as it reserves the required space (respecting alignment) on the stack and returns a pointer to the top (bottom? confusing) of the stack. PR_PushFrame and PR_PopFrame need to be used around PR_SetupParams, regardless of using temp strings, to avoid a stack leak (need to do an audit).
2022-01-24 03:50:15 +00:00
if (stack & 3) {
PR_RunError (pr, "Progs stack not aligned");
}
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
if (stack < pr->stack_bottom) {
PR_RunError (pr, "Progs stack overflow");
}
if (stack > pr->globals_size - size) {
PR_RunError (pr, "Progs stack underflow");
}
}
[gamecode] Rework PR_RESET_PARAMS to use PR_SetupParams PR_SetupParams is new and sets up the parameter pointers so older code that expects only up to 8 parameter will work with both v6p and Ruamoko progs without having to check what progs are running. PR_SetupParams is useful even when Ruamoko progs are expected as it reserves the required space (respecting alignment) on the stack and returns a pointer to the top (bottom? confusing) of the stack. PR_PushFrame and PR_PopFrame need to be used around PR_SetupParams, regardless of using temp strings, to avoid a stack leak (need to do an audit).
2022-01-24 03:50:15 +00:00
VISIBLE pr_type_t *
PR_SetupParams (progs_t *pr, int num_params, int min_alignment)
{
if (pr->progs->version < PROG_VERSION) {
if (num_params > PR_MAX_PARAMS) {
PR_Error (pr, "attempt to settup more than %d params",
PR_MAX_PARAMS);
}
pr->pr_params[0] = pr->pr_real_params[0];
pr->pr_params[1] = pr->pr_real_params[1];
return pr->pr_real_params[0];
}
int offset = num_params * 4;
if (min_alignment < 4) {
min_alignment = 4;
}
pr_ptr_t mask = ~(min_alignment - 1);
pr_ptr_t stack = (*pr->globals.stack - offset) & mask;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 0);
}
*pr->globals.stack = stack;
pr->pr_params[0] = pr->pr_globals + stack;
[qfcc] Build the Ruamoko function parameters The parameter defs are allocated from the parameter space using a minimum alignment of 4, and varargs functions get a va_list struct in place of the ... An "args" expression is unconditionally injected into the call arguments list at the place where ... is in the list, with arguments passed through ... coming after the ... Arguments get through to functions now, but there's problems with taking the address of local variables: currently done using constant pointer defs, which can't work for the base register addressing used in Ruamoko progs. With the update to test-bi's printf (and a hack to qfcc for lea), triangle.r actually works, printing the expected results (but -1 instead of 1 for equality, though that too is actually expected). qfcc will take a bit longer because it seems there are some design issues in address expressions (ambiguity, and a few other things) that have pretty much always been there.
2022-01-24 09:35:16 +00:00
num_params = max (num_params, PR_MAX_PARAMS);
[gamecode] Rework PR_RESET_PARAMS to use PR_SetupParams PR_SetupParams is new and sets up the parameter pointers so older code that expects only up to 8 parameter will work with both v6p and Ruamoko progs without having to check what progs are running. PR_SetupParams is useful even when Ruamoko progs are expected as it reserves the required space (respecting alignment) on the stack and returns a pointer to the top (bottom? confusing) of the stack. PR_PushFrame and PR_PopFrame need to be used around PR_SetupParams, regardless of using temp strings, to avoid a stack leak (need to do an audit).
2022-01-24 03:50:15 +00:00
for (int i = 1; i < num_params; i++) {
pr->pr_params[i] = pr->pr_params[0] + i * 4;
}
return pr->pr_params[0];
}
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
static inline void
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pr_memset (pr_type_t *dst, int val, pr_uint_t count)
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
{
while (count-- > 0) {
[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
(*dst++).int_var = val;
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
}
}
[gamecode] Split out the old quake c execution loop There is no reasonable way (due to hardware-enforced alignment issues) to simply convert old bytecode to new (probably best done with an off-line tool, preferably just recompiling when I get qfcc up to the job), so both loops will need to be present. This just moves the original loop into its own function in order to make it easy to bring in the new (and iron out integration issues).
2022-01-02 11:16:45 +00:00
static void
pr_exec_quakec (progs_t *pr, int exitdepth)
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
{
[gamecode] Split out the old quake c execution loop There is no reasonable way (due to hardware-enforced alignment issues) to simply convert old bytecode to new (probably best done with an off-line tool, preferably just recompiling when I get qfcc up to the job), so both loops will need to be present. This just moves the original loop into its own function in order to make it easy to bring in the new (and iron out integration issues).
2022-01-02 11:16:45 +00:00
int profile, startprofile;
Rewrite edict access. The server edict arrays are now stored outside of progs memory, only the entity data itself (ie data accessible to progs via ent.fld) is stored in progs memory. Many of the changes were due to code accessing edicts and entity fields directly rather than through the provided macros.
2013-01-17 05:11:54 +00:00
int fldofs;
make progs related code a little more consistent with its int type usage
2007-04-06 00:47:41 +00:00
pr_uint_t pointer;
dstatement_t *st;
pr_type_t *ptr;
[gamecode] Allow watch-point to be updated With the watch-point address cached in a local var, it was not possible to update the watch-point while the progs were executing.
2020-03-24 10:45:39 +00:00
pr_type_t old_val = {0};
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
Whitespace.
2001-09-10 12:56:23 +00:00
// make a stack frame
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
startprofile = profile = 0;
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
st = pr->pr_statements + pr->pr_xstatement;
"hardware" (haha) watch points (one!) in progs. only catches changes done by progs, and the expression parser is as flaky as anything, but it's better than nothing :)
2007-05-08 02:04:47 +00:00
if (pr->watch) {
[gamecode] Fix some silly errors I forgot to compile-test :(
2020-03-24 14:16:25 +00:00
old_val = *pr->watch;
"hardware" (haha) watch points (one!) in progs. only catches changes done by progs, and the expression parser is as flaky as anything, but it's better than nothing :)
2007-05-08 02:04:47 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
while (1) {
this should speed up progs a little bit
2002-06-07 19:41:13 +00:00
pr_type_t *op_a, *op_b, *op_c;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
st++;
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
++pr->pr_xstatement;
if (pr->pr_xstatement != st - pr->pr_statements)
PR_RunError (pr, "internal error");
fix up #0 builtin functions at runtime. not done automaticly (need to call PR_RelocateBuiltins) and fix a bug with profiling and unlimited execution counts
2001-12-14 08:15:04 +00:00
if (++profile > 1000000 && !pr->no_exec_limit) {
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
PR_RunError (pr, "runaway loop error");
}
this should speed up progs a little bit
2002-06-07 19:41:13 +00:00
op_a = pr->pr_globals + st->a;
op_b = pr->pr_globals + st->b;
op_c = pr->pr_globals + st->c;
[gamecode] Add debug hooks to the VM engine While there was a breakpoint hook, it was for only breakpoints and more was needed. Now there's a generic hook that is called for tracing, breakpoints, watch points, runtime errors and VM errors, with the "event" type passed as the first parameter and a data pointer in the second.
2020-03-24 06:35:42 +00:00
if (pr->pr_trace) {
if (pr->debug_handler) {
[gamecode] Add a param pointer to debug_handler I decided I want events for VM enter/exit but enter needs to somehow pass the function which will be executed (even if a builtin). A generic void * param seemed the best idea, which meant the error string could be passed via the param instead of a "global" string in the progs struct.
2020-03-26 02:44:02 +00:00
pr->debug_handler (prd_trace, 0, pr->debug_data);
[gamecode] Add debug hooks to the VM engine While there was a breakpoint hook, it was for only breakpoints and more was needed. Now there's a generic hook that is called for tracing, breakpoints, watch points, runtime errors and VM errors, with the "event" type passed as the first parameter and a data pointer in the second.
2020-03-24 06:35:42 +00:00
} else {
PR_PrintStatement (pr, st, 1);
}
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
Add a breakpoint flag to opcodes The progs execution code will call a breakpoint handler just before executing an instruction with the flag set. This means there's no need for the breakpoint handler to mess with execution state or even the instruction in order to continue past the breakpoint. The flag being set in a progs file is invalid.
2020-02-26 04:40:26 +00:00
if (st->op & OP_BREAK) {
[gamecode] Add debug hooks to the VM engine While there was a breakpoint hook, it was for only breakpoints and more was needed. Now there's a generic hook that is called for tracing, breakpoints, watch points, runtime errors and VM errors, with the "event" type passed as the first parameter and a data pointer in the second.
2020-03-24 06:35:42 +00:00
if (pr->debug_handler) {
[gamecode] Add a param pointer to debug_handler I decided I want events for VM enter/exit but enter needs to somehow pass the function which will be executed (even if a builtin). A generic void * param seemed the best idea, which meant the error string could be passed via the param instead of a "global" string in the progs struct.
2020-03-26 02:44:02 +00:00
pr->debug_handler (prd_breakpoint, 0, pr->debug_data);
Add a breakpoint flag to opcodes The progs execution code will call a breakpoint handler just before executing an instruction with the flag set. This means there's no need for the breakpoint handler to mess with execution state or even the instruction in order to continue past the breakpoint. The flag being set in a progs file is invalid.
2020-02-26 04:40:26 +00:00
} else {
PR_RunError (pr, "breakpoint hit");
}
}
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
pr_opcode_v6p_e op = st->op & ~OP_BREAK;
Add a breakpoint flag to opcodes The progs execution code will call a breakpoint handler just before executing an instruction with the flag set. This means there's no need for the breakpoint handler to mess with execution state or even the instruction in order to continue past the breakpoint. The flag being set in a progs file is invalid.
2020-02-26 04:40:26 +00:00
switch (op) {
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_ADD_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = OPA(double) + OPB(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_ADD_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(float) + OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_ADD_V_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
VectorAdd (&OPA(float), &OPB(float), &OPC(float));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_ADD_Q_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatAdd (&OPA(float), &OPB(float), &OPC(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_ADD_S_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(string) = PR_CatStrings (pr,
avoid using the hunk in the progs engine (except for the override-able load and alloc functions) so tools (qfprogs and qwaq) don't need to create it. register only the first instance of a progs provided string This is an imperfect revision of history.
2004-11-02 04:59:00 +00:00
PR_GetString (pr,
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPA(string)),
avoid using the hunk in the progs engine (except for the override-able load and alloc functions) so tools (qfprogs and qwaq) don't need to create it. register only the first instance of a progs provided string This is an imperfect revision of history.
2004-11-02 04:59:00 +00:00
PR_GetString (pr,
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPB(string)));
pr_comp.h: add OP_ADD_S. WARNING!!! this /will/ move. progs.h: add prototype for PR_PrintStatement pr_edict.c: add OP_ADD_S support in the progs checker pr_exec.c: implement OP_ADD_S tools/qfcc/include/.gitignore: add config.h.in qfcc.h: nuke PR_NameImmediate and change PR_ParseImmediate's prototype (see pr_imm.c) pr_comp.c: add ADD_S, adjust for PR_ParseImmediate's prototype, make PR_ParseExpression work with non-sequential opcodes (slow, will work on that next). Fix up initialised global parsing. pr_imm.c: nuke PR_NameImmediate. didn't work well and wasn't such a good idea anyway. PR_ParseImmediate now accepts a def_t * arg. if null, will allocate a new global def, otherwise it will initialize the def passed in. qwaq/main.c: sports some debugging code (dumps info about the progs it's running) qwaq/main.qc: better ADD_S testing
2001-06-03 17:36:49 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SUB_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = OPA(double) - OPB(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SUB_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(float) - OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SUB_V_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
VectorSubtract (&OPA(float), &OPB(float),
&OPC(float));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SUB_Q_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatSubtract (&OPA(float), &OPB(float), &OPC(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = OPA(double) * OPB(double);
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(float) * OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_V_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = DotProduct (&OPA(float), &OPB(float));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_DV_v6p:
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
{
// avoid issues with the likes of x = x.x * x;
// makes for faster code, too
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
double scale = OPA(double);
VectorScale (&OPB(float), scale, &OPC(float));
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_VD_v6p:
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
{
// avoid issues with the likes of x = x * x.x;
// makes for faster code, too
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
double scale = OPB(double);
VectorScale (&OPA(float), scale, &OPC(float));
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_FV_v6p:
Fix the vector/quaternion scaling instructions. It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy when the operands overlapped (eg, x = x.x * x) as the result would become 'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On testing, sure enough the bug was present (and is a nice demonstration that QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the code produced by the fixes is actually faster than the broken version :). The ruamoko code used for testing: void (string fmt, ...) printf = #0; vector foo (vector x) { x = x * x.x; return x; } vector bar (vector x) { x = x.x * x; return x; } int main () { vector x = '2 3 4'; vector y = foo (x); vector z = bar (x); printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x); return 0; }
2013-01-17 01:23:02 +00:00
{
// avoid issues with the likes of x = x.x * x;
// makes for faster code, too
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
float scale = OPA(float);
VectorScale (&OPB(float), scale, &OPC(float));
Fix the vector/quaternion scaling instructions. It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy when the operands overlapped (eg, x = x.x * x) as the result would become 'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On testing, sure enough the bug was present (and is a nice demonstration that QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the code produced by the fixes is actually faster than the broken version :). The ruamoko code used for testing: void (string fmt, ...) printf = #0; vector foo (vector x) { x = x * x.x; return x; } vector bar (vector x) { x = x.x * x; return x; } int main () { vector x = '2 3 4'; vector y = foo (x); vector z = bar (x); printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x); return 0; }
2013-01-17 01:23:02 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_VF_v6p:
Fix the vector/quaternion scaling instructions. It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy when the operands overlapped (eg, x = x.x * x) as the result would become 'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On testing, sure enough the bug was present (and is a nice demonstration that QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the code produced by the fixes is actually faster than the broken version :). The ruamoko code used for testing: void (string fmt, ...) printf = #0; vector foo (vector x) { x = x * x.x; return x; } vector bar (vector x) { x = x.x * x; return x; } int main () { vector x = '2 3 4'; vector y = foo (x); vector z = bar (x); printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x); return 0; }
2013-01-17 01:23:02 +00:00
{
// avoid issues with the likes of x = x * x.x;
// makes for faster code, too
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
float scale = OPB(float);
VectorScale (&OPA(float), scale, &OPC(float));
Fix the vector/quaternion scaling instructions. It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy when the operands overlapped (eg, x = x.x * x) as the result would become 'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On testing, sure enough the bug was present (and is a nice demonstration that QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the code produced by the fixes is actually faster than the broken version :). The ruamoko code used for testing: void (string fmt, ...) printf = #0; vector foo (vector x) { x = x * x.x; return x; } vector bar (vector x) { x = x.x * x; return x; } int main () { vector x = '2 3 4'; vector y = foo (x); vector z = bar (x); printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x); return 0; }
2013-01-17 01:23:02 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_Q_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatMult (&OPA(float), &OPB(float), &OPC(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_QV_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatMultVec (&OPA(float), &OPB(float), &OPC(float));
Add vec = quat * vec to the progs engine.
2012-04-26 01:29:21 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_DQ_v6p:
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
{
// avoid issues with the likes of x = x.s * x;
// makes for faster code, too
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
double scale = OPA(double);
QuatScale (&OPB(float), scale, &OPC(float));
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_QD_v6p:
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
{
// avoid issues with the likes of x = x * x.s;
// makes for faster code, too
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
double scale = OPB(double);
QuatScale (&OPA(float), scale, &OPC(float));
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
}
Add vec = quat * vec to the progs engine.
2012-04-26 01:29:21 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_FQ_v6p:
Fix the vector/quaternion scaling instructions. It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy when the operands overlapped (eg, x = x.x * x) as the result would become 'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On testing, sure enough the bug was present (and is a nice demonstration that QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the code produced by the fixes is actually faster than the broken version :). The ruamoko code used for testing: void (string fmt, ...) printf = #0; vector foo (vector x) { x = x * x.x; return x; } vector bar (vector x) { x = x.x * x; return x; } int main () { vector x = '2 3 4'; vector y = foo (x); vector z = bar (x); printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x); return 0; }
2013-01-17 01:23:02 +00:00
{
// avoid issues with the likes of x = x.s * x;
// makes for faster code, too
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
float scale = OPA(float);
QuatScale (&OPB(float), scale, &OPC(float));
Fix the vector/quaternion scaling instructions. It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy when the operands overlapped (eg, x = x.x * x) as the result would become 'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On testing, sure enough the bug was present (and is a nice demonstration that QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the code produced by the fixes is actually faster than the broken version :). The ruamoko code used for testing: void (string fmt, ...) printf = #0; vector foo (vector x) { x = x * x.x; return x; } vector bar (vector x) { x = x.x * x; return x; } int main () { vector x = '2 3 4'; vector y = foo (x); vector z = bar (x); printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x); return 0; }
2013-01-17 01:23:02 +00:00
}
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_QF_v6p:
Fix the vector/quaternion scaling instructions. It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy when the operands overlapped (eg, x = x.x * x) as the result would become 'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On testing, sure enough the bug was present (and is a nice demonstration that QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the code produced by the fixes is actually faster than the broken version :). The ruamoko code used for testing: void (string fmt, ...) printf = #0; vector foo (vector x) { x = x * x.x; return x; } vector bar (vector x) { x = x.x * x; return x; } int main () { vector x = '2 3 4'; vector y = foo (x); vector z = bar (x); printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x); return 0; }
2013-01-17 01:23:02 +00:00
{
// avoid issues with the likes of x = x * x.s;
// makes for faster code, too
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
float scale = OPB(float);
QuatScale (&OPA(float), scale, &OPC(float));
Fix the vector/quaternion scaling instructions. It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy when the operands overlapped (eg, x = x.x * x) as the result would become 'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On testing, sure enough the bug was present (and is a nice demonstration that QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the code produced by the fixes is actually faster than the broken version :). The ruamoko code used for testing: void (string fmt, ...) printf = #0; vector foo (vector x) { x = x * x.x; return x; } vector bar (vector x) { x = x.x * x; return x; } int main () { vector x = '2 3 4'; vector y = foo (x); vector z = bar (x); printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x); return 0; }
2013-01-17 01:23:02 +00:00
}
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_CONJ_Q_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatConj (&OPA(float), &OPC(float));
quaternion conjugate support (engine side)
2004-04-08 04:57:17 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_DIV_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = OPA(double) / OPB(double);
quaternion conjugate support (engine side)
2004-04-08 04:57:17 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_DIV_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(float) / OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BITAND_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = (int) OPA(float) & (int) OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BITOR_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = (int) OPA(float) | (int) OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BITXOR_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = (int) OPA(float) ^ (int) OPB(float);
^ and ~ operators for qc (^ from Rhamphoryncus) and clean up the punctuation line in qc-lex.l (why didn't I think to do that in the first place?!?)
2001-08-09 16:34:46 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BITNOT_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = ~ (int) OPA(float);
^ and ~ operators for qc (^ from Rhamphoryncus) and clean up the punctuation line in qc-lex.l (why didn't I think to do that in the first place?!?)
2001-08-09 16:34:46 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SHL_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = (int) OPA(float) << (int) OPB(float);
got a few new operators for qc :) << >> % which all act like their C counterparts += -= *= /= &= ^= |= <<= >>= %= which just expand into the obvious, also like the C versions.
2001-08-10 16:17:00 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SHR_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = (int) OPA(float) >> (int) OPB(float);
got a few new operators for qc :) << >> % which all act like their C counterparts += -= *= /= &= ^= |= <<= >>= %= which just expand into the obvious, also like the C versions.
2001-08-10 16:17:00 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SHL_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) << OPB(int);
got a few new operators for qc :) << >> % which all act like their C counterparts += -= *= /= &= ^= |= <<= >>= %= which just expand into the obvious, also like the C versions.
2001-08-10 16:17:00 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SHR_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) >> OPB(int);
got a few new operators for qc :) << >> % which all act like their C counterparts += -= *= /= &= ^= |= <<= >>= %= which just expand into the obvious, also like the C versions.
2001-08-10 16:17:00 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SHR_U_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(uint) = OPA(uint) >> OPB(int);
get unsigned mostly working
2003-08-01 21:20:04 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GE_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(float) >= OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LE_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(float) <= OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GT_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(float) > OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LT_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(float) < OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_AND_v6p: // OPA and OPB have to be float for -0.0
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = FNZ (OPA(uint)) && FNZ (OPB(uint));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_OR_v6p: // OPA and OPB have to be float for -0.0
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = FNZ (OPA(uint)) || FNZ (OPB(uint));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NOT_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = !FNZ (OPA(uint));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NOT_V_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = VectorIsZero (&OPA(float));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NOT_Q_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = QuatIsZero (&OPA(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NOT_S_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = !OPA(string) || !*PR_GetString (pr, OPA(string));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NOT_FN_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = !OPA(func);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NOT_ENT_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = !OPA(entity);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_EQ_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(float) == OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_EQ_V_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = VectorCompare (&OPA(float), &OPB(float));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_EQ_Q_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = QuatCompare (&OPA(float), &OPB(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_EQ_E_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = OPA(field) == OPB(field);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_EQ_FN_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = OPA(func) == OPB(func);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NE_F_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(float) != OPB(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NE_V_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = !VectorCompare (&OPA(float), &OPB(float));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NE_Q_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = !QuatCompare (&OPA(float), &OPB(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LE_S_v6p:
case OP_GE_S_v6p:
case OP_LT_S_v6p:
case OP_GT_S_v6p:
case OP_NE_S_v6p:
case OP_EQ_S_v6p:
string comparison operators
2001-06-04 03:36:35 +00:00
{
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
int cmp = strcmp (PR_GetString (pr, OPA(string)),
PR_GetString (pr, OPB(string)));
string comparison operators
2001-06-04 03:36:35 +00:00
switch (st->op) {
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LE_S_v6p: cmp = (cmp <= 0); break;
case OP_GE_S_v6p: cmp = (cmp >= 0); break;
case OP_LT_S_v6p: cmp = (cmp < 0); break;
case OP_GT_S_v6p: cmp = (cmp > 0); break;
case OP_NE_S_v6p: break;
case OP_EQ_S_v6p: cmp = !cmp; break;
blah, enums and switch... (at least gcc 3.1 is warning about that again:)
2002-06-09 16:31:08 +00:00
default: break;
string comparison operators
2001-06-04 03:36:35 +00:00
}
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = cmp;
string comparison operators
2001-06-04 03:36:35 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NE_E_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = OPA(entity) != OPB(entity);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NE_FN_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPC(int) = OPA(func) != OPB(func);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
new operand handling from nq
2001-02-27 08:21:40 +00:00
// ==================
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STORE_F_v6p:
case OP_STORE_ENT_v6p:
case OP_STORE_FLD_v6p: // integers
case OP_STORE_S_v6p:
case OP_STORE_FN_v6p: // pointers
case OP_STORE_I_v6p:
case OP_STORE_P_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPB(int) = OPA(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STORE_V_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
VectorCopy (&OPA(float), &OPB(float));
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STORE_Q_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatCopy (&OPA(float), &OPB(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STORE_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPB(double) = OPA(double);
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREP_F_v6p:
case OP_STOREP_ENT_v6p:
case OP_STOREP_FLD_v6p: // integers
case OP_STOREP_S_v6p:
case OP_STOREP_FN_v6p: // pointers
case OP_STOREP_I_v6p:
case OP_STOREP_P_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[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
PR_BoundsCheck (pr, pointer, ev_int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
ptr = pr->pr_globals + pointer;
[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
ptr->int_var = OPA(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREP_V_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
PR_BoundsCheck (pr, pointer, ev_vector);
}
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
VectorCopy (&OPA(float), &ptr->vector_var);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREP_Q_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatCopy (&OPA(float), &ptr->quat_var);
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREP_D_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
if (pr_boundscheck->int_val) {
PR_BoundsCheck (pr, pointer, ev_double);
}
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
*(double *) ptr = OPA(double);
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_ADDRESS_v6p:
do a pre and post pass for maps/mapname.cfg and use maps_default.cfg if maps/mapname.cfg doesn't exist.
2002-11-08 02:43:04 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPA(entity) >= pr->pr_edict_area_size)
do a pre and post pass for maps/mapname.cfg and use maps_default.cfg if maps/mapname.cfg doesn't exist.
2002-11-08 02:43:04 +00:00
PR_RunError (pr, "Progs attempted to address an out "
"of bounds edict");
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPA(entity) == 0 && pr->null_bad)
do a pre and post pass for maps/mapname.cfg and use maps_default.cfg if maps/mapname.cfg doesn't exist.
2002-11-08 02:43:04 +00:00
PR_RunError (pr, "assignment to world entity");
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPB(field) >= pr->progs->entityfields)
do a pre and post pass for maps/mapname.cfg and use maps_default.cfg if maps/mapname.cfg doesn't exist.
2002-11-08 02:43:04 +00:00
PR_RunError (pr, "Progs attempted to address an "
"invalid field in an edict");
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
fldofs = OPA(entity) + OPB(field);
OPC(ptr) = &pr->pr_edict_area[fldofs] - pr->pr_globals;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_ADDRESS_VOID_v6p:
case OP_ADDRESS_F_v6p:
case OP_ADDRESS_V_v6p:
case OP_ADDRESS_Q_v6p:
case OP_ADDRESS_S_v6p:
case OP_ADDRESS_ENT_v6p:
case OP_ADDRESS_FLD_v6p:
case OP_ADDRESS_FN_v6p:
case OP_ADDRESS_I_v6p:
case OP_ADDRESS_P_v6p:
case OP_ADDRESS_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = st->a;
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOAD_F_v6p:
case OP_LOAD_FLD_v6p:
case OP_LOAD_ENT_v6p:
case OP_LOAD_S_v6p:
case OP_LOAD_FN_v6p:
case OP_LOAD_I_v6p:
case OP_LOAD_P_v6p:
do a pre and post pass for maps/mapname.cfg and use maps_default.cfg if maps/mapname.cfg doesn't exist.
2002-11-08 02:43:04 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPA(entity) >= pr->pr_edict_area_size)
do a pre and post pass for maps/mapname.cfg and use maps_default.cfg if maps/mapname.cfg doesn't exist.
2002-11-08 02:43:04 +00:00
PR_RunError (pr, "Progs attempted to read an out of "
"bounds edict number");
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPB(field) >= pr->progs->entityfields)
do a pre and post pass for maps/mapname.cfg and use maps_default.cfg if maps/mapname.cfg doesn't exist.
2002-11-08 02:43:04 +00:00
PR_RunError (pr, "Progs attempted to read an invalid "
"field in an edict");
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
fldofs = OPA(entity) + OPB(field);
[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
OPC(int) = pr->pr_edict_area[fldofs].int_var;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOAD_V_v6p:
do a pre and post pass for maps/mapname.cfg and use maps_default.cfg if maps/mapname.cfg doesn't exist.
2002-11-08 02:43:04 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPA(entity) >= pr->pr_edict_area_size)
engine side quaternion support
2004-04-08 00:56:30 +00:00
PR_RunError (pr, "Progs attempted to read an out of "
"bounds edict number");
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPB(field) + 2 >= pr->progs->entityfields)
engine side quaternion support
2004-04-08 00:56:30 +00:00
PR_RunError (pr, "Progs attempted to read an invalid "
"field in an edict");
}
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
fldofs = OPA(entity) + OPB(field);
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
memcpy (op_c, &pr->pr_edict_area[fldofs], 3 * sizeof (*op_c));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOAD_Q_v6p:
engine side quaternion support
2004-04-08 00:56:30 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPA(entity) >= pr->pr_edict_area_size)
engine side quaternion support
2004-04-08 00:56:30 +00:00
PR_RunError (pr, "Progs attempted to read an out of "
"bounds edict number");
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPB(field) + 3 >= pr->progs->entityfields)
engine side quaternion support
2004-04-08 00:56:30 +00:00
PR_RunError (pr, "Progs attempted to read an invalid "
"field in an edict");
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
fldofs = OPA(entity) + OPB(field);
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
memcpy (op_c, &pr->pr_edict_area[fldofs], 4 * sizeof (*op_c));
new operand handling from nq
2001-02-27 08:21:40 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOAD_D_v6p:
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPA(entity) >= pr->pr_edict_area_size)
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
PR_RunError (pr, "Progs attempted to read an out of "
"bounds edict number");
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPB(field) + 1 >= pr->progs->entityfields)
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
PR_RunError (pr, "Progs attempted to read an invalid "
"field in an edict");
}
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
fldofs = OPA(entity) + OPB(field);
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
memcpy (op_c, &pr->pr_edict_area[fldofs], sizeof (double));
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOADB_F_v6p:
case OP_LOADB_S_v6p:
case OP_LOADB_ENT_v6p:
case OP_LOADB_FLD_v6p:
case OP_LOADB_FN_v6p:
case OP_LOADB_I_v6p:
case OP_LOADB_P_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(entity) + OPB(field);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[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
PR_BoundsCheck (pr, pointer, ev_int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
ptr = pr->pr_globals + pointer;
[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
OPC(int) = ptr->int_var;
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOADB_V_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(entity) + OPB(field);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
PR_BoundsCheck (pr, pointer, ev_vector);
}
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
VectorCopy (&ptr->vector_var, &OPC(float));
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOADB_Q_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(entity) + OPB(field);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
engine side quaternion support
2004-04-08 00:56:30 +00:00
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatCopy (&ptr->quat_var, &OPC(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOADB_D_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(entity) + OPB(field);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
if (pr_boundscheck->int_val) {
PR_BoundsCheck (pr, pointer, ev_double);
}
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = *(double *) ptr;
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOADBI_F_v6p:
case OP_LOADBI_S_v6p:
case OP_LOADBI_ENT_v6p:
case OP_LOADBI_FLD_v6p:
case OP_LOADBI_FN_v6p:
case OP_LOADBI_I_v6p:
case OP_LOADBI_P_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + (short) st->b;
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[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
PR_BoundsCheck (pr, pointer, ev_int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
ptr = pr->pr_globals + pointer;
[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
OPC(int) = ptr->int_var;
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOADBI_V_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + (short) st->b;
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
PR_BoundsCheck (pr, pointer, ev_vector);
}
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
VectorCopy (&ptr->vector_var, &OPC(float));
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOADBI_Q_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + (short) st->b;
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
engine side quaternion support
2004-04-08 00:56:30 +00:00
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatCopy (&ptr->quat_var, &OPC(float));
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LOADBI_D_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + (short) st->b;
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
}
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = *(double *) ptr;
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LEA_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + OPB(int);
OPC(ptr) = pointer;
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LEAI_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + (short) st->b;
OPC(ptr) = pointer;
ok, structures seem to generate correct code now
2001-12-08 08:19:48 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREB_F_v6p:
case OP_STOREB_S_v6p:
case OP_STOREB_ENT_v6p:
case OP_STOREB_FLD_v6p:
case OP_STOREB_FN_v6p:
case OP_STOREB_I_v6p:
case OP_STOREB_P_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr) + OPC(int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[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
PR_BoundsCheck (pr, pointer, ev_int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
ptr = pr->pr_globals + pointer;
[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
ptr->int_var = OPA(int);
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREB_V_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr) + OPC(int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
PR_BoundsCheck (pr, pointer, ev_vector);
}
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
VectorCopy (&OPA(float), &ptr->vector_var);
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREB_Q_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr) + OPC(int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
engine side quaternion support
2004-04-08 00:56:30 +00:00
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatCopy (&OPA(float), &ptr->quat_var);
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREB_D_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr) + OPC(int);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
}
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
*(double *) ptr = OPA(double);
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
pr_comp.h: - new opcodes for pointers progs.h: - prototype PR_Check_Opcodes pr_edict.c: - move the static bounds checking to PR_Check_Opcodes in pr_opcode.c pr_exec.c: - vector instruction cleanup - temporarily nuke bounds checking from storep.* - move base of address results from pr->edicts to pr->pr_globals - implement new pointer related instructions - nuke proposed global pointer instructions (not flexible enough) pr_opcode.c: - add new pointer instuctions - re-implement static bounds/invalid opcode checking. no more multiple case statements to keep track of.
2001-11-02 22:41:11 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREBI_F_v6p:
case OP_STOREBI_S_v6p:
case OP_STOREBI_ENT_v6p:
case OP_STOREBI_FLD_v6p:
case OP_STOREBI_FN_v6p:
case OP_STOREBI_I_v6p:
case OP_STOREBI_P_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr) + (short) st->c;
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[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
PR_BoundsCheck (pr, pointer, ev_int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
ptr = pr->pr_globals + pointer;
[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
ptr->int_var = OPA(int);
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREBI_V_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr) + (short) st->c;
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
PR_BoundsCheck (pr, pointer, ev_vector);
}
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
VectorCopy (&OPA(float), &ptr->vector_var);
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREBI_Q_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr) + (short) st->c;
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
engine side quaternion support
2004-04-08 00:56:30 +00:00
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
QuatCopy (&OPA(float), &ptr->quat_var);
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STOREBI_D_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPB(ptr) + (short) st->c;
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
}
ptr = pr->pr_globals + pointer;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
*(double *) ptr = OPA(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSH_F_v6p:
case OP_PUSH_FLD_v6p:
case OP_PUSH_ENT_v6p:
case OP_PUSH_S_v6p:
case OP_PUSH_FN_v6p:
case OP_PUSH_I_v6p:
case OP_PUSH_P_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 1;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 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
stk->int_var = OPA(int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSH_V_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 3;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 3);
}
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
memcpy (stk, op_a, 3 * sizeof (*op_c));
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSH_Q_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 4;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 4);
}
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
memcpy (stk, op_a, 4 * sizeof (*op_c));
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSHB_F_v6p:
case OP_PUSHB_S_v6p:
case OP_PUSHB_ENT_v6p:
case OP_PUSHB_FLD_v6p:
case OP_PUSHB_FN_v6p:
case OP_PUSHB_I_v6p:
case OP_PUSHB_P_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 1;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + OPB(int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 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
PR_BoundsCheck (pr, pointer, ev_int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[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
stk->int_var = ptr->int_var;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSHB_V_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 3;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + OPB(int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 3);
[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
PR_BoundsCheck (pr, pointer, ev_int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[build] Fix a pile of gcc 10 issues gcc got stricter about array accesses, complicating progs macros, and much better at detecting buffer overflows.
2020-12-20 17:12:51 +00:00
VectorCopy (&ptr->vector_var, &stk->vector_var);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSHB_Q_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 4;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + OPB(int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 4);
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[build] Fix a pile of gcc 10 issues gcc got stricter about array accesses, complicating progs macros, and much better at detecting buffer overflows.
2020-12-20 17:12:51 +00:00
QuatCopy (&ptr->quat_var, &stk->quat_var);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSHBI_F_v6p:
case OP_PUSHBI_S_v6p:
case OP_PUSHBI_ENT_v6p:
case OP_PUSHBI_FLD_v6p:
case OP_PUSHBI_FN_v6p:
case OP_PUSHBI_I_v6p:
case OP_PUSHBI_P_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 1;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + st->b;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 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
PR_BoundsCheck (pr, pointer, ev_int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[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
stk->int_var = ptr->int_var;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSHBI_V_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 3;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + st->b;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 3);
[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
PR_BoundsCheck (pr, pointer, ev_int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[build] Fix a pile of gcc 10 issues gcc got stricter about array accesses, complicating progs macros, and much better at detecting buffer overflows.
2020-12-20 17:12:51 +00:00
VectorCopy (&ptr->vector_var, &stk->vector_var);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_PUSHBI_Q_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 4;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + st->b;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 4);
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[build] Fix a pile of gcc 10 issues gcc got stricter about array accesses, complicating progs macros, and much better at detecting buffer overflows.
2020-12-20 17:12:51 +00:00
QuatCopy (&ptr->quat_var, &stk->quat_var);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POP_F_v6p:
case OP_POP_FLD_v6p:
case OP_POP_ENT_v6p:
case OP_POP_S_v6p:
case OP_POP_FN_v6p:
case OP_POP_I_v6p:
case OP_POP_P_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 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
OPA(int) = stk->int_var;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 1;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POP_V_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 3);
}
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
memcpy (op_a, stk, 3 * sizeof (*op_c));
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 3;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POP_Q_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 4);
}
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
memcpy (op_a, stk, 4 * sizeof (*op_c));
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 4;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POPB_F_v6p:
case OP_POPB_S_v6p:
case OP_POPB_ENT_v6p:
case OP_POPB_FLD_v6p:
case OP_POPB_FN_v6p:
case OP_POPB_I_v6p:
case OP_POPB_P_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + OPB(int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 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
PR_BoundsCheck (pr, pointer, ev_int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[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
ptr->int_var = stk->int_var;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 1;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POPB_V_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + OPB(int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 3);
[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
PR_BoundsCheck (pr, pointer, ev_int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[gamecode] Correct pop implementations Had src and dst swapped (yay for not testing :P (boo for not having an easy way to test (yay for working on it))).
2021-07-19 13:31:22 +00:00
VectorCopy (&stk->vector_var, &ptr->vector_var);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 3;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POPB_Q_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + OPB(int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 4);
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[gamecode] Correct pop implementations Had src and dst swapped (yay for not testing :P (boo for not having an easy way to test (yay for working on it))).
2021-07-19 13:31:22 +00:00
QuatCopy (&stk->quat_var, &ptr->quat_var);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 4;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POPBI_F_v6p:
case OP_POPBI_S_v6p:
case OP_POPBI_ENT_v6p:
case OP_POPBI_FLD_v6p:
case OP_POPBI_FN_v6p:
case OP_POPBI_I_v6p:
case OP_POPBI_P_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + st->b;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 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
PR_BoundsCheck (pr, pointer, ev_int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[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
ptr->int_var = stk->int_var;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 1;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POPBI_V_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + st->b;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 3);
[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
PR_BoundsCheck (pr, pointer, ev_int);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[gamecode] Correct pop implementations Had src and dst swapped (yay for not testing :P (boo for not having an easy way to test (yay for working on it))).
2021-07-19 13:31:22 +00:00
VectorCopy (&stk->vector_var, &ptr->vector_var);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 3;
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_POPBI_Q_v6p:
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
pr_type_t *stk = pr->pr_globals + stack;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pointer = OPA(ptr) + st->b;
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
ptr = pr->pr_globals + pointer;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 4);
[gamecode] Rename ev_quat to ev_quaternion I much prefer the full name, though the short version is easier to type.
2022-01-18 06:48:43 +00:00
PR_BoundsCheck (pr, pointer, ev_quaternion);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
}
[gamecode] Correct pop implementations Had src and dst swapped (yay for not testing :P (boo for not having an easy way to test (yay for working on it))).
2021-07-19 13:31:22 +00:00
QuatCopy (&stk->quat_var, &ptr->quat_var);
Add a stack and push and pop instructions. The stack is for data, not return addresses.
2018-10-11 04:24:03 +00:00
*pr->globals.stack = stack + 4;
}
engine side quaternion support
2004-04-08 00:56:30 +00:00
break;
immidiate indexed pointer access and some whitespace + reorg
2001-12-07 20:07:38 +00:00
new operand handling from nq
2001-02-27 08:21:40 +00:00
// ==================
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_IFNOT_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
if (!OPA(int)) {
bah, forgot to -1 the instruction pointer for jumpb
2003-08-24 07:23:12 +00:00
pr->pr_xstatement += (short)st->b - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_IF_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
if (OPA(int)) {
bah, forgot to -1 the instruction pointer for jumpb
2003-08-24 07:23:12 +00:00
pr->pr_xstatement += (short)st->b - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_IFBE_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
if (OPA(int) <= 0) {
bah, forgot to -1 the instruction pointer for jumpb
2003-08-24 07:23:12 +00:00
pr->pr_xstatement += (short)st->b - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
}
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_IFB_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
if (OPA(int) < 0) {
bah, forgot to -1 the instruction pointer for jumpb
2003-08-24 07:23:12 +00:00
pr->pr_xstatement += (short)st->b - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
}
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_IFAE_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
if (OPA(int) >= 0) {
bah, forgot to -1 the instruction pointer for jumpb
2003-08-24 07:23:12 +00:00
pr->pr_xstatement += (short)st->b - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
}
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_IFA_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
if (OPA(int) > 0) {
bah, forgot to -1 the instruction pointer for jumpb
2003-08-24 07:23:12 +00:00
pr->pr_xstatement += (short)st->b - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
}
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GOTO_v6p:
bah, forgot to -1 the instruction pointer for jumpb
2003-08-24 07:23:12 +00:00
pr->pr_xstatement += (short)st->a - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_JUMP_v6p:
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
if (pr_boundscheck->int_val
[gamecode] Use a struct for offset/count pairs This cleans up dprograms_t, making it easier to read and see what chunks are in it (I was surprised to see only 6, the explicit pairs made it seem to have more).
2022-01-26 10:30:25 +00:00
&& (OPA(uint) >= pr->progs->statements.count)) {
search for `.self' before `self'
2002-05-18 00:49:16 +00:00
PR_RunError (pr, "Invalid jump destination");
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
}
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
pr->pr_xstatement = OPA(uint) - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_JUMPB_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
pointer = st->a + OPB(int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[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
PR_BoundsCheck (pr, pointer, ev_int);
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
pr_comp.h: o add OP_JUMPB o OP_JUMPB renumberd some opcodes, so up PROG_VERSION pr_edict.c: o make the version error reporting more informative pr_exec.c: o implement OP_JUMPB (goto *(ptr + index)) pr_opcode.c: (libs/gamecode/engine) o add OP_JUMPB to the table expr.h: o ex_uinteger support o some const correctness o prototype new_label_expr qfcc.h: o uinteger ussport o add pointers for op_jump and op_jumpb o prototype PR_GetArray emit.c: o general uinteger support o new reference/reloc type 3: absolute statement address o jumpb support (binary goto) expr.c: o uinteger support o break the label name creation out of new_label_expr into new_label_name o some const correctness pr_def.c: o add PR_GetArray to allocate an array in global space o factor out some code common to PR_GetDef and PR_GetArray that would otherwise be duplicated pr_imm.c: o some const correctness o uinteger support pr_lex.c: o uinteger support pr_opcode.c: (tools/qfcc/source) o support jump and jumpb switch.c: o rewrite the binary search code to support ranges.
2001-11-13 08:58:54 +00:00
ptr = pr->pr_globals + pointer;
[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
pointer = ptr->int_var;
pr_comp.h: o add OP_JUMPB o OP_JUMPB renumberd some opcodes, so up PROG_VERSION pr_edict.c: o make the version error reporting more informative pr_exec.c: o implement OP_JUMPB (goto *(ptr + index)) pr_opcode.c: (libs/gamecode/engine) o add OP_JUMPB to the table expr.h: o ex_uinteger support o some const correctness o prototype new_label_expr qfcc.h: o uinteger ussport o add pointers for op_jump and op_jumpb o prototype PR_GetArray emit.c: o general uinteger support o new reference/reloc type 3: absolute statement address o jumpb support (binary goto) expr.c: o uinteger support o break the label name creation out of new_label_expr into new_label_name o some const correctness pr_def.c: o add PR_GetArray to allocate an array in global space o factor out some code common to PR_GetDef and PR_GetArray that would otherwise be duplicated pr_imm.c: o some const correctness o uinteger support pr_lex.c: o uinteger support pr_opcode.c: (tools/qfcc/source) o support jump and jumpb switch.c: o rewrite the binary search code to support ranges.
2001-11-13 08:58:54 +00:00
if (pr_boundscheck->int_val
[gamecode] Use a struct for offset/count pairs This cleans up dprograms_t, making it easier to read and see what chunks are in it (I was surprised to see only 6, the explicit pairs made it seem to have more).
2022-01-26 10:30:25 +00:00
&& (pointer >= pr->progs->statements.count)) {
search for `.self' before `self'
2002-05-18 00:49:16 +00:00
PR_RunError (pr, "Invalid jump destination");
pr_comp.h: o add OP_JUMPB o OP_JUMPB renumberd some opcodes, so up PROG_VERSION pr_edict.c: o make the version error reporting more informative pr_exec.c: o implement OP_JUMPB (goto *(ptr + index)) pr_opcode.c: (libs/gamecode/engine) o add OP_JUMPB to the table expr.h: o ex_uinteger support o some const correctness o prototype new_label_expr qfcc.h: o uinteger ussport o add pointers for op_jump and op_jumpb o prototype PR_GetArray emit.c: o general uinteger support o new reference/reloc type 3: absolute statement address o jumpb support (binary goto) expr.c: o uinteger support o break the label name creation out of new_label_expr into new_label_name o some const correctness pr_def.c: o add PR_GetArray to allocate an array in global space o factor out some code common to PR_GetDef and PR_GetArray that would otherwise be duplicated pr_imm.c: o some const correctness o uinteger support pr_lex.c: o uinteger support pr_opcode.c: (tools/qfcc/source) o support jump and jumpb switch.c: o rewrite the binary search code to support ranges.
2001-11-13 08:58:54 +00:00
}
bah, forgot to -1 the instruction pointer for jumpb
2003-08-24 07:23:12 +00:00
pr->pr_xstatement = pointer - 1; // offset the st++
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
pr_comp.h: o add OP_JUMPB o OP_JUMPB renumberd some opcodes, so up PROG_VERSION pr_edict.c: o make the version error reporting more informative pr_exec.c: o implement OP_JUMPB (goto *(ptr + index)) pr_opcode.c: (libs/gamecode/engine) o add OP_JUMPB to the table expr.h: o ex_uinteger support o some const correctness o prototype new_label_expr qfcc.h: o uinteger ussport o add pointers for op_jump and op_jumpb o prototype PR_GetArray emit.c: o general uinteger support o new reference/reloc type 3: absolute statement address o jumpb support (binary goto) expr.c: o uinteger support o break the label name creation out of new_label_expr into new_label_name o some const correctness pr_def.c: o add PR_GetArray to allocate an array in global space o factor out some code common to PR_GetDef and PR_GetArray that would otherwise be duplicated pr_imm.c: o some const correctness o uinteger support pr_lex.c: o uinteger support pr_opcode.c: (tools/qfcc/source) o support jump and jumpb switch.c: o rewrite the binary search code to support ranges.
2001-11-13 08:58:54 +00:00
break;
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_RCALL2_v6p:
case OP_RCALL3_v6p:
case OP_RCALL4_v6p:
case OP_RCALL5_v6p:
case OP_RCALL6_v6p:
case OP_RCALL7_v6p:
case OP_RCALL8_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
pr->pr_params[1] = op_c;
implement Raven's calling convention (rcall: first 2 params in opb and opc). should give a general speedup to most progs.
2005-06-12 09:54:01 +00:00
goto op_rcall;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_RCALL1_v6p:
implement Raven's calling convention (rcall: first 2 params in opb and opc). should give a general speedup to most progs.
2005-06-12 09:54:01 +00:00
pr->pr_params[1] = pr->pr_real_params[1];
op_rcall:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
pr->pr_params[0] = op_b;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
pr->pr_argc = st->op - OP_RCALL1_v6p + 1;
implement Raven's calling convention (rcall: first 2 params in opb and opc). should give a general speedup to most progs.
2005-06-12 09:54:01 +00:00
goto op_call;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_CALL0_v6p:
case OP_CALL1_v6p:
case OP_CALL2_v6p:
case OP_CALL3_v6p:
case OP_CALL4_v6p:
case OP_CALL5_v6p:
case OP_CALL6_v6p:
case OP_CALL7_v6p:
case OP_CALL8_v6p:
implement Raven's calling convention (rcall: first 2 params in opb and opc). should give a general speedup to most progs.
2005-06-12 09:54:01 +00:00
PR_RESET_PARAMS (pr);
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
pr->pr_argc = st->op - OP_CALL0_v6p;
implement Raven's calling convention (rcall: first 2 params in opb and opc). should give a general speedup to most progs.
2005-06-12 09:54:01 +00:00
op_call:
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
pr->pr_xfunction->profile += profile - startprofile;
startprofile = profile;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
PR_CallFunction (pr, OPA(func), pr->pr_return);
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_DONE_v6p:
case OP_RETURN_v6p:
handle "return 0" a bit better. assumes location is is always 0, but it always has been (and always /should/ be anyway:)
2003-08-13 17:27:34 +00:00
if (!st->a)
memset (&R_INT (pr), 0,
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
pr->pr_param_size * sizeof (*op_a));
else if (&R_INT (pr) != &OPA(int))
memcpy (&R_INT (pr), op_a,
pr->pr_param_size * sizeof (*op_a));
Add a "void return" instruction. I got fed up with always having to explicty return something.
2011-01-12 15:29:56 +00:00
// fallthrough
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_RETURN_V_v6p:
fix an accounting error
2003-09-15 21:13:13 +00:00
pr->pr_xfunction->profile += profile - startprofile;
startprofile = profile;
[gamecode] Be more informative with function calls PR_EnterFunction and PR_LeaveFunction now print the entered/left/returned function when tracing. Makes debugging obj code much easier.
2020-03-24 04:24:55 +00:00
PR_LeaveFunction (pr, pr->pr_depth == exitdepth);
pr_xstatement now always reflects the currently executing statement making debugging easier in the event of a segfault
2002-10-22 15:07:54 +00:00
st = pr->pr_statements + pr->pr_xstatement;
Move the signal handling code from video/targets/* to sys.c (I'm leaving the SDL target files for Despair since he's working on the currently). Also make progs segfault handling much more robust (and general: sigill etc too:)
2002-08-20 23:04:57 +00:00
if (pr->pr_depth == exitdepth) {
make a common call function and fix pr_trace such that it autoclears only when the execution session it's set in is exited This is an imperfect revision of history.
2004-11-07 03:00:00 +00:00
if (pr->pr_trace && pr->pr_depth <= pr->pr_trace_depth)
pr->pr_trace = false;
Allow Sys_Error to be hooked. This makes debugging builtins that wrap normal functions a little easier by giving a progs dump when such an error occurs.
2016-01-03 14:04:00 +00:00
// all done
goto exit_program;
Move the signal handling code from video/targets/* to sys.c (I'm leaving the SDL target files for Despair since he's working on the currently). Also make progs segfault handling much more robust (and general: sigill etc too:)
2002-08-20 23:04:57 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STATE_v6p:
Rewrite edict access. The server edict arrays are now stored outside of progs memory, only the entity data itself (ie data accessible to progs via ent.fld) is stored in progs memory. Many of the changes were due to code accessing edicts and entity fields directly rather than through the provided macros.
2013-01-17 05:11:54 +00:00
{
int self = *pr->globals.self;
[gamecode] Clean up state imlementations This makes the code easier to read. Also, yay for automated tests: caught a mistyped time :)
2021-07-15 07:55:02 +00:00
int nextthink = pr->fields.nextthink + self;
int frame = pr->fields.frame + self;
int think = pr->fields.think + self;
[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
float time = *pr->globals.ftime + 0.1;
[gamecode] Clean up state imlementations This makes the code easier to read. Also, yay for automated tests: caught a mistyped time :)
2021-07-15 07:55:02 +00:00
pr->pr_edict_area[nextthink].float_var = time;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
pr->pr_edict_area[frame].float_var = OPA(float);
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pr->pr_edict_area[think].func_var = OPB(func);
Rewrite edict access. The server edict arrays are now stored outside of progs memory, only the entity data itself (ie data accessible to progs via ent.fld) is stored in progs memory. Many of the changes were due to code accessing edicts and entity fields directly rather than through the provided macros.
2013-01-17 05:11:54 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_STATE_F_v6p:
Rewrite edict access. The server edict arrays are now stored outside of progs memory, only the entity data itself (ie data accessible to progs via ent.fld) is stored in progs memory. Many of the changes were due to code accessing edicts and entity fields directly rather than through the provided macros.
2013-01-17 05:11:54 +00:00
{
int self = *pr->globals.self;
[gamecode] Clean up state imlementations This makes the code easier to read. Also, yay for automated tests: caught a mistyped time :)
2021-07-15 07:55:02 +00:00
int nextthink = pr->fields.nextthink + self;
int frame = pr->fields.frame + self;
int think = pr->fields.think + self;
[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
float time = *pr->globals.ftime + OPC(float);
[gamecode] Clean up state imlementations This makes the code easier to read. Also, yay for automated tests: caught a mistyped time :)
2021-07-15 07:55:02 +00:00
pr->pr_edict_area[nextthink].float_var = time;
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
pr->pr_edict_area[frame].float_var = OPA(float);
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pr->pr_edict_area[think].func_var = OPB(func);
Rewrite edict access. The server edict arrays are now stored outside of progs memory, only the entity data itself (ie data accessible to progs via ent.fld) is stored in progs memory. Many of the changes were due to code accessing edicts and entity fields directly rather than through the provided macros.
2013-01-17 05:11:54 +00:00
}
new opcode: state.f. same as state, but takes a 3rd float operand to specify the step for calculating nextthink. accessed using [frame, think, step] (state is [frame, think])
2004-02-11 01:43:33 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_ADD_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) + OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_SUB_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) - OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MUL_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) * OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_DIV_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) / OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MOD_I_v6p:
Implement true modulo in the engine
2020-02-16 02:53:56 +00:00
{
// implement true modulo for integers:
// 5 mod 3 = 2
// -5 mod 3 = 1
// 5 mod -3 = -1
// -5 mod -3 = -2
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
int a = OPA(int);
int b = OPB(int);
Implement true modulo in the engine
2020-02-16 02:53:56 +00:00
int c = a % b;
// % is really remainder and so has the same sign rules
// as division: -5 % 3 = -2, so need to add b (3 here)
// if c's sign is incorrect, but only if c is non-zero
int mask = (a ^ b) >> 31;
Make gcc accept the bitwise-boolean magic Forgot to compile check...
2020-02-16 03:08:08 +00:00
mask &= ~(!!c + 0) + 1; // +0 to convert bool to int (gcc)
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = c + (mask & b);
Implement true modulo in the engine
2020-02-16 02:53:56 +00:00
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_REM_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) % OPB(int);
got a few new operators for qc :) << >> % which all act like their C counterparts += -= *= /= &= ^= |= <<= >>= %= which just expand into the obvious, also like the C versions.
2001-08-10 16:17:00 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MOD_D_v6p:
Implement true modulo in the engine
2020-02-16 02:53:56 +00:00
{
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
double a = OPA(double);
double b = OPB(double);
Implement true modulo in the engine
2020-02-16 02:53:56 +00:00
// floating point modulo is so much easier :P
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = a - b * floor (a / b);
Implement true modulo in the engine
2020-02-16 02:53:56 +00:00
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_REM_D_v6p:
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
{
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
double a = OPA(double);
double b = OPB(double);
OPC(double) = a - b * trunc (a / b);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MOD_F_v6p:
Implement true modulo in the engine
2020-02-16 02:53:56 +00:00
{
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
float a = OPA(float);
float b = OPB(float);
OPC(float) = a - b * floorf (a / b);
Implement true modulo in the engine
2020-02-16 02:53:56 +00:00
}
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_REM_F_v6p:
Don't truncat float % float This allows full usage, eg, x % pi, but otherwise maintains compatibility with integer %
2020-02-14 04:54:26 +00:00
{
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
float a = OPA(float);
float b = OPB(float);
OPC(float) = a - b * truncf (a / b);
Don't truncat float % float This allows full usage, eg, x % pi, but otherwise maintains compatibility with integer %
2020-02-14 04:54:26 +00:00
}
got a few new operators for qc :) << >> % which all act like their C counterparts += -= *= /= &= ^= |= <<= >>= %= which just expand into the obvious, also like the C versions.
2001-08-10 16:17:00 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_CONV_IF_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_CONV_FI_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(float);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BITAND_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) & OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BITOR_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) | OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BITXOR_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) ^ OPB(int);
^ and ~ operators for qc (^ from Rhamphoryncus) and clean up the punctuation line in qc-lex.l (why didn't I think to do that in the first place?!?)
2001-08-09 16:34:46 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BITNOT_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = ~OPA(int);
^ and ~ operators for qc (^ from Rhamphoryncus) and clean up the punctuation line in qc-lex.l (why didn't I think to do that in the first place?!?)
2001-08-09 16:34:46 +00:00
break;
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GE_I_v6p:
case OP_GE_P_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) >= OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GE_U_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(uint) >= OPB(uint);
fix the unsigned comparison opcodes
2003-08-24 05:53:15 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LE_I_v6p:
case OP_LE_P_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) <= OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LE_U_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(uint) <= OPB(uint);
fix the unsigned comparison opcodes
2003-08-24 05:53:15 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GT_I_v6p:
case OP_GT_P_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) > OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GT_U_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(uint) > OPB(uint);
fix the unsigned comparison opcodes
2003-08-24 05:53:15 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LT_I_v6p:
case OP_LT_P_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) < OPB(int);
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LT_U_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(uint) < OPB(uint);
fix the unsigned comparison opcodes
2003-08-24 05:53:15 +00:00
break;
pr_comp.h: o add ev_uniteger to the types enum o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui progs.h: o add uinteger accessors pr_exec.c: o implement ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui pr_opcode.c: o add opcodes for ifbe, ifb, ifae, ifa, jump, lt.ui, gt.ui, le.ui, ge.ui expr.h: o prototype inc_users qfcc.h: o add externs for op_ifbe, op_ifb, op_ifae and op_ifa emit.c: o don't bother emiting an assignment to a temp def that's only used once (ie, it's never read, only written to) o support the new if* instructions expr.c: o support the new if* insructions o dectect expression loops in append_expr o support unsigned integers o re-work temp def usage counting pr_def.c o debugging for temp def usage counts pr_opcode.c: o support the new if* instructions qc-parse.y: o provide defines for IFBE IFB IFAE IFA switch.c: o do binary searches for strings, floats and ints if there are more than 8 cases in a switch. Strings need more testing.
2001-11-09 00:58:16 +00:00
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_AND_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) && OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_OR_I_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) || OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NOT_I_v6p:
case OP_NOT_P_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = !OPA(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_EQ_I_v6p:
case OP_EQ_P_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) == OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NE_I_v6p:
case OP_NE_P_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(int) != OPB(int);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MOVEI_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
memmove (op_c, op_a, st->b * 4);
two new instructions: move and movep: basicly memmove. qfcc support coming as soon as I get it working :)
2002-10-16 06:44:41 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MOVEP_v6p:
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
PR_BoundsCheckSize (pr, OPC(ptr), OPB(uint));
PR_BoundsCheckSize (pr, OPA(ptr), OPB(uint));
implement bounds checking on all opcodes
2010-01-13 06:19:50 +00:00
}
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
memmove (pr->pr_globals + OPC(ptr),
pr->pr_globals + OPA(ptr),
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPB(uint) * 4);
two new instructions: move and movep: basicly memmove. qfcc support coming as soon as I get it working :)
2002-10-16 06:44:41 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MOVEPI_v6p:
Add a movepi instruction to support indirect moves of fixed size.
2011-03-09 01:29:24 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
PR_BoundsCheckSize (pr, OPC(ptr), st->b);
PR_BoundsCheckSize (pr, OPA(ptr), st->b);
Add a movepi instruction to support indirect moves of fixed size.
2011-03-09 01:29:24 +00:00
}
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
memmove (pr->pr_globals + OPC(ptr),
pr->pr_globals + OPA(ptr),
Add a movepi instruction to support indirect moves of fixed size.
2011-03-09 01:29:24 +00:00
st->b * 4);
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MEMSETI_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pr_memset (op_c, OPA(ptr), st->b);
[gamecode] Rework implementation of memset* The memset instructions now match the move* instructions other than the first operand (always int). Probably breaks much, but fixed in next few commits.
2020-03-13 08:50:57 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MEMSETP_v6p:
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
PR_BoundsCheckSize (pr, OPC(ptr), OPB(uint));
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
}
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_memset (pr->pr_globals + OPC(ptr), OPA(int),
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
OPB(uint));
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_MEMSETPI_v6p:
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
if (pr_boundscheck->int_val) {
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
PR_BoundsCheckSize (pr, OPC(ptr), st->b);
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
}
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_memset (pr->pr_globals + OPC(ptr), OPA(int),
[gamecode] Add memset instructions
2020-03-11 13:48:55 +00:00
st->b);
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GE_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(double) >= OPB(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LE_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(double) <= OPB(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_GT_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(double) > OPB(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_LT_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(double) < OPB(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NOT_D_v6p:
[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
OPC(int) = (op_a[0].int_var
|| (op_a[1].int_var & ~0x80000000u));
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_EQ_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(double) == OPB(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_NE_D_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(double) != OPB(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_CONV_ID_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = OPA(int);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_CONV_DI_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(int) = OPA(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_CONV_FD_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(double) = OPA(float);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_CONV_DF_v6p:
[gamecode] Switch to using type parameter op macros I wish I'd done it this way years ago (but maybe gcc 2.95 couldn't hack the casts, I do know there were aliasing problems in the past). Anyway, this makes operand access much more consistent for variable sized operands (eg float vs double vs vec4), and is a big part of the new instruction set implementation.
2022-01-02 11:46:32 +00:00
OPC(float) = OPA(double);
Add support for doubles to Ruamoko Only as scalars, I still need to think about what to do for vectors and quaternions due to param size issues. Also, doubles are not yet guaranteed to be correctly aligned.
2020-02-14 07:38:37 +00:00
break;
two new instructions: move and movep: basicly memmove. qfcc support coming as soon as I get it working :)
2002-10-16 06:44:41 +00:00
Initial integer type support. qfcc /is/ partially broken when it comes to integer constants and float function args/return values. pr_comp.h: o add the integer opcodes to pr_opcode_e pr_edict.c: o add "quaternion" and "integer" to type_name[] o support quatnernion and integers types when printing values o support the integer opcodes when bounds checking pr_exec.c o enable the integer opcodes pr_opcode: o add the integer opcodes to the opcode table o logical operators all result in an integer rather than a value expr.h: o rename int_val to integer_val qfcc.h: o kill another magic number expr.c: o move the opcode to string conversion out of type_mismatch and into get_op_string o rename int_val to integer_val o general integer type support. o generate an internal comipiler error for null opcodes rather than segging. pr_imm.c: o rename int_val to integer_val o support integer constants, converting to float when needed. pr_lex.c: o magic number death and support quaternions and integers in type_size[] qc-lex.l o rename int_val to integer_val o support quaternion and integer type keywords qc-parse.y: o rename int_val to integer_val o use binary_expr instead of new_binary_expr for local initialized variables builtins.c: o rename int_val to integer_val o fix most (all?) of the INT related FIXMEs defs.qc: o use integer instead of float where it makes sense main.c: o read_result is now integer rather than float main.qc: o float -> integer where appropriate o new test for int const to float arg
2001-07-23 01:31:22 +00:00
// LordHavoc: to be enabled when Progs version 7 (or whatever it will be numbered) is finalized
/*
[gamecode] Rename the old opcodes To reflect their basis on v6 progs instructions, they sport the v6p tag where the p is for "plus" due to the QuakeForge extensions.
2022-01-02 12:06:14 +00:00
case OP_BOUNDCHECK_v6p:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
if (OPA(ptr) >= st->b) {
Whitespace.
2001-09-10 12:56:23 +00:00
PR_RunError (pr, "Progs boundcheck failed at line number "
search for `.self' before `self'
2002-05-18 00:49:16 +00:00
"%d, value is < 0 or >= %d", st->b, st->c);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
break;
*/
default:
[gamecode] Create a mask for extracting the opcode Got tired of copying the full thing around.
2022-01-03 08:54:54 +00:00
PR_RunError (pr, "Bad opcode %i", st->op & ~OP_BREAK);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
[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
if (pr->watch && pr->watch->int_var != old_val.int_var) {
[gamecode] Improve watchpoint handling a little Mostly just update the old value if the condition didn't trigger.
2020-03-24 04:26:35 +00:00
if (!pr->wp_conditional
[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
|| pr->watch->int_var == pr->wp_val.int_var) {
[gamecode] Add debug hooks to the VM engine While there was a breakpoint hook, it was for only breakpoints and more was needed. Now there's a generic hook that is called for tracing, breakpoints, watch points, runtime errors and VM errors, with the "event" type passed as the first parameter and a data pointer in the second.
2020-03-24 06:35:42 +00:00
if (pr->debug_handler) {
[gamecode] Add a param pointer to debug_handler I decided I want events for VM enter/exit but enter needs to somehow pass the function which will be executed (even if a builtin). A generic void * param seemed the best idea, which meant the error string could be passed via the param instead of a "global" string in the progs struct.
2020-03-26 02:44:02 +00:00
pr->debug_handler (prd_watchpoint, 0, pr->debug_data);
[gamecode] Add debug hooks to the VM engine While there was a breakpoint hook, it was for only breakpoints and more was needed. Now there's a generic hook that is called for tracing, breakpoints, watch points, runtime errors and VM errors, with the "event" type passed as the first parameter and a data pointer in the second.
2020-03-24 06:35:42 +00:00
} else {
PR_RunError (pr, "watchpoint hit: %d -> %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
old_val.int_var, pr->watch->int_var);
[gamecode] Add debug hooks to the VM engine While there was a breakpoint hook, it was for only breakpoints and more was needed. Now there's a generic hook that is called for tracing, breakpoints, watch points, runtime errors and VM errors, with the "event" type passed as the first parameter and a data pointer in the second.
2020-03-24 06:35:42 +00:00
}
[gamecode] Improve watchpoint handling a little Mostly just update the old value if the condition didn't trigger.
2020-03-24 04:26:35 +00:00
}
[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
old_val.int_var = pr->watch->int_var;
[gamecode] Improve watchpoint handling a little Mostly just update the old value if the condition didn't trigger.
2020-03-24 04:26:35 +00:00
}
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
[gamecode] Split out the old quake c execution loop There is no reasonable way (due to hardware-enforced alignment issues) to simply convert old bytecode to new (probably best done with an off-line tool, preferably just recompiling when I get qfcc up to the job), so both loops will need to be present. This just moves the original loop into its own function in order to make it easy to bring in the new (and iron out integration issues).
2022-01-02 11:16:45 +00:00
exit_program:
}
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
#define MM(type) (*((pr_##type##_t *) (mm)))
#define STK(type) (*((pr_##type##_t *) (stk)))
static pr_type_t *
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
pr_address_mode (progs_t *pr, const dstatement_t *st, int mm_ind)
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
{
pr_type_t *op_a = pr->pr_globals + st->a + PR_BASE (pr, st, A);
[gamecode] Fix a pile of incorrect base register refs The problem with copying code is it's all to easy to forget to make all necessary edits.
2022-01-04 10:01:05 +00:00
pr_type_t *op_b = pr->pr_globals + st->b + PR_BASE (pr, st, B);
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t mm_offs = 0;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
switch (mm_ind) {
case 0:
// regular global access
mm_offs = op_a - pr->pr_globals;
break;
case 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
// entity.field (equivalent to OP_LOAD_t_v6p)
pr_ptr_t edict_area = pr->pr_edict_area - pr->pr_globals;
mm_offs = edict_area + OPA(entity) + OPB(field);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
case 2:
[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
// constant indexed pointer: *a + b (supports -ve offset)
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
mm_offs = OPA(ptr) + (short) st->b;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
case 3:
[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
// variable indexed pointer: *a + *b (supports -ve offset)
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
mm_offs = OPA(ptr) + OPB(int);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
}
return pr->pr_globals + mm_offs;
}
[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
static pr_type_t *
pr_call_mode (progs_t *pr, const dstatement_t *st, int mm_ind)
{
pr_type_t *op_a = pr->pr_globals + st->a + PR_BASE (pr, st, A);
pr_type_t *op_b = pr->pr_globals + st->b + PR_BASE (pr, st, B);
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t mm_offs = 0;
[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
switch (mm_ind) {
case 1:
// regular global access
mm_offs = op_a - pr->pr_globals;
break;
case 2:
// constant indexed pointer: *a + b (supports -ve offset)
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
mm_offs = OPA(ptr) + (short) st->b;
[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
break;
case 3:
// variable indexed pointer: *a + *b (supports -ve offset)
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
mm_offs = OPA(ptr) + OPB(int);
[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
break;
case 4:
// entity.field (equivalent to OP_LOAD_t_v6p)
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t edict_area = pr->pr_edict_area - pr->pr_globals;
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
mm_offs = edict_area + OPA(entity) + OPB(field);
[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
break;
}
return pr->pr_globals + mm_offs;
}
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
static pr_ptr_t __attribute__((pure))
[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
pr_jump_mode (progs_t *pr, const dstatement_t *st, int jump_ind)
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
{
pr_type_t *op_a = pr->pr_globals + st->a + PR_BASE (pr, st, A);
[gamecode] Fix a pile of incorrect base register refs The problem with copying code is it's all to easy to forget to make all necessary edits.
2022-01-04 10:01:05 +00:00
pr_type_t *op_b = pr->pr_globals + st->b + PR_BASE (pr, st, B);
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t jump_offs = pr->pr_xstatement;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
switch (jump_ind) {
case 0:
// instruction relative offset
[gamecode] Fix relative offset jumps Yet another missed sign extension.
2022-01-04 05:30:20 +00:00
jump_offs = jump_offs + (short) st->a;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
case 1:
[gamecode] Redesign jump's B addressing Yet another redundant addressing mode (since ptr + 0 can be used), so replace it with a variable-indexed array (same as in v6p). Was forced into noticing the problem when trying to compile Machine.r.
2022-01-30 13:34:40 +00:00
// variable indexed array: a + *b (only +ve)
jump_offs = (op_a + OPB(uint))->uint_var;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
case 2:
[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
// constant indexed pointer: *a + b (supports -ve offset)
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
jump_offs = OPA(ptr) + (short) st->b;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
case 3:
[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
// variable indexed pointer: *a + *b (supports -ve offset)
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
jump_offs = OPA(ptr) + OPB(int);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
}
[gamecode] Use a struct for offset/count pairs This cleans up dprograms_t, making it easier to read and see what chunks are in it (I was surprised to see only 6, the explicit pairs made it seem to have more).
2022-01-26 10:30:25 +00:00
if (pr_boundscheck->int_val && jump_offs >= pr->progs->statements.count) {
[gamecode] Add statement bounds checking Statements can be bounds checked in the one place (jump calculation), but memory accesses cannot as they can be used in lea instructions which should never cause an exception (unless one of lea's operands is OOB).
2022-01-04 08:53:10 +00:00
PR_RunError (pr, "out of bounds: %x", jump_offs);
}
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
return jump_offs - 1; // for st++
}
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
static pr_type_t *
pr_stack_push (progs_t *pr)
{
// keep the stack 16-byte aligned
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack - 4;
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
pr_type_t *stk = pr->pr_globals + stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 4);
}
*pr->globals.stack = stack;
return stk;
}
static pr_type_t *
pr_stack_pop (progs_t *pr)
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t stack = *pr->globals.stack;
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
pr_type_t *stk = pr->pr_globals + stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack, 4);
}
// keep the stack 16-byte aligned
*pr->globals.stack = stack + 4;
return stk;
}
[gamecode] Initialize .stack if it's available And implement bounds checks for adjstk.
2022-01-21 11:33:15 +00:00
static void
pr_stack_adjust (progs_t *pr, int mode, int offset)
{
// keep the stack 16-byte aligned
if (mode || (offset & 3)) {
PR_RunError (pr, "invalid stack adjustment: %d, %d", mode, offset);
}
pr_ptr_t stack = *pr->globals.stack;
if (pr_boundscheck->int_val) {
check_stack_pointer (pr, stack + offset, 0);
}
*pr->globals.stack = stack + offset;
}
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
static void
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
pr_with (progs_t *pr, const dstatement_t *st)
{
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t edict_area = pr->pr_edict_area - pr->pr_globals;
[gamecode] Add more modes to WITH It turned out I had no way of using a pointer or field as the value to load, so all 4 modes are duplicated with loads from where operand b points, but the loaded value interpreted the same way. Also, fixed an error in the calculation of op-b offsets.
2022-01-04 08:55:20 +00:00
pr_type_t *op_b = pr->pr_globals + PR_BASE (pr, st, B) + st->b;
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
pr_type_t *stk;
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
pr_uint_t *base = &pr->pr_bases[st->c & 3];
[gamecode] Add more modes to WITH It turned out I had no way of using a pointer or field as the value to load, so all 4 modes are duplicated with loads from where operand b points, but the loaded value interpreted the same way. Also, fixed an error in the calculation of op-b offsets.
2022-01-04 08:55:20 +00:00
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
switch (st->a) {
[gamecode] Add more modes to WITH It turned out I had no way of using a pointer or field as the value to load, so all 4 modes are duplicated with loads from where operand b points, but the loaded value interpreted the same way. Also, fixed an error in the calculation of op-b offsets.
2022-01-04 08:55:20 +00:00
// fixed offset
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
case 0:
// hard-0 base
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
*base = st->b;
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
return;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
case 1:
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
// relative to current base (-ve offset)
*base = PR_BASE (pr, st, B) + (pr_short_t) st->b;
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
return;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
case 2:
// relative to stack (-ve offset)
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
*base = *pr->globals.stack + (pr_short_t) st->b;
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
return;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
case 3:
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
// relative to edict_area (only +ve)
*base = edict_area + st->b;
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
return;
[gamecode] Add more modes to WITH It turned out I had no way of using a pointer or field as the value to load, so all 4 modes are duplicated with loads from where operand b points, but the loaded value interpreted the same way. Also, fixed an error in the calculation of op-b offsets.
2022-01-04 08:55:20 +00:00
case 4:
// hard-0 base
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
*base = pr->pr_globals[st->b].pointer_var;
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
return;
[gamecode] Add more modes to WITH It turned out I had no way of using a pointer or field as the value to load, so all 4 modes are duplicated with loads from where operand b points, but the loaded value interpreted the same way. Also, fixed an error in the calculation of op-b offsets.
2022-01-04 08:55:20 +00:00
case 5:
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
*base = OPB(ptr);
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
return;
[gamecode] Add more modes to WITH It turned out I had no way of using a pointer or field as the value to load, so all 4 modes are duplicated with loads from where operand b points, but the loaded value interpreted the same way. Also, fixed an error in the calculation of op-b offsets.
2022-01-04 08:55:20 +00:00
case 6:
// relative to stack (-ve offset)
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
*base = *pr->globals.stack + OPB(int);
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
return;
[gamecode] Add more modes to WITH It turned out I had no way of using a pointer or field as the value to load, so all 4 modes are duplicated with loads from where operand b points, but the loaded value interpreted the same way. Also, fixed an error in the calculation of op-b offsets.
2022-01-04 08:55:20 +00:00
case 7:
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
// relative to edict_area (only +ve)
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
*base = edict_area + OPB(field);
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
return;
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
case 8:
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
// pushregs
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
stk = pr_stack_push (pr);
STK(uivec4) = pr->pr_bases;
return;
case 9:
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
// popregs
[gamecode] Move pushregs and popregs into with This frees up another two instructions.
2022-01-15 07:51:59 +00:00
stk = pr_stack_pop (pr);
pr->pr_bases = STK(uivec4);
return;
[gamecode] Add tests for the with instruction(s) While mode 4 was tested a lot, none of the rest were. Also added a full reset instruction.
2022-01-15 09:44:11 +00:00
case 10:
// reset
pr->pr_bases = (pr_uivec4_t) {};
return;
[gamecode] Add "return pointer" mode to with instruction This loads the current return pointer into the specified register. No offset is used (should make that an error, but for now any offset is simply ignored). This is part of the fix for getting obj_msg_sendv to work with return values.
2022-02-05 09:42:54 +00:00
case 11:
// return pointer
*base = pr->pr_return - pr->pr_globals;
return;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
}
PR_RunError (pr, "Invalid with index: %u", st->a);
}
[gamecode] Implement 4-component 32-bit swizzle The swizzle instruction is very powerful in that in can do any of the 256 permutations of xyzw, optionally negate any combination of the resulting components, and zero any combination of the result components (even all). This means the one instruction can take care of any actual swizzles, conjugation for complex and quaternion values, zeroing vectors (not that it's the only way), and probably other weird things. The python file was used to generate the jump table and actual swizzle code.
2022-01-03 10:30:32 +00:00
static pr_ivec4_t
pr_swizzle_f (pr_ivec4_t vec, pr_ushort_t swiz)
{
goto do_swizzle;
#define swizzle __builtin_shuffle
swizzle_xxxx: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 0, 0 }); goto negate;
swizzle_yxxx: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 0, 0 }); goto negate;
swizzle_zxxx: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 0, 0 }); goto negate;
swizzle_wxxx: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 0, 0 }); goto negate;
swizzle_xyxx: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 0, 0 }); goto negate;
swizzle_yyxx: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 0, 0 }); goto negate;
swizzle_zyxx: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 0, 0 }); goto negate;
swizzle_wyxx: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 0, 0 }); goto negate;
swizzle_xzxx: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 0, 0 }); goto negate;
swizzle_yzxx: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 0, 0 }); goto negate;
swizzle_zzxx: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 0, 0 }); goto negate;
swizzle_wzxx: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 0, 0 }); goto negate;
swizzle_xwxx: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 0, 0 }); goto negate;
swizzle_ywxx: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 0, 0 }); goto negate;
swizzle_zwxx: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 0, 0 }); goto negate;
swizzle_wwxx: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 0, 0 }); goto negate;
swizzle_xxyx: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 1, 0 }); goto negate;
swizzle_yxyx: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 1, 0 }); goto negate;
swizzle_zxyx: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 1, 0 }); goto negate;
swizzle_wxyx: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 1, 0 }); goto negate;
swizzle_xyyx: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 1, 0 }); goto negate;
swizzle_yyyx: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 1, 0 }); goto negate;
swizzle_zyyx: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 1, 0 }); goto negate;
swizzle_wyyx: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 1, 0 }); goto negate;
swizzle_xzyx: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 1, 0 }); goto negate;
swizzle_yzyx: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 1, 0 }); goto negate;
swizzle_zzyx: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 1, 0 }); goto negate;
swizzle_wzyx: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 1, 0 }); goto negate;
swizzle_xwyx: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 1, 0 }); goto negate;
swizzle_ywyx: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 1, 0 }); goto negate;
swizzle_zwyx: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 1, 0 }); goto negate;
swizzle_wwyx: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 1, 0 }); goto negate;
swizzle_xxzx: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 2, 0 }); goto negate;
swizzle_yxzx: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 2, 0 }); goto negate;
swizzle_zxzx: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 2, 0 }); goto negate;
swizzle_wxzx: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 2, 0 }); goto negate;
swizzle_xyzx: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 2, 0 }); goto negate;
swizzle_yyzx: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 2, 0 }); goto negate;
swizzle_zyzx: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 2, 0 }); goto negate;
swizzle_wyzx: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 2, 0 }); goto negate;
swizzle_xzzx: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 2, 0 }); goto negate;
swizzle_yzzx: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 2, 0 }); goto negate;
swizzle_zzzx: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 2, 0 }); goto negate;
swizzle_wzzx: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 2, 0 }); goto negate;
swizzle_xwzx: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 2, 0 }); goto negate;
swizzle_ywzx: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 2, 0 }); goto negate;
swizzle_zwzx: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 2, 0 }); goto negate;
swizzle_wwzx: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 2, 0 }); goto negate;
swizzle_xxwx: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 3, 0 }); goto negate;
swizzle_yxwx: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 3, 0 }); goto negate;
swizzle_zxwx: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 3, 0 }); goto negate;
swizzle_wxwx: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 3, 0 }); goto negate;
swizzle_xywx: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 3, 0 }); goto negate;
swizzle_yywx: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 3, 0 }); goto negate;
swizzle_zywx: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 3, 0 }); goto negate;
swizzle_wywx: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 3, 0 }); goto negate;
swizzle_xzwx: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 3, 0 }); goto negate;
swizzle_yzwx: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 3, 0 }); goto negate;
swizzle_zzwx: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 3, 0 }); goto negate;
swizzle_wzwx: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 3, 0 }); goto negate;
swizzle_xwwx: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 3, 0 }); goto negate;
swizzle_ywwx: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 3, 0 }); goto negate;
swizzle_zwwx: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 3, 0 }); goto negate;
swizzle_wwwx: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 3, 0 }); goto negate;
swizzle_xxxy: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 0, 1 }); goto negate;
swizzle_yxxy: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 0, 1 }); goto negate;
swizzle_zxxy: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 0, 1 }); goto negate;
swizzle_wxxy: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 0, 1 }); goto negate;
swizzle_xyxy: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 0, 1 }); goto negate;
swizzle_yyxy: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 0, 1 }); goto negate;
swizzle_zyxy: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 0, 1 }); goto negate;
swizzle_wyxy: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 0, 1 }); goto negate;
swizzle_xzxy: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 0, 1 }); goto negate;
swizzle_yzxy: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 0, 1 }); goto negate;
swizzle_zzxy: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 0, 1 }); goto negate;
swizzle_wzxy: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 0, 1 }); goto negate;
swizzle_xwxy: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 0, 1 }); goto negate;
swizzle_ywxy: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 0, 1 }); goto negate;
swizzle_zwxy: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 0, 1 }); goto negate;
swizzle_wwxy: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 0, 1 }); goto negate;
swizzle_xxyy: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 1, 1 }); goto negate;
swizzle_yxyy: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 1, 1 }); goto negate;
swizzle_zxyy: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 1, 1 }); goto negate;
swizzle_wxyy: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 1, 1 }); goto negate;
swizzle_xyyy: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 1, 1 }); goto negate;
swizzle_yyyy: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 1, 1 }); goto negate;
swizzle_zyyy: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 1, 1 }); goto negate;
swizzle_wyyy: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 1, 1 }); goto negate;
swizzle_xzyy: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 1, 1 }); goto negate;
swizzle_yzyy: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 1, 1 }); goto negate;
swizzle_zzyy: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 1, 1 }); goto negate;
swizzle_wzyy: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 1, 1 }); goto negate;
swizzle_xwyy: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 1, 1 }); goto negate;
swizzle_ywyy: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 1, 1 }); goto negate;
swizzle_zwyy: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 1, 1 }); goto negate;
swizzle_wwyy: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 1, 1 }); goto negate;
swizzle_xxzy: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 2, 1 }); goto negate;
swizzle_yxzy: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 2, 1 }); goto negate;
swizzle_zxzy: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 2, 1 }); goto negate;
swizzle_wxzy: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 2, 1 }); goto negate;
swizzle_xyzy: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 2, 1 }); goto negate;
swizzle_yyzy: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 2, 1 }); goto negate;
swizzle_zyzy: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 2, 1 }); goto negate;
swizzle_wyzy: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 2, 1 }); goto negate;
swizzle_xzzy: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 2, 1 }); goto negate;
swizzle_yzzy: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 2, 1 }); goto negate;
swizzle_zzzy: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 2, 1 }); goto negate;
swizzle_wzzy: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 2, 1 }); goto negate;
swizzle_xwzy: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 2, 1 }); goto negate;
swizzle_ywzy: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 2, 1 }); goto negate;
swizzle_zwzy: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 2, 1 }); goto negate;
swizzle_wwzy: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 2, 1 }); goto negate;
swizzle_xxwy: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 3, 1 }); goto negate;
swizzle_yxwy: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 3, 1 }); goto negate;
swizzle_zxwy: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 3, 1 }); goto negate;
swizzle_wxwy: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 3, 1 }); goto negate;
swizzle_xywy: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 3, 1 }); goto negate;
swizzle_yywy: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 3, 1 }); goto negate;
swizzle_zywy: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 3, 1 }); goto negate;
swizzle_wywy: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 3, 1 }); goto negate;
swizzle_xzwy: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 3, 1 }); goto negate;
swizzle_yzwy: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 3, 1 }); goto negate;
swizzle_zzwy: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 3, 1 }); goto negate;
swizzle_wzwy: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 3, 1 }); goto negate;
swizzle_xwwy: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 3, 1 }); goto negate;
swizzle_ywwy: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 3, 1 }); goto negate;
swizzle_zwwy: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 3, 1 }); goto negate;
swizzle_wwwy: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 3, 1 }); goto negate;
swizzle_xxxz: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 0, 2 }); goto negate;
swizzle_yxxz: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 0, 2 }); goto negate;
swizzle_zxxz: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 0, 2 }); goto negate;
swizzle_wxxz: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 0, 2 }); goto negate;
swizzle_xyxz: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 0, 2 }); goto negate;
swizzle_yyxz: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 0, 2 }); goto negate;
swizzle_zyxz: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 0, 2 }); goto negate;
swizzle_wyxz: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 0, 2 }); goto negate;
swizzle_xzxz: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 0, 2 }); goto negate;
swizzle_yzxz: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 0, 2 }); goto negate;
swizzle_zzxz: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 0, 2 }); goto negate;
swizzle_wzxz: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 0, 2 }); goto negate;
swizzle_xwxz: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 0, 2 }); goto negate;
swizzle_ywxz: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 0, 2 }); goto negate;
swizzle_zwxz: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 0, 2 }); goto negate;
swizzle_wwxz: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 0, 2 }); goto negate;
swizzle_xxyz: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 1, 2 }); goto negate;
swizzle_yxyz: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 1, 2 }); goto negate;
swizzle_zxyz: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 1, 2 }); goto negate;
swizzle_wxyz: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 1, 2 }); goto negate;
swizzle_xyyz: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 1, 2 }); goto negate;
swizzle_yyyz: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 1, 2 }); goto negate;
swizzle_zyyz: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 1, 2 }); goto negate;
swizzle_wyyz: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 1, 2 }); goto negate;
swizzle_xzyz: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 1, 2 }); goto negate;
swizzle_yzyz: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 1, 2 }); goto negate;
swizzle_zzyz: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 1, 2 }); goto negate;
swizzle_wzyz: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 1, 2 }); goto negate;
swizzle_xwyz: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 1, 2 }); goto negate;
swizzle_ywyz: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 1, 2 }); goto negate;
swizzle_zwyz: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 1, 2 }); goto negate;
swizzle_wwyz: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 1, 2 }); goto negate;
swizzle_xxzz: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 2, 2 }); goto negate;
swizzle_yxzz: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 2, 2 }); goto negate;
swizzle_zxzz: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 2, 2 }); goto negate;
swizzle_wxzz: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 2, 2 }); goto negate;
swizzle_xyzz: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 2, 2 }); goto negate;
swizzle_yyzz: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 2, 2 }); goto negate;
swizzle_zyzz: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 2, 2 }); goto negate;
swizzle_wyzz: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 2, 2 }); goto negate;
swizzle_xzzz: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 2, 2 }); goto negate;
swizzle_yzzz: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 2, 2 }); goto negate;
swizzle_zzzz: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 2, 2 }); goto negate;
swizzle_wzzz: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 2, 2 }); goto negate;
swizzle_xwzz: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 2, 2 }); goto negate;
swizzle_ywzz: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 2, 2 }); goto negate;
swizzle_zwzz: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 2, 2 }); goto negate;
swizzle_wwzz: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 2, 2 }); goto negate;
swizzle_xxwz: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 3, 2 }); goto negate;
swizzle_yxwz: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 3, 2 }); goto negate;
swizzle_zxwz: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 3, 2 }); goto negate;
swizzle_wxwz: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 3, 2 }); goto negate;
swizzle_xywz: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 3, 2 }); goto negate;
swizzle_yywz: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 3, 2 }); goto negate;
swizzle_zywz: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 3, 2 }); goto negate;
swizzle_wywz: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 3, 2 }); goto negate;
swizzle_xzwz: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 3, 2 }); goto negate;
swizzle_yzwz: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 3, 2 }); goto negate;
swizzle_zzwz: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 3, 2 }); goto negate;
swizzle_wzwz: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 3, 2 }); goto negate;
swizzle_xwwz: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 3, 2 }); goto negate;
swizzle_ywwz: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 3, 2 }); goto negate;
swizzle_zwwz: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 3, 2 }); goto negate;
swizzle_wwwz: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 3, 2 }); goto negate;
swizzle_xxxw: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 0, 3 }); goto negate;
swizzle_yxxw: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 0, 3 }); goto negate;
swizzle_zxxw: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 0, 3 }); goto negate;
swizzle_wxxw: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 0, 3 }); goto negate;
swizzle_xyxw: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 0, 3 }); goto negate;
swizzle_yyxw: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 0, 3 }); goto negate;
swizzle_zyxw: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 0, 3 }); goto negate;
swizzle_wyxw: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 0, 3 }); goto negate;
swizzle_xzxw: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 0, 3 }); goto negate;
swizzle_yzxw: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 0, 3 }); goto negate;
swizzle_zzxw: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 0, 3 }); goto negate;
swizzle_wzxw: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 0, 3 }); goto negate;
swizzle_xwxw: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 0, 3 }); goto negate;
swizzle_ywxw: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 0, 3 }); goto negate;
swizzle_zwxw: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 0, 3 }); goto negate;
swizzle_wwxw: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 0, 3 }); goto negate;
swizzle_xxyw: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 1, 3 }); goto negate;
swizzle_yxyw: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 1, 3 }); goto negate;
swizzle_zxyw: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 1, 3 }); goto negate;
swizzle_wxyw: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 1, 3 }); goto negate;
swizzle_xyyw: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 1, 3 }); goto negate;
swizzle_yyyw: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 1, 3 }); goto negate;
swizzle_zyyw: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 1, 3 }); goto negate;
swizzle_wyyw: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 1, 3 }); goto negate;
swizzle_xzyw: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 1, 3 }); goto negate;
swizzle_yzyw: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 1, 3 }); goto negate;
swizzle_zzyw: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 1, 3 }); goto negate;
swizzle_wzyw: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 1, 3 }); goto negate;
swizzle_xwyw: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 1, 3 }); goto negate;
swizzle_ywyw: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 1, 3 }); goto negate;
swizzle_zwyw: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 1, 3 }); goto negate;
swizzle_wwyw: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 1, 3 }); goto negate;
swizzle_xxzw: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 2, 3 }); goto negate;
swizzle_yxzw: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 2, 3 }); goto negate;
swizzle_zxzw: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 2, 3 }); goto negate;
swizzle_wxzw: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 2, 3 }); goto negate;
swizzle_xyzw: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 2, 3 }); goto negate;
swizzle_yyzw: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 2, 3 }); goto negate;
swizzle_zyzw: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 2, 3 }); goto negate;
swizzle_wyzw: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 2, 3 }); goto negate;
swizzle_xzzw: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 2, 3 }); goto negate;
swizzle_yzzw: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 2, 3 }); goto negate;
swizzle_zzzw: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 2, 3 }); goto negate;
swizzle_wzzw: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 2, 3 }); goto negate;
swizzle_xwzw: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 2, 3 }); goto negate;
swizzle_ywzw: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 2, 3 }); goto negate;
swizzle_zwzw: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 2, 3 }); goto negate;
swizzle_wwzw: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 2, 3 }); goto negate;
swizzle_xxww: vec = swizzle (vec, (pr_ivec4_t) { 0, 0, 3, 3 }); goto negate;
swizzle_yxww: vec = swizzle (vec, (pr_ivec4_t) { 1, 0, 3, 3 }); goto negate;
swizzle_zxww: vec = swizzle (vec, (pr_ivec4_t) { 2, 0, 3, 3 }); goto negate;
swizzle_wxww: vec = swizzle (vec, (pr_ivec4_t) { 3, 0, 3, 3 }); goto negate;
swizzle_xyww: vec = swizzle (vec, (pr_ivec4_t) { 0, 1, 3, 3 }); goto negate;
swizzle_yyww: vec = swizzle (vec, (pr_ivec4_t) { 1, 1, 3, 3 }); goto negate;
swizzle_zyww: vec = swizzle (vec, (pr_ivec4_t) { 2, 1, 3, 3 }); goto negate;
swizzle_wyww: vec = swizzle (vec, (pr_ivec4_t) { 3, 1, 3, 3 }); goto negate;
swizzle_xzww: vec = swizzle (vec, (pr_ivec4_t) { 0, 2, 3, 3 }); goto negate;
swizzle_yzww: vec = swizzle (vec, (pr_ivec4_t) { 1, 2, 3, 3 }); goto negate;
swizzle_zzww: vec = swizzle (vec, (pr_ivec4_t) { 2, 2, 3, 3 }); goto negate;
swizzle_wzww: vec = swizzle (vec, (pr_ivec4_t) { 3, 2, 3, 3 }); goto negate;
swizzle_xwww: vec = swizzle (vec, (pr_ivec4_t) { 0, 3, 3, 3 }); goto negate;
swizzle_ywww: vec = swizzle (vec, (pr_ivec4_t) { 1, 3, 3, 3 }); goto negate;
swizzle_zwww: vec = swizzle (vec, (pr_ivec4_t) { 2, 3, 3, 3 }); goto negate;
swizzle_wwww: vec = swizzle (vec, (pr_ivec4_t) { 3, 3, 3, 3 }); goto negate;
static void *swizzle_table[256] = {
&&swizzle_xxxx, &&swizzle_yxxx, &&swizzle_zxxx, &&swizzle_wxxx,
&&swizzle_xyxx, &&swizzle_yyxx, &&swizzle_zyxx, &&swizzle_wyxx,
&&swizzle_xzxx, &&swizzle_yzxx, &&swizzle_zzxx, &&swizzle_wzxx,
&&swizzle_xwxx, &&swizzle_ywxx, &&swizzle_zwxx, &&swizzle_wwxx,
&&swizzle_xxyx, &&swizzle_yxyx, &&swizzle_zxyx, &&swizzle_wxyx,
&&swizzle_xyyx, &&swizzle_yyyx, &&swizzle_zyyx, &&swizzle_wyyx,
&&swizzle_xzyx, &&swizzle_yzyx, &&swizzle_zzyx, &&swizzle_wzyx,
&&swizzle_xwyx, &&swizzle_ywyx, &&swizzle_zwyx, &&swizzle_wwyx,
&&swizzle_xxzx, &&swizzle_yxzx, &&swizzle_zxzx, &&swizzle_wxzx,
&&swizzle_xyzx, &&swizzle_yyzx, &&swizzle_zyzx, &&swizzle_wyzx,
&&swizzle_xzzx, &&swizzle_yzzx, &&swizzle_zzzx, &&swizzle_wzzx,
&&swizzle_xwzx, &&swizzle_ywzx, &&swizzle_zwzx, &&swizzle_wwzx,
&&swizzle_xxwx, &&swizzle_yxwx, &&swizzle_zxwx, &&swizzle_wxwx,
&&swizzle_xywx, &&swizzle_yywx, &&swizzle_zywx, &&swizzle_wywx,
&&swizzle_xzwx, &&swizzle_yzwx, &&swizzle_zzwx, &&swizzle_wzwx,
&&swizzle_xwwx, &&swizzle_ywwx, &&swizzle_zwwx, &&swizzle_wwwx,
&&swizzle_xxxy, &&swizzle_yxxy, &&swizzle_zxxy, &&swizzle_wxxy,
&&swizzle_xyxy, &&swizzle_yyxy, &&swizzle_zyxy, &&swizzle_wyxy,
&&swizzle_xzxy, &&swizzle_yzxy, &&swizzle_zzxy, &&swizzle_wzxy,
&&swizzle_xwxy, &&swizzle_ywxy, &&swizzle_zwxy, &&swizzle_wwxy,
&&swizzle_xxyy, &&swizzle_yxyy, &&swizzle_zxyy, &&swizzle_wxyy,
&&swizzle_xyyy, &&swizzle_yyyy, &&swizzle_zyyy, &&swizzle_wyyy,
&&swizzle_xzyy, &&swizzle_yzyy, &&swizzle_zzyy, &&swizzle_wzyy,
&&swizzle_xwyy, &&swizzle_ywyy, &&swizzle_zwyy, &&swizzle_wwyy,
&&swizzle_xxzy, &&swizzle_yxzy, &&swizzle_zxzy, &&swizzle_wxzy,
&&swizzle_xyzy, &&swizzle_yyzy, &&swizzle_zyzy, &&swizzle_wyzy,
&&swizzle_xzzy, &&swizzle_yzzy, &&swizzle_zzzy, &&swizzle_wzzy,
&&swizzle_xwzy, &&swizzle_ywzy, &&swizzle_zwzy, &&swizzle_wwzy,
&&swizzle_xxwy, &&swizzle_yxwy, &&swizzle_zxwy, &&swizzle_wxwy,
&&swizzle_xywy, &&swizzle_yywy, &&swizzle_zywy, &&swizzle_wywy,
&&swizzle_xzwy, &&swizzle_yzwy, &&swizzle_zzwy, &&swizzle_wzwy,
&&swizzle_xwwy, &&swizzle_ywwy, &&swizzle_zwwy, &&swizzle_wwwy,
&&swizzle_xxxz, &&swizzle_yxxz, &&swizzle_zxxz, &&swizzle_wxxz,
&&swizzle_xyxz, &&swizzle_yyxz, &&swizzle_zyxz, &&swizzle_wyxz,
&&swizzle_xzxz, &&swizzle_yzxz, &&swizzle_zzxz, &&swizzle_wzxz,
&&swizzle_xwxz, &&swizzle_ywxz, &&swizzle_zwxz, &&swizzle_wwxz,
&&swizzle_xxyz, &&swizzle_yxyz, &&swizzle_zxyz, &&swizzle_wxyz,
&&swizzle_xyyz, &&swizzle_yyyz, &&swizzle_zyyz, &&swizzle_wyyz,
&&swizzle_xzyz, &&swizzle_yzyz, &&swizzle_zzyz, &&swizzle_wzyz,
&&swizzle_xwyz, &&swizzle_ywyz, &&swizzle_zwyz, &&swizzle_wwyz,
&&swizzle_xxzz, &&swizzle_yxzz, &&swizzle_zxzz, &&swizzle_wxzz,
&&swizzle_xyzz, &&swizzle_yyzz, &&swizzle_zyzz, &&swizzle_wyzz,
&&swizzle_xzzz, &&swizzle_yzzz, &&swizzle_zzzz, &&swizzle_wzzz,
&&swizzle_xwzz, &&swizzle_ywzz, &&swizzle_zwzz, &&swizzle_wwzz,
&&swizzle_xxwz, &&swizzle_yxwz, &&swizzle_zxwz, &&swizzle_wxwz,
&&swizzle_xywz, &&swizzle_yywz, &&swizzle_zywz, &&swizzle_wywz,
&&swizzle_xzwz, &&swizzle_yzwz, &&swizzle_zzwz, &&swizzle_wzwz,
&&swizzle_xwwz, &&swizzle_ywwz, &&swizzle_zwwz, &&swizzle_wwwz,
&&swizzle_xxxw, &&swizzle_yxxw, &&swizzle_zxxw, &&swizzle_wxxw,
&&swizzle_xyxw, &&swizzle_yyxw, &&swizzle_zyxw, &&swizzle_wyxw,
&&swizzle_xzxw, &&swizzle_yzxw, &&swizzle_zzxw, &&swizzle_wzxw,
&&swizzle_xwxw, &&swizzle_ywxw, &&swizzle_zwxw, &&swizzle_wwxw,
&&swizzle_xxyw, &&swizzle_yxyw, &&swizzle_zxyw, &&swizzle_wxyw,
&&swizzle_xyyw, &&swizzle_yyyw, &&swizzle_zyyw, &&swizzle_wyyw,
&&swizzle_xzyw, &&swizzle_yzyw, &&swizzle_zzyw, &&swizzle_wzyw,
&&swizzle_xwyw, &&swizzle_ywyw, &&swizzle_zwyw, &&swizzle_wwyw,
&&swizzle_xxzw, &&swizzle_yxzw, &&swizzle_zxzw, &&swizzle_wxzw,
&&swizzle_xyzw, &&swizzle_yyzw, &&swizzle_zyzw, &&swizzle_wyzw,
&&swizzle_xzzw, &&swizzle_yzzw, &&swizzle_zzzw, &&swizzle_wzzw,
&&swizzle_xwzw, &&swizzle_ywzw, &&swizzle_zwzw, &&swizzle_wwzw,
&&swizzle_xxww, &&swizzle_yxww, &&swizzle_zxww, &&swizzle_wxww,
&&swizzle_xyww, &&swizzle_yyww, &&swizzle_zyww, &&swizzle_wyww,
&&swizzle_xzww, &&swizzle_yzww, &&swizzle_zzww, &&swizzle_wzww,
&&swizzle_xwww, &&swizzle_ywww, &&swizzle_zwww, &&swizzle_wwww,
};
#undef swizzle
static const pr_ivec4_t neg[16] = {
{ 0, 0, 0, 0 },
{ 1<<31, 0, 0, 0 },
{ 0, 1<<31, 0, 0 },
{ 1<<31, 1<<31, 0, 0 },
{ 0, 0, 1<<31, 0 },
{ 1<<31, 0, 1<<31, 0 },
{ 0, 1<<31, 1<<31, 0 },
{ 1<<31, 1<<31, 1<<31, 0 },
{ 0, 0, 0, 1<<31 },
{ 1<<31, 0, 0, 1<<31 },
{ 0, 1<<31, 0, 1<<31 },
{ 1<<31, 1<<31, 0, 1<<31 },
{ 0, 0, 1<<31, 1<<31 },
{ 1<<31, 0, 1<<31, 1<<31 },
{ 0, 1<<31, 1<<31, 1<<31 },
{ 1<<31, 1<<31, 1<<31, 1<<31 },
};
static const pr_ivec4_t zero[16] = {
{ ~0, ~0, ~0, ~0 },
{ 0, ~0, ~0, ~0 },
{ ~0, 0, ~0, ~0 },
{ 0, 0, ~0, ~0 },
{ ~0, ~0, 0, ~0 },
{ 0, ~0, 0, ~0 },
{ ~0, 0, 0, ~0 },
{ 0, 0, 0, ~0 },
{ ~0, ~0, ~0, 0 },
{ 0, ~0, ~0, 0 },
{ ~0, 0, ~0, 0 },
{ 0, 0, ~0, 0 },
{ ~0, ~0, 0, 0 },
{ 0, ~0, 0, 0 },
{ ~0, 0, 0, 0 },
{ 0, 0, 0, 0 },
};
do_swizzle:
goto *swizzle_table[swiz & 0xff];
negate:
vec ^= neg[(swiz >> 8) & 0xf];
vec &= zero[(swiz >> 12) & 0xf];
return vec;
}
[gamecode] Implement 64-bit swizzles See commit for 32-bit swizzles.
2022-01-03 10:55:27 +00:00
static pr_lvec4_t
[gamesource] Work around a windows gcc bug The bug (alignment issues with AVX on windows) seems to have in gcc from the 4.x days, and is still present in 11.2: it does not ensure stack parameters that need 32 byte alignment are aligned. Telling gcc to use the sysv abi (safe on a static function) lets gcc do what it does for linux (usually pass the parameters in registers, which it seems to have done).
2022-01-06 13:21:24 +00:00
#ifdef _WIN64
//force gcc to use registers for the parameters to avoid alignment issues
//on the stack (gcc bug as of 11.2)
__attribute__((sysv_abi))
#endif
[gamecode] Implement 64-bit swizzles See commit for 32-bit swizzles.
2022-01-03 10:55:27 +00:00
pr_swizzle_d (pr_lvec4_t vec, pr_ushort_t swiz)
{
goto do_swizzle;
#define swizzle __builtin_shuffle
swizzle_xxxx: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 0, 0 }); goto negate;
swizzle_yxxx: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 0, 0 }); goto negate;
swizzle_zxxx: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 0, 0 }); goto negate;
swizzle_wxxx: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 0, 0 }); goto negate;
swizzle_xyxx: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 0, 0 }); goto negate;
swizzle_yyxx: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 0, 0 }); goto negate;
swizzle_zyxx: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 0, 0 }); goto negate;
swizzle_wyxx: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 0, 0 }); goto negate;
swizzle_xzxx: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 0, 0 }); goto negate;
swizzle_yzxx: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 0, 0 }); goto negate;
swizzle_zzxx: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 0, 0 }); goto negate;
swizzle_wzxx: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 0, 0 }); goto negate;
swizzle_xwxx: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 0, 0 }); goto negate;
swizzle_ywxx: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 0, 0 }); goto negate;
swizzle_zwxx: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 0, 0 }); goto negate;
swizzle_wwxx: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 0, 0 }); goto negate;
swizzle_xxyx: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 1, 0 }); goto negate;
swizzle_yxyx: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 1, 0 }); goto negate;
swizzle_zxyx: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 1, 0 }); goto negate;
swizzle_wxyx: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 1, 0 }); goto negate;
swizzle_xyyx: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 1, 0 }); goto negate;
swizzle_yyyx: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 1, 0 }); goto negate;
swizzle_zyyx: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 1, 0 }); goto negate;
swizzle_wyyx: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 1, 0 }); goto negate;
swizzle_xzyx: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 1, 0 }); goto negate;
swizzle_yzyx: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 1, 0 }); goto negate;
swizzle_zzyx: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 1, 0 }); goto negate;
swizzle_wzyx: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 1, 0 }); goto negate;
swizzle_xwyx: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 1, 0 }); goto negate;
swizzle_ywyx: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 1, 0 }); goto negate;
swizzle_zwyx: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 1, 0 }); goto negate;
swizzle_wwyx: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 1, 0 }); goto negate;
swizzle_xxzx: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 2, 0 }); goto negate;
swizzle_yxzx: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 2, 0 }); goto negate;
swizzle_zxzx: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 2, 0 }); goto negate;
swizzle_wxzx: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 2, 0 }); goto negate;
swizzle_xyzx: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 2, 0 }); goto negate;
swizzle_yyzx: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 2, 0 }); goto negate;
swizzle_zyzx: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 2, 0 }); goto negate;
swizzle_wyzx: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 2, 0 }); goto negate;
swizzle_xzzx: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 2, 0 }); goto negate;
swizzle_yzzx: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 2, 0 }); goto negate;
swizzle_zzzx: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 2, 0 }); goto negate;
swizzle_wzzx: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 2, 0 }); goto negate;
swizzle_xwzx: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 2, 0 }); goto negate;
swizzle_ywzx: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 2, 0 }); goto negate;
swizzle_zwzx: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 2, 0 }); goto negate;
swizzle_wwzx: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 2, 0 }); goto negate;
swizzle_xxwx: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 3, 0 }); goto negate;
swizzle_yxwx: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 3, 0 }); goto negate;
swizzle_zxwx: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 3, 0 }); goto negate;
swizzle_wxwx: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 3, 0 }); goto negate;
swizzle_xywx: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 3, 0 }); goto negate;
swizzle_yywx: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 3, 0 }); goto negate;
swizzle_zywx: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 3, 0 }); goto negate;
swizzle_wywx: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 3, 0 }); goto negate;
swizzle_xzwx: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 3, 0 }); goto negate;
swizzle_yzwx: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 3, 0 }); goto negate;
swizzle_zzwx: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 3, 0 }); goto negate;
swizzle_wzwx: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 3, 0 }); goto negate;
swizzle_xwwx: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 3, 0 }); goto negate;
swizzle_ywwx: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 3, 0 }); goto negate;
swizzle_zwwx: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 3, 0 }); goto negate;
swizzle_wwwx: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 3, 0 }); goto negate;
swizzle_xxxy: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 0, 1 }); goto negate;
swizzle_yxxy: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 0, 1 }); goto negate;
swizzle_zxxy: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 0, 1 }); goto negate;
swizzle_wxxy: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 0, 1 }); goto negate;
swizzle_xyxy: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 0, 1 }); goto negate;
swizzle_yyxy: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 0, 1 }); goto negate;
swizzle_zyxy: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 0, 1 }); goto negate;
swizzle_wyxy: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 0, 1 }); goto negate;
swizzle_xzxy: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 0, 1 }); goto negate;
swizzle_yzxy: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 0, 1 }); goto negate;
swizzle_zzxy: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 0, 1 }); goto negate;
swizzle_wzxy: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 0, 1 }); goto negate;
swizzle_xwxy: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 0, 1 }); goto negate;
swizzle_ywxy: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 0, 1 }); goto negate;
swizzle_zwxy: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 0, 1 }); goto negate;
swizzle_wwxy: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 0, 1 }); goto negate;
swizzle_xxyy: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 1, 1 }); goto negate;
swizzle_yxyy: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 1, 1 }); goto negate;
swizzle_zxyy: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 1, 1 }); goto negate;
swizzle_wxyy: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 1, 1 }); goto negate;
swizzle_xyyy: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 1, 1 }); goto negate;
swizzle_yyyy: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 1, 1 }); goto negate;
swizzle_zyyy: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 1, 1 }); goto negate;
swizzle_wyyy: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 1, 1 }); goto negate;
swizzle_xzyy: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 1, 1 }); goto negate;
swizzle_yzyy: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 1, 1 }); goto negate;
swizzle_zzyy: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 1, 1 }); goto negate;
swizzle_wzyy: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 1, 1 }); goto negate;
swizzle_xwyy: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 1, 1 }); goto negate;
swizzle_ywyy: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 1, 1 }); goto negate;
swizzle_zwyy: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 1, 1 }); goto negate;
swizzle_wwyy: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 1, 1 }); goto negate;
swizzle_xxzy: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 2, 1 }); goto negate;
swizzle_yxzy: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 2, 1 }); goto negate;
swizzle_zxzy: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 2, 1 }); goto negate;
swizzle_wxzy: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 2, 1 }); goto negate;
swizzle_xyzy: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 2, 1 }); goto negate;
swizzle_yyzy: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 2, 1 }); goto negate;
swizzle_zyzy: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 2, 1 }); goto negate;
swizzle_wyzy: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 2, 1 }); goto negate;
swizzle_xzzy: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 2, 1 }); goto negate;
swizzle_yzzy: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 2, 1 }); goto negate;
swizzle_zzzy: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 2, 1 }); goto negate;
swizzle_wzzy: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 2, 1 }); goto negate;
swizzle_xwzy: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 2, 1 }); goto negate;
swizzle_ywzy: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 2, 1 }); goto negate;
swizzle_zwzy: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 2, 1 }); goto negate;
swizzle_wwzy: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 2, 1 }); goto negate;
swizzle_xxwy: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 3, 1 }); goto negate;
swizzle_yxwy: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 3, 1 }); goto negate;
swizzle_zxwy: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 3, 1 }); goto negate;
swizzle_wxwy: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 3, 1 }); goto negate;
swizzle_xywy: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 3, 1 }); goto negate;
swizzle_yywy: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 3, 1 }); goto negate;
swizzle_zywy: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 3, 1 }); goto negate;
swizzle_wywy: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 3, 1 }); goto negate;
swizzle_xzwy: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 3, 1 }); goto negate;
swizzle_yzwy: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 3, 1 }); goto negate;
swizzle_zzwy: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 3, 1 }); goto negate;
swizzle_wzwy: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 3, 1 }); goto negate;
swizzle_xwwy: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 3, 1 }); goto negate;
swizzle_ywwy: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 3, 1 }); goto negate;
swizzle_zwwy: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 3, 1 }); goto negate;
swizzle_wwwy: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 3, 1 }); goto negate;
swizzle_xxxz: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 0, 2 }); goto negate;
swizzle_yxxz: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 0, 2 }); goto negate;
swizzle_zxxz: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 0, 2 }); goto negate;
swizzle_wxxz: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 0, 2 }); goto negate;
swizzle_xyxz: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 0, 2 }); goto negate;
swizzle_yyxz: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 0, 2 }); goto negate;
swizzle_zyxz: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 0, 2 }); goto negate;
swizzle_wyxz: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 0, 2 }); goto negate;
swizzle_xzxz: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 0, 2 }); goto negate;
swizzle_yzxz: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 0, 2 }); goto negate;
swizzle_zzxz: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 0, 2 }); goto negate;
swizzle_wzxz: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 0, 2 }); goto negate;
swizzle_xwxz: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 0, 2 }); goto negate;
swizzle_ywxz: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 0, 2 }); goto negate;
swizzle_zwxz: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 0, 2 }); goto negate;
swizzle_wwxz: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 0, 2 }); goto negate;
swizzle_xxyz: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 1, 2 }); goto negate;
swizzle_yxyz: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 1, 2 }); goto negate;
swizzle_zxyz: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 1, 2 }); goto negate;
swizzle_wxyz: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 1, 2 }); goto negate;
swizzle_xyyz: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 1, 2 }); goto negate;
swizzle_yyyz: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 1, 2 }); goto negate;
swizzle_zyyz: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 1, 2 }); goto negate;
swizzle_wyyz: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 1, 2 }); goto negate;
swizzle_xzyz: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 1, 2 }); goto negate;
swizzle_yzyz: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 1, 2 }); goto negate;
swizzle_zzyz: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 1, 2 }); goto negate;
swizzle_wzyz: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 1, 2 }); goto negate;
swizzle_xwyz: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 1, 2 }); goto negate;
swizzle_ywyz: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 1, 2 }); goto negate;
swizzle_zwyz: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 1, 2 }); goto negate;
swizzle_wwyz: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 1, 2 }); goto negate;
swizzle_xxzz: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 2, 2 }); goto negate;
swizzle_yxzz: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 2, 2 }); goto negate;
swizzle_zxzz: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 2, 2 }); goto negate;
swizzle_wxzz: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 2, 2 }); goto negate;
swizzle_xyzz: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 2, 2 }); goto negate;
swizzle_yyzz: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 2, 2 }); goto negate;
swizzle_zyzz: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 2, 2 }); goto negate;
swizzle_wyzz: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 2, 2 }); goto negate;
swizzle_xzzz: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 2, 2 }); goto negate;
swizzle_yzzz: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 2, 2 }); goto negate;
swizzle_zzzz: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 2, 2 }); goto negate;
swizzle_wzzz: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 2, 2 }); goto negate;
swizzle_xwzz: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 2, 2 }); goto negate;
swizzle_ywzz: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 2, 2 }); goto negate;
swizzle_zwzz: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 2, 2 }); goto negate;
swizzle_wwzz: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 2, 2 }); goto negate;
swizzle_xxwz: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 3, 2 }); goto negate;
swizzle_yxwz: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 3, 2 }); goto negate;
swizzle_zxwz: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 3, 2 }); goto negate;
swizzle_wxwz: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 3, 2 }); goto negate;
swizzle_xywz: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 3, 2 }); goto negate;
swizzle_yywz: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 3, 2 }); goto negate;
swizzle_zywz: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 3, 2 }); goto negate;
swizzle_wywz: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 3, 2 }); goto negate;
swizzle_xzwz: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 3, 2 }); goto negate;
swizzle_yzwz: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 3, 2 }); goto negate;
swizzle_zzwz: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 3, 2 }); goto negate;
swizzle_wzwz: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 3, 2 }); goto negate;
swizzle_xwwz: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 3, 2 }); goto negate;
swizzle_ywwz: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 3, 2 }); goto negate;
swizzle_zwwz: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 3, 2 }); goto negate;
swizzle_wwwz: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 3, 2 }); goto negate;
swizzle_xxxw: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 0, 3 }); goto negate;
swizzle_yxxw: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 0, 3 }); goto negate;
swizzle_zxxw: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 0, 3 }); goto negate;
swizzle_wxxw: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 0, 3 }); goto negate;
swizzle_xyxw: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 0, 3 }); goto negate;
swizzle_yyxw: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 0, 3 }); goto negate;
swizzle_zyxw: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 0, 3 }); goto negate;
swizzle_wyxw: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 0, 3 }); goto negate;
swizzle_xzxw: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 0, 3 }); goto negate;
swizzle_yzxw: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 0, 3 }); goto negate;
swizzle_zzxw: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 0, 3 }); goto negate;
swizzle_wzxw: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 0, 3 }); goto negate;
swizzle_xwxw: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 0, 3 }); goto negate;
swizzle_ywxw: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 0, 3 }); goto negate;
swizzle_zwxw: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 0, 3 }); goto negate;
swizzle_wwxw: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 0, 3 }); goto negate;
swizzle_xxyw: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 1, 3 }); goto negate;
swizzle_yxyw: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 1, 3 }); goto negate;
swizzle_zxyw: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 1, 3 }); goto negate;
swizzle_wxyw: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 1, 3 }); goto negate;
swizzle_xyyw: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 1, 3 }); goto negate;
swizzle_yyyw: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 1, 3 }); goto negate;
swizzle_zyyw: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 1, 3 }); goto negate;
swizzle_wyyw: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 1, 3 }); goto negate;
swizzle_xzyw: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 1, 3 }); goto negate;
swizzle_yzyw: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 1, 3 }); goto negate;
swizzle_zzyw: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 1, 3 }); goto negate;
swizzle_wzyw: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 1, 3 }); goto negate;
swizzle_xwyw: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 1, 3 }); goto negate;
swizzle_ywyw: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 1, 3 }); goto negate;
swizzle_zwyw: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 1, 3 }); goto negate;
swizzle_wwyw: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 1, 3 }); goto negate;
swizzle_xxzw: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 2, 3 }); goto negate;
swizzle_yxzw: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 2, 3 }); goto negate;
swizzle_zxzw: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 2, 3 }); goto negate;
swizzle_wxzw: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 2, 3 }); goto negate;
swizzle_xyzw: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 2, 3 }); goto negate;
swizzle_yyzw: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 2, 3 }); goto negate;
swizzle_zyzw: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 2, 3 }); goto negate;
swizzle_wyzw: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 2, 3 }); goto negate;
swizzle_xzzw: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 2, 3 }); goto negate;
swizzle_yzzw: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 2, 3 }); goto negate;
swizzle_zzzw: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 2, 3 }); goto negate;
swizzle_wzzw: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 2, 3 }); goto negate;
swizzle_xwzw: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 2, 3 }); goto negate;
swizzle_ywzw: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 2, 3 }); goto negate;
swizzle_zwzw: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 2, 3 }); goto negate;
swizzle_wwzw: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 2, 3 }); goto negate;
swizzle_xxww: vec = swizzle (vec, (pr_lvec4_t) { 0, 0, 3, 3 }); goto negate;
swizzle_yxww: vec = swizzle (vec, (pr_lvec4_t) { 1, 0, 3, 3 }); goto negate;
swizzle_zxww: vec = swizzle (vec, (pr_lvec4_t) { 2, 0, 3, 3 }); goto negate;
swizzle_wxww: vec = swizzle (vec, (pr_lvec4_t) { 3, 0, 3, 3 }); goto negate;
swizzle_xyww: vec = swizzle (vec, (pr_lvec4_t) { 0, 1, 3, 3 }); goto negate;
swizzle_yyww: vec = swizzle (vec, (pr_lvec4_t) { 1, 1, 3, 3 }); goto negate;
swizzle_zyww: vec = swizzle (vec, (pr_lvec4_t) { 2, 1, 3, 3 }); goto negate;
swizzle_wyww: vec = swizzle (vec, (pr_lvec4_t) { 3, 1, 3, 3 }); goto negate;
swizzle_xzww: vec = swizzle (vec, (pr_lvec4_t) { 0, 2, 3, 3 }); goto negate;
swizzle_yzww: vec = swizzle (vec, (pr_lvec4_t) { 1, 2, 3, 3 }); goto negate;
swizzle_zzww: vec = swizzle (vec, (pr_lvec4_t) { 2, 2, 3, 3 }); goto negate;
swizzle_wzww: vec = swizzle (vec, (pr_lvec4_t) { 3, 2, 3, 3 }); goto negate;
swizzle_xwww: vec = swizzle (vec, (pr_lvec4_t) { 0, 3, 3, 3 }); goto negate;
swizzle_ywww: vec = swizzle (vec, (pr_lvec4_t) { 1, 3, 3, 3 }); goto negate;
swizzle_zwww: vec = swizzle (vec, (pr_lvec4_t) { 2, 3, 3, 3 }); goto negate;
swizzle_wwww: vec = swizzle (vec, (pr_lvec4_t) { 3, 3, 3, 3 }); goto negate;
static void *swizzle_table[256] = {
&&swizzle_xxxx, &&swizzle_yxxx, &&swizzle_zxxx, &&swizzle_wxxx,
&&swizzle_xyxx, &&swizzle_yyxx, &&swizzle_zyxx, &&swizzle_wyxx,
&&swizzle_xzxx, &&swizzle_yzxx, &&swizzle_zzxx, &&swizzle_wzxx,
&&swizzle_xwxx, &&swizzle_ywxx, &&swizzle_zwxx, &&swizzle_wwxx,
&&swizzle_xxyx, &&swizzle_yxyx, &&swizzle_zxyx, &&swizzle_wxyx,
&&swizzle_xyyx, &&swizzle_yyyx, &&swizzle_zyyx, &&swizzle_wyyx,
&&swizzle_xzyx, &&swizzle_yzyx, &&swizzle_zzyx, &&swizzle_wzyx,
&&swizzle_xwyx, &&swizzle_ywyx, &&swizzle_zwyx, &&swizzle_wwyx,
&&swizzle_xxzx, &&swizzle_yxzx, &&swizzle_zxzx, &&swizzle_wxzx,
&&swizzle_xyzx, &&swizzle_yyzx, &&swizzle_zyzx, &&swizzle_wyzx,
&&swizzle_xzzx, &&swizzle_yzzx, &&swizzle_zzzx, &&swizzle_wzzx,
&&swizzle_xwzx, &&swizzle_ywzx, &&swizzle_zwzx, &&swizzle_wwzx,
&&swizzle_xxwx, &&swizzle_yxwx, &&swizzle_zxwx, &&swizzle_wxwx,
&&swizzle_xywx, &&swizzle_yywx, &&swizzle_zywx, &&swizzle_wywx,
&&swizzle_xzwx, &&swizzle_yzwx, &&swizzle_zzwx, &&swizzle_wzwx,
&&swizzle_xwwx, &&swizzle_ywwx, &&swizzle_zwwx, &&swizzle_wwwx,
&&swizzle_xxxy, &&swizzle_yxxy, &&swizzle_zxxy, &&swizzle_wxxy,
&&swizzle_xyxy, &&swizzle_yyxy, &&swizzle_zyxy, &&swizzle_wyxy,
&&swizzle_xzxy, &&swizzle_yzxy, &&swizzle_zzxy, &&swizzle_wzxy,
&&swizzle_xwxy, &&swizzle_ywxy, &&swizzle_zwxy, &&swizzle_wwxy,
&&swizzle_xxyy, &&swizzle_yxyy, &&swizzle_zxyy, &&swizzle_wxyy,
&&swizzle_xyyy, &&swizzle_yyyy, &&swizzle_zyyy, &&swizzle_wyyy,
&&swizzle_xzyy, &&swizzle_yzyy, &&swizzle_zzyy, &&swizzle_wzyy,
&&swizzle_xwyy, &&swizzle_ywyy, &&swizzle_zwyy, &&swizzle_wwyy,
&&swizzle_xxzy, &&swizzle_yxzy, &&swizzle_zxzy, &&swizzle_wxzy,
&&swizzle_xyzy, &&swizzle_yyzy, &&swizzle_zyzy, &&swizzle_wyzy,
&&swizzle_xzzy, &&swizzle_yzzy, &&swizzle_zzzy, &&swizzle_wzzy,
&&swizzle_xwzy, &&swizzle_ywzy, &&swizzle_zwzy, &&swizzle_wwzy,
&&swizzle_xxwy, &&swizzle_yxwy, &&swizzle_zxwy, &&swizzle_wxwy,
&&swizzle_xywy, &&swizzle_yywy, &&swizzle_zywy, &&swizzle_wywy,
&&swizzle_xzwy, &&swizzle_yzwy, &&swizzle_zzwy, &&swizzle_wzwy,
&&swizzle_xwwy, &&swizzle_ywwy, &&swizzle_zwwy, &&swizzle_wwwy,
&&swizzle_xxxz, &&swizzle_yxxz, &&swizzle_zxxz, &&swizzle_wxxz,
&&swizzle_xyxz, &&swizzle_yyxz, &&swizzle_zyxz, &&swizzle_wyxz,
&&swizzle_xzxz, &&swizzle_yzxz, &&swizzle_zzxz, &&swizzle_wzxz,
&&swizzle_xwxz, &&swizzle_ywxz, &&swizzle_zwxz, &&swizzle_wwxz,
&&swizzle_xxyz, &&swizzle_yxyz, &&swizzle_zxyz, &&swizzle_wxyz,
&&swizzle_xyyz, &&swizzle_yyyz, &&swizzle_zyyz, &&swizzle_wyyz,
&&swizzle_xzyz, &&swizzle_yzyz, &&swizzle_zzyz, &&swizzle_wzyz,
&&swizzle_xwyz, &&swizzle_ywyz, &&swizzle_zwyz, &&swizzle_wwyz,
&&swizzle_xxzz, &&swizzle_yxzz, &&swizzle_zxzz, &&swizzle_wxzz,
&&swizzle_xyzz, &&swizzle_yyzz, &&swizzle_zyzz, &&swizzle_wyzz,
&&swizzle_xzzz, &&swizzle_yzzz, &&swizzle_zzzz, &&swizzle_wzzz,
&&swizzle_xwzz, &&swizzle_ywzz, &&swizzle_zwzz, &&swizzle_wwzz,
&&swizzle_xxwz, &&swizzle_yxwz, &&swizzle_zxwz, &&swizzle_wxwz,
&&swizzle_xywz, &&swizzle_yywz, &&swizzle_zywz, &&swizzle_wywz,
&&swizzle_xzwz, &&swizzle_yzwz, &&swizzle_zzwz, &&swizzle_wzwz,
&&swizzle_xwwz, &&swizzle_ywwz, &&swizzle_zwwz, &&swizzle_wwwz,
&&swizzle_xxxw, &&swizzle_yxxw, &&swizzle_zxxw, &&swizzle_wxxw,
&&swizzle_xyxw, &&swizzle_yyxw, &&swizzle_zyxw, &&swizzle_wyxw,
&&swizzle_xzxw, &&swizzle_yzxw, &&swizzle_zzxw, &&swizzle_wzxw,
&&swizzle_xwxw, &&swizzle_ywxw, &&swizzle_zwxw, &&swizzle_wwxw,
&&swizzle_xxyw, &&swizzle_yxyw, &&swizzle_zxyw, &&swizzle_wxyw,
&&swizzle_xyyw, &&swizzle_yyyw, &&swizzle_zyyw, &&swizzle_wyyw,
&&swizzle_xzyw, &&swizzle_yzyw, &&swizzle_zzyw, &&swizzle_wzyw,
&&swizzle_xwyw, &&swizzle_ywyw, &&swizzle_zwyw, &&swizzle_wwyw,
&&swizzle_xxzw, &&swizzle_yxzw, &&swizzle_zxzw, &&swizzle_wxzw,
&&swizzle_xyzw, &&swizzle_yyzw, &&swizzle_zyzw, &&swizzle_wyzw,
&&swizzle_xzzw, &&swizzle_yzzw, &&swizzle_zzzw, &&swizzle_wzzw,
&&swizzle_xwzw, &&swizzle_ywzw, &&swizzle_zwzw, &&swizzle_wwzw,
&&swizzle_xxww, &&swizzle_yxww, &&swizzle_zxww, &&swizzle_wxww,
&&swizzle_xyww, &&swizzle_yyww, &&swizzle_zyww, &&swizzle_wyww,
&&swizzle_xzww, &&swizzle_yzww, &&swizzle_zzww, &&swizzle_wzww,
&&swizzle_xwww, &&swizzle_ywww, &&swizzle_zwww, &&swizzle_wwww,
};
#undef swizzle
[gamecode] use INT64_C instead of l-suffix Once again, I had forgotten that long is not always 64-bits.
2022-01-06 13:20:16 +00:00
#define L(x) UINT64_C(x)
[gamecode] Implement 64-bit swizzles See commit for 32-bit swizzles.
2022-01-03 10:55:27 +00:00
static const pr_lvec4_t neg[16] = {
[gamecode] use INT64_C instead of l-suffix Once again, I had forgotten that long is not always 64-bits.
2022-01-06 13:20:16 +00:00
{ INT64_C(0), INT64_C(0), INT64_C(0), INT64_C(0) },
{ INT64_C(1)<<63, INT64_C(0), INT64_C(0), INT64_C(0) },
{ INT64_C(0), INT64_C(1)<<63, INT64_C(0), INT64_C(0) },
{ INT64_C(1)<<63, INT64_C(1)<<63, INT64_C(0), INT64_C(0) },
{ INT64_C(0), INT64_C(0), INT64_C(1)<<63, INT64_C(0) },
{ INT64_C(1)<<63, INT64_C(0), INT64_C(1)<<63, INT64_C(0) },
{ INT64_C(0), INT64_C(1)<<63, INT64_C(1)<<63, INT64_C(0) },
{ INT64_C(1)<<63, INT64_C(1)<<63, INT64_C(1)<<63, INT64_C(0) },
{ INT64_C(0), INT64_C(0), INT64_C(0), INT64_C(1)<<63 },
{ INT64_C(1)<<63, INT64_C(0), INT64_C(0), INT64_C(1)<<63 },
{ INT64_C(0), INT64_C(1)<<63, INT64_C(0), INT64_C(1)<<63 },
{ INT64_C(1)<<63, INT64_C(1)<<63, INT64_C(0), INT64_C(1)<<63 },
{ INT64_C(0), INT64_C(0), INT64_C(1)<<63, INT64_C(1)<<63 },
{ INT64_C(1)<<63, INT64_C(0), INT64_C(1)<<63, INT64_C(1)<<63 },
{ INT64_C(0), INT64_C(1)<<63, INT64_C(1)<<63, INT64_C(1)<<63 },
{ INT64_C(1)<<63, INT64_C(1)<<63, INT64_C(1)<<63, INT64_C(1)<<63 },
[gamecode] Implement 64-bit swizzles See commit for 32-bit swizzles.
2022-01-03 10:55:27 +00:00
};
static const pr_lvec4_t zero[16] = {
[gamecode] use INT64_C instead of l-suffix Once again, I had forgotten that long is not always 64-bits.
2022-01-06 13:20:16 +00:00
{ ~INT64_C(0), ~INT64_C(0), ~INT64_C(0), ~INT64_C(0) },
{ INT64_C(0), ~INT64_C(0), ~INT64_C(0), ~INT64_C(0) },
{ ~INT64_C(0), INT64_C(0), ~INT64_C(0), ~INT64_C(0) },
{ INT64_C(0), INT64_C(0), ~INT64_C(0), ~INT64_C(0) },
{ ~INT64_C(0), ~INT64_C(0), INT64_C(0), ~INT64_C(0) },
{ INT64_C(0), ~INT64_C(0), INT64_C(0), ~INT64_C(0) },
{ ~INT64_C(0), INT64_C(0), INT64_C(0), ~INT64_C(0) },
{ INT64_C(0), INT64_C(0), INT64_C(0), ~INT64_C(0) },
{ ~INT64_C(0), ~INT64_C(0), ~INT64_C(0), INT64_C(0) },
{ INT64_C(0), ~INT64_C(0), ~INT64_C(0), INT64_C(0) },
{ ~INT64_C(0), INT64_C(0), ~INT64_C(0), INT64_C(0) },
{ INT64_C(0), INT64_C(0), ~INT64_C(0), INT64_C(0) },
{ ~INT64_C(0), ~INT64_C(0), INT64_C(0), INT64_C(0) },
{ INT64_C(0), ~INT64_C(0), INT64_C(0), INT64_C(0) },
{ ~INT64_C(0), INT64_C(0), INT64_C(0), INT64_C(0) },
{ INT64_C(0), INT64_C(0), INT64_C(0), INT64_C(0) },
[gamecode] Implement 64-bit swizzles See commit for 32-bit swizzles.
2022-01-03 10:55:27 +00:00
};
do_swizzle:
goto *swizzle_table[swiz & 0xff];
negate:
vec ^= neg[(swiz >> 8) & 0xf];
vec &= zero[(swiz >> 12) & 0xf];
return vec;
}
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
static void
pr_exec_ruamoko (progs_t *pr, int exitdepth)
{
int profile, startprofile;
dstatement_t *st;
pr_type_t old_val = {0};
// make a stack frame
startprofile = profile = 0;
st = pr->pr_statements + pr->pr_xstatement;
if (pr->watch) {
old_val = *pr->watch;
}
while (1) {
st++;
++pr->pr_xstatement;
if (pr->pr_xstatement != st - pr->pr_statements)
PR_RunError (pr, "internal error");
if (++profile > 1000000 && !pr->no_exec_limit) {
PR_RunError (pr, "runaway loop error");
}
if (pr->pr_trace) {
if (pr->debug_handler) {
pr->debug_handler (prd_trace, 0, pr->debug_data);
} else {
PR_PrintStatement (pr, st, 1);
}
}
if (st->op & OP_BREAK) {
if (pr->debug_handler) {
pr->debug_handler (prd_breakpoint, 0, pr->debug_data);
} else {
PR_RunError (pr, "breakpoint hit");
}
}
[gamecode] Clean up string_t and pointer_t They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a little clearer than ptr, but ptr is consistent with things like intptr, and keeps the type name short).
2022-01-18 03:11:14 +00:00
pr_ptr_t st_a = st->a + PR_BASE (pr, st, A);
pr_ptr_t st_b = st->b + PR_BASE (pr, st, B);
pr_ptr_t st_c = st->c + PR_BASE (pr, st, C);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
pr_type_t *op_a = pr->pr_globals + st_a;
pr_type_t *op_b = pr->pr_globals + st_b;
pr_type_t *op_c = pr->pr_globals + st_c;
pr_type_t *stk;
pr_type_t *mm;
[gamecode] Rename func_t to pr_func_t Even more consistency.
2022-01-18 06:32:43 +00:00
pr_func_t function;
[gamecode] Create a mask for extracting the opcode Got tired of copying the full thing around.
2022-01-03 08:54:54 +00:00
pr_opcode_e st_op = st->op & OP_MASK;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
switch (st_op) {
// 0 0000
[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
case OP_NOP:
break;
case OP_ADJSTK:
[gamecode] Initialize .stack if it's available And implement bounds checks for adjstk.
2022-01-21 11:33:15 +00:00
pr_stack_adjust (pr, st->a, (short) st->b);
[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
break;
case OP_LDCONST:
PR_RunError (pr, "OP_LDCONST not implemented");
break;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
case OP_LOAD_B_1:
case OP_LOAD_C_1:
case OP_LOAD_D_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
mm = pr_address_mode (pr, st, (st_op - OP_LOAD_B_1 + 4) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
OPC(int) = MM(int);
break;
case OP_LOAD_B_2:
case OP_LOAD_C_2:
case OP_LOAD_D_2:
[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
mm = pr_address_mode (pr, st, (st_op - OP_LOAD_B_2 + 4) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
OPC(ivec2) = MM(ivec2);
break;
case OP_LOAD_B_3:
case OP_LOAD_C_3:
case OP_LOAD_D_3:
[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
mm = pr_address_mode (pr, st, (st_op - OP_LOAD_B_3 + 4) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
VectorCopy (&MM(int), &OPC(int));
break;
case OP_LOAD_B_4:
case OP_LOAD_C_4:
case OP_LOAD_D_4:
[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
mm = pr_address_mode (pr, st, (st_op - OP_LOAD_B_4 + 4) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
OPC(ivec4) = MM(ivec4);
break;
// 0 0001
case OP_STORE_A_1:
case OP_STORE_B_1:
case OP_STORE_C_1:
case OP_STORE_D_1:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_STORE_A_1) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
MM(int) = OPC(int);
break;
case OP_STORE_A_2:
case OP_STORE_B_2:
case OP_STORE_C_2:
case OP_STORE_D_2:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_STORE_A_2) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
MM(ivec2) = OPC(ivec2);
break;
case OP_STORE_A_3:
case OP_STORE_B_3:
case OP_STORE_C_3:
case OP_STORE_D_3:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_STORE_A_3) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
VectorCopy (&OPC(int), &MM(int));
break;
case OP_STORE_A_4:
case OP_STORE_B_4:
case OP_STORE_C_4:
case OP_STORE_D_4:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_STORE_A_4) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
MM(ivec4) = OPC(ivec4);
break;
// 0 0010
case OP_PUSH_A_1:
case OP_PUSH_B_1:
case OP_PUSH_C_1:
case OP_PUSH_D_1:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_PUSH_A_1) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
stk = pr_stack_push (pr);
STK(int) = MM(int);
break;
case OP_PUSH_A_2:
case OP_PUSH_B_2:
case OP_PUSH_C_2:
case OP_PUSH_D_2:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_PUSH_A_2) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
stk = pr_stack_push (pr);
STK(ivec2) = MM(ivec2);
break;
case OP_PUSH_A_3:
case OP_PUSH_B_3:
case OP_PUSH_C_3:
case OP_PUSH_D_3:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_PUSH_A_3) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
stk = pr_stack_push (pr);
VectorCopy (&MM(int), &STK(int));
break;
case OP_PUSH_A_4:
case OP_PUSH_B_4:
case OP_PUSH_C_4:
case OP_PUSH_D_4:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_PUSH_A_4) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
stk = pr_stack_push (pr);
STK(ivec4) = MM(ivec4);
break;
// 0 0011
case OP_POP_A_1:
case OP_POP_B_1:
case OP_POP_C_1:
case OP_POP_D_1:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_POP_A_1) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
stk = pr_stack_pop (pr);
MM(int) = STK(int);
break;
case OP_POP_A_2:
case OP_POP_B_2:
case OP_POP_C_2:
case OP_POP_D_2:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_POP_A_2) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
stk = pr_stack_pop (pr);
MM(ivec2) = STK(ivec2);
break;
case OP_POP_A_3:
case OP_POP_B_3:
case OP_POP_C_3:
case OP_POP_D_3:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_POP_A_3) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
stk = pr_stack_pop (pr);
VectorCopy (&STK(int), &MM(int));
break;
case OP_POP_A_4:
case OP_POP_B_4:
case OP_POP_C_4:
case OP_POP_D_4:
[gamecode] Drop B addressing for lea When creating the tests for lea, I noticed that B was yet another simple assign, so I decided it was best to drop it and move E into its place (freeing up another instruction).
2022-01-15 07:27:46 +00:00
mm = pr_address_mode (pr, st, (st_op - OP_POP_A_4) >> 2);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
stk = pr_stack_pop (pr);
MM(ivec4) = STK(ivec4);
break;
// 0 0100
[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
// spare
[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
// 0 0101
[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
// spare
[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
// 0 0110
[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
// spare
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
// 0 0111
[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
// spare
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
#define OP_cmp_1(OP, T, rt, cmp, ct) \
case OP_##OP##_##T##_1: \
OPC(rt) = -(OPA(ct) cmp OPB(ct)); \
break
#define OP_cmp_2(OP, T, rt, cmp, ct) \
case OP_##OP##_##T##_2: \
OPC(rt) = (OPA(ct) cmp OPB(ct)); \
break
#define OP_cmp_3(OP, T, rt, cmp, ct) \
case OP_##OP##_##T##_3: \
VectorCompCompare (&OPC(rt), -, &OPA(ct), cmp, &OPB(ct)); \
break;
#define OP_cmp_4(OP, T, rt, cmp, ct) \
case OP_##OP##_##T##_4: \
OPC(rt) = (OPA(ct) cmp OPB(ct)); \
break
#define OP_cmp_T(OP, T, rt1, rt2, rt4, cmp, ct1, ct2, ct4) \
OP_cmp_1 (OP, T, rt1, cmp, ct1); \
OP_cmp_2 (OP, T, rt2, cmp, ct2); \
OP_cmp_3 (OP, T, rt1, cmp, ct1); \
OP_cmp_4 (OP, T, rt4, cmp, ct4)
#define OP_cmp(OP, cmp) \
OP_cmp_T (OP, I, int, ivec2, ivec4, cmp, int, ivec2, ivec4); \
OP_cmp_T (OP, F, int, ivec2, ivec4, cmp, float, vec2, vec4); \
OP_cmp_T (OP, L, long, lvec2, lvec4, cmp, long, lvec2, lvec4); \
OP_cmp_T (OP, D, long, lvec2, lvec4, cmp, double, dvec2, dvec4)
// 0 1000
OP_cmp(EQ, ==);
// 0 1001
OP_cmp(LT, <);
// 0 1010
OP_cmp(GT, >);
[gamecode] Add unsigned divide and remainder instructions I had forgotten that unsigned division was different from signed division (rather silly of me). However, with some testing and analysis, unsigned true modulo is not needed as it's not possible to have negative inputs and thus it's the same as remainder.
2022-02-06 03:20:17 +00:00
#define OP_op_1(OP, T, t, op) \
case OP_##OP##_##T##_1: \
OPC(t) = (OPA(t) op OPB(t)); \
break
#define OP_op_2(OP, T, t, op) \
case OP_##OP##_##T##_2: \
OPC(t) = (OPA(t) op OPB(t)); \
break
#define OP_op_3(OP, T, t, op) \
case OP_##OP##_##T##_3: \
VectorCompOp (&OPC(t), &OPA(t), op, &OPB(t)); \
break;
#define OP_op_4(OP, T, t, op) \
case OP_##OP##_##T##_4: \
OPC(t) = (OPA(t) op OPB(t)); \
break
#define OP_op_T(OP, T, t1, t2, t4, op) \
OP_op_1 (OP, T, t1, op); \
OP_op_2 (OP, T, t2, op); \
OP_op_3 (OP, T, t1, op); \
OP_op_4 (OP, T, t4, op)
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
// 0 1011
[gamecode] Add unsigned divide and remainder instructions I had forgotten that unsigned division was different from signed division (rather silly of me). However, with some testing and analysis, unsigned true modulo is not needed as it's not possible to have negative inputs and thus it's the same as remainder.
2022-02-06 03:20:17 +00:00
OP_op_T (DIV, u, uint, uivec2, uivec4, /);
OP_op_T (DIV, U, ulong, ulvec2, ulvec4, /);
OP_op_T (REM, u, uint, uivec2, uivec4, %);
OP_op_T (REM, U, ulong, ulvec2, ulvec4, %);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
// 0 1100
OP_cmp(NE, !=);
// 0 1101
OP_cmp(GE, >=);
// 0 1110
OP_cmp(LE, <=);
[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
// 0 1111
[gamecode] Add 64-bit load/store instructions Only widths 3 and 4 have been added because widths 1 and 2 can be implemented by widths 2 and 4 of the 32-bit load/store instructions.
2022-02-02 05:47:36 +00:00
case OP_LOAD64_B_3:
case OP_LOAD64_C_3:
case OP_LOAD64_D_3:
mm = pr_address_mode (pr, st, (st_op - OP_LOAD64_B_3 + 1));
VectorCopy (&MM(long), &OPC(long));
break;
case OP_STORE64_A_3:
case OP_STORE64_B_3:
case OP_STORE64_C_3:
case OP_STORE64_D_3:
mm = pr_address_mode (pr, st, (st_op - OP_STORE64_A_3));
VectorCopy (&OPC(long), &MM(long));
break;
case OP_LOAD64_B_4:
case OP_LOAD64_C_4:
case OP_LOAD64_D_4:
mm = pr_address_mode (pr, st, (st_op - OP_LOAD64_B_4 + 1));
OPC(lvec4) = MM(lvec4);
break;
case OP_STORE64_A_4:
case OP_STORE64_B_4:
case OP_STORE64_C_4:
case OP_STORE64_D_4:
mm = pr_address_mode (pr, st, (st_op - OP_STORE64_A_4));
MM(lvec4) = OPC(lvec4);
break;
[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
// spare
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
#define OP_op(OP, op) \
OP_op_T (OP, I, int, ivec2, ivec4, op); \
OP_op_T (OP, F, float, vec2, vec4, op); \
OP_op_T (OP, L, long, lvec2, lvec4, op); \
OP_op_T (OP, D, double, dvec2, dvec4, op)
#define OP_uop_1(OP, T, t, op) \
case OP_##OP##_##T##_1: \
OPC(t) = op (OPA(t)); \
break
#define OP_uop_2(OP, T, t, op) \
case OP_##OP##_##T##_2: \
OPC(t) = op (OPA(t)); \
break
#define OP_uop_3(OP, T, t, op) \
case OP_##OP##_##T##_3: \
VectorCompUop (&OPC(t), op, &OPA(t)); \
break;
#define OP_uop_4(OP, T, t, op) \
case OP_##OP##_##T##_4: \
OPC(t) = op (OPA(t)); \
break
#define OP_uop_T(OP, T, t1, t2, t4, op) \
OP_uop_1 (OP, T, t1, op); \
OP_uop_2 (OP, T, t2, op); \
OP_uop_3 (OP, T, t1, op); \
OP_uop_4 (OP, T, t4, op)
// 1 0000
OP_op(MUL, *);
// 1 0001
OP_op(DIV, /);
[gamecode] Fix up MOD (%%) for integral types Use the new "1" versions of loadvec3 to get a 1 in w to avoid divide-by-zero errors, and use the correct type for longs (forgot to change i to l on the vector types).
2022-01-04 09:36:13 +00:00
// implement remainder (c %) for integers:
// 5 rem 3 = 2
// -5 rem 3 = -2
// 5 rem -3 = 2
// -5 rem -3 = -2
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
#define OP_store(d, s) *(d) = s
#define OP_remmod_T(OP, T, n, t, l, f, s) \
case OP_##OP##_##T##_##n: \
{ \
__auto_type a = l (&OPA(t)); \
__auto_type b = l (&OPB(t)); \
s (&OPC(t), a - b * f(a / b)); \
} \
break
#define OP_rem_T(T, n, t, l, f, s) \
OP_remmod_T(REM, T, n, t, l, f, s)
// 1 0010
OP_op_T (REM, I, int, ivec2, ivec4, %);
OP_rem_T (F, 1, float, *, truncf, OP_store);
OP_rem_T (F, 2, vec2, *, vtrunc2f, OP_store);
OP_rem_T (F, 3, float, loadvec3f, vtrunc4f, storevec3f);
OP_rem_T (F, 4, vec4, *, vtrunc4f, OP_store);
OP_op_T (REM, L, long, lvec2, lvec4, %);
OP_rem_T (D, 1, double, *, trunc, OP_store);
OP_rem_T (D, 2, dvec2, *, vtrunc2d, OP_store);
OP_rem_T (D, 3, double, loadvec3d, vtrunc4d, storevec3d);
OP_rem_T (D, 4, dvec4, *, vtrunc4d, OP_store);
[gamecode] Fix up MOD (%%) for integral types Use the new "1" versions of loadvec3 to get a 1 in w to avoid divide-by-zero errors, and use the correct type for longs (forgot to change i to l on the vector types).
2022-01-04 09:36:13 +00:00
// implement true modulo (python %) for integers:
// 5 mod 3 = 2
// -5 mod 3 = 1
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
// 5 mod -3 = -1
// -5 mod -3 = -2
#define OP_mod_Ti(T, n, t, l, m, s) \
case OP_MOD_##T##_##n: \
{ \
__auto_type a = l(&OPA(t)); \
__auto_type b = l(&OPB(t)); \
__auto_type c = a % b; \
/* % is really remainder and so has the same sign rules */\
/* as division: -5 % 3 = -2, so need to add b (3 here) */\
/* if c's sign is incorrect, but only if c is non-zero */\
__auto_type mask = m((a ^ b) < 0); \
mask &= m(c != 0); \
s(&OPC(t), c + (mask & b)); \
} \
break
// floating point modulo is so much easier :P (just use floor instead of trunc)
#define OP_mod_Tf(T, n, t, l, f, s) \
OP_remmod_T(MOD, T, n, t, l, f, s)
// 1 0011
OP_mod_Ti (I, 1, int, *, -, OP_store);
OP_mod_Ti (I, 2, ivec2, *, +, OP_store);
[gamecode] Fix up MOD (%%) for integral types Use the new "1" versions of loadvec3 to get a 1 in w to avoid divide-by-zero errors, and use the correct type for longs (forgot to change i to l on the vector types).
2022-01-04 09:36:13 +00:00
OP_mod_Ti (I, 3, int, loadvec3i1, +, storevec3i);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
OP_mod_Ti (I, 4, ivec4, *, +, OP_store);
OP_mod_Tf (F, 1, float, *, floorf, OP_store);
OP_mod_Tf (F, 2, vec2, *, vfloor2f, OP_store);
OP_mod_Tf (F, 3, float, loadvec3f, vfloor4f, storevec3f);
OP_mod_Tf (F, 4, vec4, *, vfloor4f, OP_store);
OP_mod_Ti (L, 1, long, *, -, OP_store);
[gamecode] Fix up MOD (%%) for integral types Use the new "1" versions of loadvec3 to get a 1 in w to avoid divide-by-zero errors, and use the correct type for longs (forgot to change i to l on the vector types).
2022-01-04 09:36:13 +00:00
OP_mod_Ti (L, 2, lvec2, *, +, OP_store);
OP_mod_Ti (L, 3, long, loadvec3l1, +, storevec3l);
OP_mod_Ti (L, 4, lvec4, *, +, OP_store);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
OP_mod_Tf (D, 1, double, *, floor, OP_store);
OP_mod_Tf (D, 2, dvec2, *, vfloor2d, OP_store);
OP_mod_Tf (D, 3, double, loadvec3d, vfloor4d, storevec3d);
OP_mod_Tf (D, 4, dvec4, *, vfloor4d, OP_store);
// 1 0100
OP_op(ADD, +);
// 1 0101
OP_op(SUB, -);
// 1 0110
OP_op_T (SHL, I, int, ivec2, ivec4, <<);
OP_op_T (SHL, L, long, lvec2, lvec4, <<);
case OP_EQ_S:
case OP_LT_S:
case OP_GT_S:
case OP_CMP_S:
case OP_GE_S:
case OP_LE_S:
{
int cmp = strcmp (PR_GetString (pr, OPA(string)),
PR_GetString (pr, OPB(string)));
switch (st_op) {
[gamecode] Make string ops mostly conform with bools The compare/ne operator returns "random" -ve, 0, +ve values (really, just the numerical difference between the chars of the strings), but all the rest return -1 for true and 0 for false, as with the rest of the comparison operators.
2022-01-14 13:44:08 +00:00
case OP_EQ_S: cmp = -(cmp == 0); break;
case OP_LT_S: cmp = -(cmp < 0); break;
case OP_GT_S: cmp = -(cmp > 0); break;
case OP_GE_S: cmp = -(cmp >= 0); break;
case OP_LE_S: cmp = -(cmp <= 0); break;
case OP_CMP_S: break;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
default: break;
}
OPC(int) = cmp;
}
break;
case OP_ADD_S:
OPC(string) = PR_CatStrings(pr, PR_GetString (pr, OPA(string)),
PR_GetString (pr, OPB(string)));
break;
case OP_NOT_S:
[gamecode] Make string ops mostly conform with bools The compare/ne operator returns "random" -ve, 0, +ve values (really, just the numerical difference between the chars of the strings), but all the rest return -1 for true and 0 for false, as with the rest of the comparison operators.
2022-01-14 13:44:08 +00:00
OPC(int) = -(!OPA(string) || !*PR_GetString (pr, OPA(string)));
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
// 1 0111
[gamecode] Clean up some opcode names While working on the new opcode table, I decided a lot of the names were not to my liking. Part of the problem was the earlier clash with the v6p opcode names, but that has been resolved via the v6p tag.
2022-01-05 10:04:43 +00:00
OP_op_T (ASR, I, int, ivec2, ivec4, >>);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
OP_op_T (SHR, u, uint, uivec2, uivec4, >>);
[gamecode] Clean up some opcode names While working on the new opcode table, I decided a lot of the names were not to my liking. Part of the problem was the earlier clash with the v6p opcode names, but that has been resolved via the v6p tag.
2022-01-05 10:04:43 +00:00
OP_op_T (ASR, L, long, lvec2, lvec4, >>);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
OP_op_T (SHR, U, ulong, ulvec2, ulvec4, >>);
// 1 1000
OP_op_T (BITAND, I, int, ivec2, ivec4, &);
OP_op_T (BITOR, I, int, ivec2, ivec4, |);
OP_op_T (BITXOR, I, int, ivec2, ivec4, ^);
OP_uop_T (BITNOT, I, int, ivec2, ivec4, ~);
// 1 1001
[gamecode] Add tests for unsigned comparisons And fix the implementation: I had used the wrong macro.
2022-01-11 04:00:54 +00:00
OP_cmp_T (LT, u, int, ivec2, ivec4, <, uint, uivec2, uivec4);
[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
case OP_JUMP_A:
case OP_JUMP_B:
case OP_JUMP_C:
case OP_JUMP_D:
pr->pr_xstatement = pr_jump_mode (pr, st, st_op - OP_JUMP_A);
st = pr->pr_statements + pr->pr_xstatement;
break;
OP_cmp_T (LT, U, long, lvec2, lvec4, <, ulong, ulvec2, ulvec4);
case OP_RETURN:
[gamecode] Make return support 32 words This took interpreting the lower 5 bits of operand c as size - 1, and 0xffff as void (0 words).
2022-01-17 07:54:27 +00:00
int ret_size = (st->c & 0x1f) + 1; // up to 32 words
if (st->c != 0xffff) {
[gamecode] Make return use same addressing as other ops This makes return consistent with load, store, etc, though its addressing mode is encoded in bits 5 and 6 of c rather than the opcode. It turns out I had no tests for any of return's addressing modes other than basic def references, so no tests needed changing.
2022-01-26 00:51:11 +00:00
mm = pr_address_mode (pr, st, st->c >> 5);
[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
memcpy (&R_INT (pr), mm, ret_size * sizeof (*op_a));
}
pr->pr_xfunction->profile += profile - startprofile;
startprofile = profile;
PR_LeaveFunction (pr, pr->pr_depth == exitdepth);
st = pr->pr_statements + pr->pr_xstatement;
if (pr->pr_depth== exitdepth) {
if (pr->pr_trace && pr->pr_depth <= pr->pr_trace_depth) {
pr->pr_trace = false;
}
goto exit_program;
}
break;
case OP_CALL_B:
case OP_CALL_C:
case OP_CALL_D:
[gamecode] Correct call's mode selection Call's operand c is used to specify where the return value of the function is to be stored. This gets both the correct function being called, and the value being returned correctly. Test still fails due to the stack restoration issue.
2022-01-17 05:29:14 +00:00
mm = pr_call_mode (pr, st, st_op - OP_CALL_B + 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
function = mm->func_var;
pr->pr_argc = 0;
// op_c specifies the location for the return value if any
pr->pr_xfunction->profile += profile - startprofile;
startprofile = profile;
[gamecode] Preserve the return pointer across calls This required delaying the setting of the return pointer by call until after the current pointer had been saved, and thus passing the desired pointer into PR_CallFunction (which does have some advantages for C functions calling progs functions, but some dangers too (should ensure a 128 byte (32 word) buffer when calling untrusted code (which is any, really)).
2022-01-17 10:12:28 +00:00
PR_CallFunction (pr, function, op_c);
[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
st = pr->pr_statements + pr->pr_xstatement;
break;
// 1 1010
OP_cmp_T (GT, u, int, ivec2, ivec4, >, uint, uivec2, uivec4);
[gamecode] Clean up the conversion instructions Float bit-ops as well. Also, add q*v4 and v4*q instructions. There are currently 48 free opcodes, and I might remove the scale instructions, but they could be useful as expanding a single float to a vector would take 3 instructions (copy to temp, swizzle-expand temp, multiply, vs just scale).
2022-01-03 13:54:34 +00:00
case OP_SWIZZLE_F:
OPC(ivec4) = pr_swizzle_f (OPA(ivec4), st->b);
break;
[gamecode] Implement the scale instructions Both float 2,3,4 vectors and double 2,3,4 vectors (1 would be just a copy of the mul instructions). This completes the currently planned instructions. Now for testing.
2022-01-10 08:05:57 +00:00
case OP_SCALE_F_2:
OPC(vec2) = OPA(vec2) * OPB(float);
break;
case OP_SCALE_F_3:
VectorScale (&OPA(float), OPB(float), &OPC(float));
break;
case OP_SCALE_F_4:
OPC(vec4) = OPA(vec4) * OPB(float);
break;
[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_cmp_T (GT, U, long, lvec2, lvec4, >, ulong, ulvec2, ulvec4);
[gamecode] Clean up the conversion instructions Float bit-ops as well. Also, add q*v4 and v4*q instructions. There are currently 48 free opcodes, and I might remove the scale instructions, but they could be useful as expanding a single float to a vector would take 3 instructions (copy to temp, swizzle-expand temp, multiply, vs just scale).
2022-01-03 13:54:34 +00:00
case OP_SWIZZLE_D:
OPC(lvec4) = pr_swizzle_d (OPA(lvec4), st->b);
break;
[gamecode] Implement the scale instructions Both float 2,3,4 vectors and double 2,3,4 vectors (1 would be just a copy of the mul instructions). This completes the currently planned instructions. Now for testing.
2022-01-10 08:05:57 +00:00
case OP_SCALE_D_2:
OPC(dvec2) = OPA(dvec2) * OPB(double);
break;
case OP_SCALE_D_3:
VectorScale (&OPA(double), OPB(double), &OPC(double));
break;
case OP_SCALE_D_4:
OPC(dvec4) = OPA(dvec4) * OPB(double);
break;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
// 1 1011
[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
case OP_CROSS_F:
{
pr_vec4_t a = loadvec3f (&OPA(float));
pr_vec4_t b = loadvec3f (&OPB(float));
pr_vec4_t c = crossf (a, b);
storevec3f (&OPC(float), c);
}
break;
case OP_CDOT_F:
OPC(vec2) = dot2f (OPA(vec2), OPB(vec2));
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
[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
case OP_VDOT_F:
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +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
vec_t d = DotProduct (&OPA(float),
&OPB(float));
VectorSet (d, d, d, &OPC(float));
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
}
break;
[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
case OP_QDOT_F:
OPC(vec4) = dotf (OPA(vec4), OPB(vec4));
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
[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
case OP_CMUL_F:
OPC(vec2) = cmulf (OPA(vec2), OPB(vec2));
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
[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
case OP_QVMUL_F:
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +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
pr_vec4_t v = loadvec3f (&OPB(float));
v = qvmulf (OPA(vec4), v);
storevec3f (&OPC(float), v);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
}
break;
[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
case OP_VQMUL_F:
{
pr_vec4_t v = loadvec3f (&OPA(float));
v = vqmulf (v, OPB(vec4));
storevec3f (&OPC(float), v);
}
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
[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
case OP_QMUL_F:
OPC(vec4) = qmulf (OPA(vec4), OPB(vec4));
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
[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
case OP_CROSS_D:
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +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
pr_dvec4_t a = loadvec3d (&OPA(double));
pr_dvec4_t b = loadvec3d (&OPB(double));
pr_dvec4_t c = crossd (a, b);
storevec3d (&OPC(double), c);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
}
break;
[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
case OP_CDOT_D:
OPC(dvec2) = dot2d (OPA(dvec2), OPB(dvec2));
break;
case OP_VDOT_D:
{
double d = DotProduct (&OPA(double),
&OPB(double));
VectorSet (d, d, d, &OPC(double));
}
break;
case OP_QDOT_D:
OPC(dvec4) = dotd (OPA(dvec4), OPB(dvec4));
break;
case OP_CMUL_D:
OPC(dvec2) = cmuld (OPA(dvec2), OPB(dvec2));
break;
case OP_QVMUL_D:
{
pr_dvec4_t v = loadvec3d (&OPB(double));
v = qvmuld (OPA(dvec4), v);
storevec3d (&OPC(double), v);
}
break;
case OP_VQMUL_D:
{
pr_dvec4_t v = loadvec3d (&OPA(double));
v = vqmuld (v, OPB(dvec4));
storevec3d (&OPC(double), v);
}
break;
case OP_QMUL_D:
OPC(dvec4) = qmuld (OPA(dvec4), OPB(dvec4));
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
// 1 1100
[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
OP_op_T (BITAND, L, long, lvec2, lvec4, &);
OP_op_T (BITOR, L, long, lvec2, lvec4, |);
OP_op_T (BITXOR, L, long, lvec2, lvec4, ^);
OP_uop_T (BITNOT, L, long, lvec2, lvec4, ~);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
// 1 1101
[gamecode] Add tests for unsigned comparisons And fix the implementation: I had used the wrong macro.
2022-01-11 04:00:54 +00:00
OP_cmp_T (GE, u, int, ivec2, ivec4, >=, uint, uivec2, uivec4);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
case OP_MOVE_I:
memmove (op_c, op_a, st->b * sizeof (pr_type_t));
break;
case OP_MOVE_P:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
memmove (pr->pr_globals + OPC(ptr), pr->pr_globals + OPA(ptr),
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
OPB(uint) * sizeof (pr_type_t));
break;
case OP_MOVE_PI:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
memmove (pr->pr_globals + OPC(ptr), pr->pr_globals + OPA(ptr),
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
st->b * sizeof (pr_type_t));
break;
[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
case OP_STATE_ft:
{
int self = *pr->globals.self;
int nextthink = pr->fields.nextthink + self;
int frame = pr->fields.frame + self;
int think = pr->fields.think + self;
float time = *pr->globals.ftime + 0.1;
pr->pr_edict_area[nextthink].float_var = time;
pr->pr_edict_area[frame].float_var = OPA(float);
pr->pr_edict_area[think].func_var = op_b->func_var;
[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] Clean up the conversion instructions Float bit-ops as well. Also, add q*v4 and v4*q instructions. There are currently 48 free opcodes, and I might remove the scale instructions, but they could be useful as expanding a single float to a vector would take 3 instructions (copy to temp, swizzle-expand temp, multiply, vs just scale).
2022-01-03 13:54:34 +00:00
break;
[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_cmp_T (GE, U, long, lvec2, lvec4, >=, ulong, ulvec2, ulvec4);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
case OP_MEMSET_I:
[gamecode] Use pr_memset instead of memset This keeps things inline and matches the quakec exec loop. Also removes the need to calculate the size.
2022-01-03 05:45:12 +00:00
pr_memset (op_c, OPA(int), st->b);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
case OP_MEMSET_P:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pr_memset (pr->pr_globals + OPC(ptr), OPA(int), OPB(uint));
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
case OP_MEMSET_PI:
[gamecode] Be more consistent with access types Eg, pointers via ptr, entities via entity, etc.
2022-01-18 06:50:32 +00:00
pr_memset (pr->pr_globals + OPC(ptr), OPA(int), st->b);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
break;
[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
case OP_STATE_ftt:
{
int self = *pr->globals.self;
int nextthink = pr->fields.nextthink + self;
int frame = pr->fields.frame + self;
int think = pr->fields.think + self;
float time = *pr->globals.ftime + OPC(float);
pr->pr_edict_area[nextthink].float_var = time;
pr->pr_edict_area[frame].float_var = OPA(float);
pr->pr_edict_area[think].func_var = op_b->func_var;
}
[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
break;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
// 1 1110
[gamecode] Add tests for unsigned comparisons And fix the implementation: I had used the wrong macro.
2022-01-11 04:00:54 +00:00
OP_cmp_T (LE, u, int, ivec2, ivec4, <=, uint, uivec2, uivec4);
[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
case OP_IFZ:
if (!OPC(int)) {
pr->pr_xstatement = pr_jump_mode (pr, st, 0);
st = pr->pr_statements + pr->pr_xstatement;
}
break;
case OP_IFB:
if (OPC(int) < 0) {
pr->pr_xstatement = pr_jump_mode (pr, st, 0);
st = pr->pr_statements + pr->pr_xstatement;
}
break;
case OP_IFA:
if (OPC(int) > 0) {
pr->pr_xstatement = pr_jump_mode (pr, st, 0);
st = pr->pr_statements + pr->pr_xstatement;
}
break;
[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
case OP_STATE_dt:
[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
{
int self = *pr->globals.self;
int nextthink = pr->fields.nextthink + self;
int frame = pr->fields.frame + self;
int think = pr->fields.think + self;
[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
double time = *pr->globals.dtime + 0.1;
*(double *) (&pr->pr_edict_area[nextthink]) = time;
[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
pr->pr_edict_area[frame].int_var = OPA(int);
[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
pr->pr_edict_area[think].func_var = op_b->func_var;
}
break;
OP_cmp_T (LE, U, long, lvec2, lvec4, <=, ulong, ulvec2, ulvec4);
case OP_IFNZ:
if (OPC(int)) {
pr->pr_xstatement = pr_jump_mode (pr, st, 0);
st = pr->pr_statements + pr->pr_xstatement;
}
break;
case OP_IFAE:
if (OPC(int) >= 0) {
pr->pr_xstatement = pr_jump_mode (pr, st, 0);
st = pr->pr_statements + pr->pr_xstatement;
}
break;
case OP_IFBE:
if (OPC(int) <= 0) {
pr->pr_xstatement = pr_jump_mode (pr, st, 0);
st = pr->pr_statements + pr->pr_xstatement;
}
break;
[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
case OP_STATE_dtt:
[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
{
int self = *pr->globals.self;
int nextthink = pr->fields.nextthink + self;
int frame = pr->fields.frame + self;
int think = pr->fields.think + self;
[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
double time = *pr->globals.dtime + OPC(double);
*(double *) (&pr->pr_edict_area[nextthink]) = time;
[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
pr->pr_edict_area[frame].int_var = OPA(int);
[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
pr->pr_edict_area[think].func_var = op_b->func_var;
}
break;
// 1 1111
case OP_LEA_A:
[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
case OP_LEA_B:
[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
case OP_LEA_C:
case OP_LEA_D:
mm = pr_address_mode (pr, st, (st_op - OP_LEA_A));
op_c->pointer_var = mm - pr->pr_globals;
break;
case OP_QV4MUL_F:
OPC(vec4) = qvmulf (OPA(vec4), OPB(vec4));
break;
[gamecode] Clean up some opcode names While working on the new opcode table, I decided a lot of the names were not to my liking. Part of the problem was the earlier clash with the v6p opcode names, but that has been resolved via the v6p tag.
2022-01-05 10:04:43 +00:00
case OP_V4QMUL_F:
[gamecode] Clean up the conversion instructions Float bit-ops as well. Also, add q*v4 and v4*q instructions. There are currently 48 free opcodes, and I might remove the scale instructions, but they could be useful as expanding a single float to a vector would take 3 instructions (copy to temp, swizzle-expand temp, multiply, vs just scale).
2022-01-03 13:54:34 +00:00
OPC(vec4) = vqmulf (OPA(vec4), OPB(vec4));
[gamecode] Implement 4-component 32-bit swizzle The swizzle instruction is very powerful in that in can do any of the 256 permutations of xyzw, optionally negate any combination of the resulting components, and zero any combination of the result components (even all). This means the one instruction can take care of any actual swizzles, conjugation for complex and quaternion values, zeroing vectors (not that it's the only way), and probably other weird things. The python file was used to generate the jump table and actual swizzle code.
2022-01-03 10:30:32 +00:00
break;
[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
case OP_QV4MUL_D:
OPC(dvec4) = qvmuld (OPA(dvec4), OPB(dvec4));
break;
[gamecode] Clean up some opcode names While working on the new opcode table, I decided a lot of the names were not to my liking. Part of the problem was the earlier clash with the v6p opcode names, but that has been resolved via the v6p tag.
2022-01-05 10:04:43 +00:00
case OP_V4QMUL_D:
[gamecode] Clean up the conversion instructions Float bit-ops as well. Also, add q*v4 and v4*q instructions. There are currently 48 free opcodes, and I might remove the scale instructions, but they could be useful as expanding a single float to a vector would take 3 instructions (copy to temp, swizzle-expand temp, multiply, vs just scale).
2022-01-03 13:54:34 +00:00
OPC(dvec4) = vqmuld (OPA(dvec4), OPB(dvec4));
[gamecode] Implement 64-bit swizzles See commit for 32-bit swizzles.
2022-01-03 10:55:27 +00:00
break;
[gamecode] Add single-component float bitop instructions These add legacy support for basic float bitops (& | ^ ~). Avoiding the instructions would require tot only the source to be converted, but also the servers (as they do access those fields), and this seemed to be too much.
2022-02-06 10:40:16 +00:00
case OP_BITAND_F:
OPC(float) = (int) OPA(float) & (int) OPB(float);
break;
case OP_BITOR_F:
OPC(float) = (int) OPA(float) | (int) OPB(float);
break;
case OP_BITXOR_F:
OPC(float) = (int) OPA(float) ^ (int) OPB(float);
break;
case OP_BITNOT_F:
OPC(float) = ~ (int) OPA(float);
break;
[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
case OP_CONV:
switch (st->b) {
#include "libs/gamecode/pr_convert.cinc"
default:
PR_RunError (pr, "invalid conversion code: %04o",
st->b);
}
break;
case OP_WITH:
pr_with (pr, st);
break;
[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
// 1110 spare
[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
#define OP_hop2(vec, op) ((vec)[0] op (vec)[1])
#define OP_hop3(vec, op) ((vec)[0] op (vec)[1] op (vec)[2])
#define OP_hop4(vec, op) ((vec)[0] op (vec)[1] op (vec)[2] op (vec)[3])
[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
case OP_HOPS:
switch (st->b) {
[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
#include "libs/gamecode/pr_hops.cinc"
[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
default:
PR_RunError (pr, "invalid hops code: %04o",
st->b);
}
break;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
default:
[gamecode] Create a mask for extracting the opcode Got tired of copying the full thing around.
2022-01-03 08:54:54 +00:00
PR_RunError (pr, "Bad opcode o%03o", st->op & OP_MASK);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
}
[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
if (pr->watch && pr->watch->int_var != old_val.int_var) {
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
if (!pr->wp_conditional
[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
|| pr->watch->int_var == pr->wp_val.int_var) {
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
if (pr->debug_handler) {
pr->debug_handler (prd_watchpoint, 0, pr->debug_data);
} else {
PR_RunError (pr, "watchpoint hit: %d -> %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
old_val.int_var, pr->watch->int_var);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
}
}
[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
old_val.int_var = pr->watch->int_var;
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
}
}
exit_program:
}
[gamecode] Split out the old quake c execution loop There is no reasonable way (due to hardware-enforced alignment issues) to simply convert old bytecode to new (probably best done with an off-line tool, preferably just recompiling when I get qfcc up to the job), so both loops will need to be present. This just moves the original loop into its own function in order to make it easy to bring in the new (and iron out integration issues).
2022-01-02 11:16:45 +00:00
/*
PR_ExecuteProgram
The interpretation main loop
*/
VISIBLE void
[gamecode] Rename func_t to pr_func_t Even more consistency.
2022-01-18 06:32:43 +00:00
PR_ExecuteProgram (progs_t *pr, pr_func_t fnum)
[gamecode] Split out the old quake c execution loop There is no reasonable way (due to hardware-enforced alignment issues) to simply convert old bytecode to new (probably best done with an off-line tool, preferably just recompiling when I get qfcc up to the job), so both loops will need to be present. This just moves the original loop into its own function in order to make it easy to bring in the new (and iron out integration issues).
2022-01-02 11:16:45 +00:00
{
Sys_PushSignalHook (signal_hook, pr);
Sys_PushErrorHandler (error_handler, pr);
if (pr->debug_handler) {
pr->debug_handler (prd_subenter, &fnum, pr->debug_data);
}
int exitdepth = pr->pr_depth;
[gamecode] Preserve the return pointer across calls This required delaying the setting of the return pointer by call until after the current pointer had been saved, and thus passing the desired pointer into PR_CallFunction (which does have some advantages for C functions calling progs functions, but some dangers too (should ensure a 128 byte (32 word) buffer when calling untrusted code (which is any, really)).
2022-01-17 10:12:28 +00:00
if (!PR_CallFunction (pr, fnum, pr->pr_return)) {
[gamecode] Split out the old quake c execution loop There is no reasonable way (due to hardware-enforced alignment issues) to simply convert old bytecode to new (probably best done with an off-line tool, preferably just recompiling when I get qfcc up to the job), so both loops will need to be present. This just moves the original loop into its own function in order to make it easy to bring in the new (and iron out integration issues).
2022-01-02 11:16:45 +00:00
// called a builtin instead of progs code
goto exit_program;
}
[gamecode] Add PROG_V6P_VERSION and bump PROG_VERSION This allows the VM to select the right execution loop and qfcc currently still produces only the old IS (it doesn't know how to deal with the new IS yet)
2022-01-03 04:56:43 +00:00
if (pr->progs->version < PROG_VERSION) {
[gamecode] Split out the old quake c execution loop There is no reasonable way (due to hardware-enforced alignment issues) to simply convert old bytecode to new (probably best done with an off-line tool, preferably just recompiling when I get qfcc up to the job), so both loops will need to be present. This just moves the original loop into its own function in order to make it easy to bring in the new (and iron out integration issues).
2022-01-02 11:16:45 +00:00
pr_exec_quakec (pr, exitdepth);
[gamecode] Add a new Ruamoko instruction set When it's finalized (most of the conversion operations will go, probably the float bit ops, maybe (very undecided) the 3-component vector ops, and likely the CALLN ops), this will be the actual instruction set for Ruamoko. Main features: - Significant reduction in redundant instructions: no more multiple opcodes to move the one operand size. - load, store, push, and pop share unified addressing mode encoding (with the exception of mode 0 for load as that is redundant with mode 0 for store, thus load mode 0 gives quick access to entity.field). - Full support for both 32 and 64 bit signed integer, unsigned integer, and floating point values. - SIMD for 1, 2, (currently) 3, and 4 components. Transfers support up to 128-bit wide operations (need two operations to transfer a full 4-component double/long vector), but all math operations support both 128-bit (32-bit components) and 256-bit (64-bit components) vectors. - "Interpreted" operations for the various vector sizes: complex dot and multiplication, 3d vector dot and cross product, quaternion dot and multiplication, along with qv and vq shortcuts. - 4-component swizzles for both sizes (not yet implemented, but the instructions are allocated), with the option to zero or negate (thus conjugates for complex and quaternion values) individual components. - "Based offsets": all relevant instructions include base register indices for all three operands allowing for direct access to any of four areas (eg, current entity, current stack frame, Objective-QC self, ...) instructions to set a register and push/pop the four registers to/from the stack. Remaining work: - Implement swizzle operations and a few other stragglers. = Make a decision about conversion operations (if any instructions remain, they'll be just single-component (at 14 meaningful pairs, that's a lot of instructions to waste on SIMD versions). - Decide whether to keep CALL1-CALL8: probably little point in supporting two different calling conventions, and it would free up another eight instructions. - Unit tests for the instructions. - Teach qfcc to generate code for the new instruction set (hah, biggest job, I'm sure, though hopefully not as crazy as the rewrite eleven years ago).
2022-01-02 14:15:15 +00:00
} else {
pr_exec_ruamoko (pr, exitdepth);
[gamecode] Split out the old quake c execution loop There is no reasonable way (due to hardware-enforced alignment issues) to simply convert old bytecode to new (probably best done with an off-line tool, preferably just recompiling when I get qfcc up to the job), so both loops will need to be present. This just moves the original loop into its own function in order to make it easy to bring in the new (and iron out integration issues).
2022-01-02 11:16:45 +00:00
}
Allow Sys_Error to be hooked. This makes debugging builtins that wrap normal functions a little easier by giving a progs dump when such an error occurs.
2016-01-03 14:04:00 +00:00
exit_program:
[gamecode] Add VM enter/exit events And rename prd_exit to prd_terminate (the idea is the host will terminate the VM). This makes it possible for the debugger to pause the VM before any code, even a builtin function, is executed. Breaks the debugger source window, but only because it's not updating on file change (I think).
2020-03-26 03:30:32 +00:00
if (pr->debug_handler) {
pr->debug_handler (prd_subexit, 0, pr->debug_data);
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
Improve handling of pr_argc It is now set to 0 when progs are loaded and every time PR_ExecuteProgram() returns. This takes care of the default case, but when setting parameters, pr_argc needs to be set correctly in case a vararg function is called.
2020-02-25 08:28:32 +00:00
pr->pr_argc = 0;
Allow Sys_Error to be hooked. This makes debugging builtins that wrap normal functions a little easier by giving a progs dump when such an error occurs.
2016-01-03 14:04:00 +00:00
Sys_PopErrorHandler ();
Sys_PopSignalHook ();
initial checkin of most recent newtree and nuq(?) source
2001-02-19 21:15:25 +00:00
}
Reference in a new issue Copy permalink