Re: [perl #18127] [PATCH] Implicit stack direction probe

At 9:03 AM +0100 11/5/02, Leopold Toetsch wrote: Dan Sugalski wrote: At 9:41 AM +0100 10/30/02, Leopold Toetsch wrote: Jason Gloudon wrote: ... By default both compilers align stack variables at their natural alignment, so PMC pointers would normally fall on 4 byte boundaries. So, this

Re: [perl #18127] [PATCH] Implicit stack direction probe

Dan Sugalski wrote: At 9:41 AM +0100 10/30/02, Leopold Toetsch wrote: Jason Gloudon wrote: ... By default both compilers align stack variables at their natural alignment, so PMC pointers would normally fall on 4 byte boundaries. So, this someone are we (parrot itself) + language

Re: [perl #18127] [PATCH] Implicit stack direction probe

At 9:41 AM +0100 10/30/02, Leopold Toetsch wrote: Jason Gloudon wrote: ... By default both compilers align stack variables at their natural alignment, so PMC pointers would normally fall on 4 byte boundaries. However, it is also possible that someone might save a PMC pointer to an unaligned

Re: [perl #18127] [PATCH] Implicit stack direction probe

Jason Gloudon wrote: ... By default both compilers align stack variables at their natural alignment, so PMC pointers would normally fall on 4 byte boundaries. However, it is also possible that someone might save a PMC pointer to an unaligned address on the stack (I can't imagine why). We could

Re: [perl #18127] [PATCH] Implicit stack direction probe

On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote: +cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + PARROT_PTR_ALIGNMENT) When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped during stack scanning by incrementing cur_var_ptr by sizeof(size_t) *

Re: [perl #18127] [PATCH] Implicit stack direction probe

Jason Gloudon wrote: On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote: +cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + PARROT_PTR_ALIGNMENT) When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped during stack scanning by incrementing cur_var_ptr by

Re: [perl #18127] [PATCH] Implicit stack direction probe

At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote: Jason Gloudon wrote: On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote: +cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + PARROT_PTR_ALIGNMENT) When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped

Re: [perl #18127] [PATCH] Implicit stack direction probe

Jason Gloudon wrote: ptrdiff_t is not a pointer type, so cur_var_ptr + PARROT_PTR_ALIGNMENT skips exactly PARROT_PTR_ALIGNMENT bytes. I did modify your patch slightly - reversed directions (top-down is probably more common) - increment by sizeof(void*) This boost life.pasm gens from 270 -

Re: [perl #18127] [PATCH] Implicit stack direction probe

Dan Sugalski wrote: At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote: ... Can we really have e.g. odd aligned PMCs on stack? I don't think so. Or am I still missing something? There was some indication back when this was first implemented that the i386, at least when running windows, could

Re: [perl #18127] [PATCH] Implicit stack direction probe

At 4:57 PM +0100 10/29/02, Leopold Toetsch wrote: Dan Sugalski wrote: At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote: ... Can we really have e.g. odd aligned PMCs on stack? I don't think so. Or am I still missing something? There was some indication back when this was first implemented

RE: [perl #18127] [PATCH] Implicit stack direction probe

Dan Sugalski wrote: Leopold Toetsch wrote: Can we really have e.g. odd aligned PMCs on stack? the specs are available *somewhere*, and we should see about digging them up and getting a final answer one way or another. A gold mine of cpu specs: