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

2002-11-06 Thread Dan Sugalski
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 "s

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

2002-11-05 Thread Leopold Toetsch
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 extensio

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

2002-11-04 Thread Dan Sugalski
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 add

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

2002-10-30 Thread Leopold Toetsch
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 a

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

2002-10-29 Thread Jason Gloudon
On Tue, Oct 29, 2002 at 12:17:55PM -0600, Garrett Goebel wrote: > 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

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

2002-10-29 Thread Garrett Goebel
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: http://www.mit.edu/afs/sipb/contrib/

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

2002-10-29 Thread Dan Sugalski
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 th

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

2002-10-29 Thread Leopold Toetsch
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

2002-10-29 Thread Leopold Toetsch
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

2002-10-29 Thread Dan Sugalski
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 during

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

2002-10-29 Thread Leopold Toetsch
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 siz

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

2002-10-29 Thread Jason Gloudon
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

2002-10-29 Thread Leopold Toetsch
Jason Gloudon (via RT) wrote: # New Ticket Created by Jason Gloudon # Please include the string: [perl #18127] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18127 > I have problems to understand the line below: (not vot

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

2002-10-28 Thread via RT
# New Ticket Created by Jason Gloudon # Please include the string: [perl #18127] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18127 > Here is what I suggested in a previous email. Always walk the stack in the same direct