On Thu, Oct 24, 2002 at 06:16:55PM -0400, Jason Gloudon wrote:
> On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote:
> > It shouldn't at all. It does the check once, when parrot starts up.
>
> It will. If you read the following paragraph I explained why it will be slower,
> and it has nothing to do with how often the check is performed.
>
> STACK_DIR is a compile time constant, so the multiplies in the following code
> are eliminated by the compiler if it does any optimization. By making
> STACK_DIR a variable, the compiler is no longer able to do this and has to
> generate code to do multiplies.
>
> for (cur_var_ptr = lo_var_ptr;
> (ptrdiff_t)(cur_var_ptr * PARROT_STACK_DIR) <
> (ptrdiff_t)(hi_var_ptr * PARROT_STACK_DIR);
> cur_var_ptr = (size_t)( (ptrdiff_t)cur_var_ptr +
> PARROT_STACK_DIR * PARROT_PTR_ALIGNMENT )
What is wrong with any of
1: Duplicating the above loop (which isn't large), one for upwards stack,
the other for downwards stack, and switching (outside) between the two
based on an if statement on a global stack direction variable.
(Globals bad, I know, but I assume that no-one has yet made an
INTERCAL-eqse OS where the stack direction can change between threads of
the same process)
That gets the if test outside the loop, and keeps the loop construction
optimisable at compile time
2: Pulling all of trace_system_stack out into its own source file, compiling
it twice (once for up, once for down) with different names, and choosing the
correct function pointer once based on a run time test
3: Keeping things as it is, and having miniparrot #define PARROT_STACK_DIR
as a global variable containing the (run time determined) stack direction,
whereas configured parrot #defines it as -1 or +1
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
