At 1:01 PM +0100 10/25/02, Nicholas Clark wrote:
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,
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
Absolutely nothing. #3 is probably the best of the lot, as these things go.

The one issue we will have is in probing the registers, but I think we can get around that if we're willing to be sufficiently evil in places.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk


Reply via email to