Front page | perl.perl6.internals |
Postings from October 2002
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 sizeof(size_t) * >>PARROT_PTR_ALIGNMENT bytes. >> > > ptrdiff_t is not a pointer type, so cur_var_ptr + PARROT_PTR_ALIGNMENT skips > exactly PARROT_PTR_ALIGNMENT bytes. You may not be matching ( )'s quite right. Brr, yes. I checked with gdb. cur_var_ptr is incremented by PARROT_PTR_ALIGNMENT _bytes_ i.e. by 1 byte on i386. Can we really have e.g. odd aligned PMCs on stack? I don't think so. Or am I still missing something? >>As a side note: applying your patch slows down e.g. life.pasm by ~2%. >>(I really don't see why). > Are you compiling with optimization enabled ? Is the difference consistent ? W/o optimization, but consistent. > If the answer to both questions is yes, it is probably a cache effect related > to the new variable on the function stack. I doubt the slowdown is universal. > I will try to check on SPARC sometime today. leoThread Previous | Thread Next