I think Leo would be the best person to go to for an explanation,
especially if you plan to dramatically rework the code. He moved the
whole Parrot_alloc_context() routine from inter_create.c to
gc/register.c in r9645. Along with the move in r9645 he added the slot
variable and all of its side eff
On Sat, 21 Apr 2007 18:24:18 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> Then it calculates a slot value:
>
> const int slot = (reg_alloc + 7) >> 3;
> reg_alloc = slot << 3;
>
> This is where I start not to understand. Why reg_alloc + 7? Why
> shift left and right by 3?
To me it looks
On Sun, 22 Apr 2007 02:31:26 -0700
Mark Glines <[EMAIL PROTECTED]> wrote:
> On Sat, 21 Apr 2007 18:24:18 -0700
> chromatic <[EMAIL PROTECTED]> wrote:
> > Then it calculates a slot value:
> >
> > const int slot = (reg_alloc + 7) >> 3;
> > reg_alloc = slot << 3;
> >
> > This is where I sta
Am Sonntag, 22. April 2007 09:11 schrieb Patrick Rutkowski:
> I think Leo would be the best person to go to for an explanation,
> especially if you plan to dramatically rework the code.
> >> This is where I start not to understand. Why reg_alloc + 7? Why
> >> shift left
> >> and right by 3?
> >
Ok, so I see now that reg_alloc is rounded up to a multiple of 8 by
the following two lines:
/*code*/ const int slot = (reg_alloc + 7) >> 3;
/*code*/ reg_alloc = slot << 3;
However, this still begs the question of what the slot variable is
for. Clearly it's being used as an index into
interp
This week on the Perl 6 mailing lists
"The current pugs implementation is just translating to the old form
underneath, so it's not surprising it's a bit off. That's the sort of
thing that happens when the language designer gives the language
implementor whiplash. However, I rathe
This is in response to your being puzzled about the "*(void **)ptr"
statement. I'm going to assume that you know about void/non-void
context in C and that you're already comfortable with the standard
uses of pointers and type casting.
*(type **)ptr_to_type
gives the same effect as:
(type *)(*pt
Am Sonntag, 22. April 2007 14:40 schrieb Patrick Rutkowski:
> Ok, so I see now that reg_alloc is rounded up to a multiple of 8 by
> the following two lines:
>
>/*code*/ const int slot = (reg_alloc + 7) >> 3;
>/*code*/ reg_alloc = slot << 3;
>
> However, this still begs the question of what
> const int slot = (reg_alloc + 7) >> 3; reg_alloc = slot << 3;
> This is where I start not to understand. Why reg_alloc + 7? Why shift left
> and right by 3?
That's just a rounding up (if necessary) to a multiple of 8 (2<<3).
# New Ticket Created by "Steve Peters"
# Please include the string: [perl #42662]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42662 >
The const char * f below causes failures when compiled with C++. The
patch below swit
On Sunday 22 April 2007 08:44, Steve Peters wrote:
> The const char * f below causes failures when compiled with C++. The
> patch below switches it to a plain char *.
Thanks, applied as r18297.
-- c
Yes, I see that now, but that doesn't answer the questions.
Why did you choose reg_alloc/8 as an index into free_list?
Why does the code need to increase the size of free_list so
dramatically in the branching into the first if()?
I was also going to ask again how free_list is meant to be used,
> "JP" == Joerg Plate <[EMAIL PROTECTED]> writes:
>> const int slot = (reg_alloc + 7) >> 3; reg_alloc = slot << 3;
>> This is where I start not to understand. Why reg_alloc + 7? Why
>> shift left and right by 3?
JP> That's just a rounding up (if necessary) to a multiple of 8 (2<<3).
On Sunday 22 April 2007 14:08, Uri Guttman wrote:
> > "JP" == Joerg Plate <[EMAIL PROTECTED]> writes:
> >>
> >> const int slot = (reg_alloc + 7) >> 3; reg_alloc = slot << 3;
> >>
> >> This is where I start not to understand. Why reg_alloc + 7? Why
> >> shift left and right by 3?
>
>
Am Sonntag, 22. April 2007 22:47 schrieb Patrick Rutkowski:
> Yes, I see that now, but that doesn't answer the questions.
>
> Why did you choose reg_alloc/8 as an index into free_list?
A granualrity of 8 is of course arbitratly, could be some bigger power of 2
too.
> Why does the code need to in
Am Sonntag, 22. April 2007 23:14 schrieb chromatic:
> I figured it was a rounding, but I saw two magic numbers and didn't want to
> guess what it was.
Well, sorry. I thought the rounding was obvious. But obviously I was wrong.
Some macros for rounding up are for sure a good thing. The packfile c
On Apr 22, 2007, at 5:14 PM, chromatic wrote:
On Sunday 22 April 2007 14:08, Uri Guttman wrote:
"JP" == Joerg Plate <[EMAIL PROTECTED]> writes:
const int slot = (reg_alloc + 7) >> 3; reg_alloc = slot << 3;
This is where I start not to understand. Why reg_alloc + 7? Why
shift left and righ
Am Sonntag, 22. April 2007 23:34 schrieb Patrick Rutkowski:
> + const int slot;
> + /* round reg_alloc up to the nearest multiple of 8 */
> + reg_alloc = ((reg_alloc + 7) >> 3) << 3;
> +
> + /* reg_alloc now divides evenly by 8 because of the previous
> + rounding. A granualrity o
Well this is embarrassing.
I tested it yes, but when I tested it I had:
reg_alloc = ((reg_alloc + 7) >> 3) << 3
const int slot = reg_alloc / 8;
Then I remembered that some less friendly compilers
won't like the the declaration being after a statement.
So I pulled it out and changed it to:
cons
This is a clean up attempt.
Passes tests.
Kevin Tew
Index: src/gc/register.c
===
--- src/gc/register.c (revision 18297)
+++ src/gc/register.c (working copy)
@@ -321,6 +321,12 @@
interp->ctx.bp_ps = old->bp_ps;
}
+
+#define SL
The attached patch completely reworks Parrot_process_args. The changes
are extensive and I think they make the code much clearer. Rather than
just check it in, I thought I'd try to get feedback here to make sure
that it is clearer to everyone else and not just to myself.
This patch also fixes a f
On 4/22/07, chromatic <[EMAIL PROTECTED]> wrote:
It came in just before the release and it touched a lot of files, so I
(speaking only for myself) let it sit for a couple of days. Unfortunately,
it also came in after Steve Peters's "No C++ Keywords" patch, so it didn't
apply cleanly.
Thanks.
Andy Dougherty wrote:
On Thu, 19 Apr 2007, chromatic via RT wrote:
On Thursday 19 April 2007 11:35, Andy Dougherty wrote:
While trying to run 'make test' today, t/stm/llqueue_2.pir hung and had
to be killed manually. Trying it again, I got an out-of-memory error
The hanging behavior appears
From: "Matt Diephouse" <[EMAIL PROTECTED]>
Date: Sun, 22 Apr 2007 20:38:11 -0400
The attached patch completely reworks Parrot_process_args. The changes
are extensive and I think they make the code much clearer. Rather than
just check it in, I thought I'd try to get feedback here to
On Sunday 22 April 2007 18:35, Allison Randal wrote:
> It fails for me too (MacOSX 10.4.9, Intel Core 2 Duo), but it was marked
> as TODO for the release.
>
> t/stm/llqueueok 1/2
> # Failed (TODO) test (t/stm/llqueue.t at line 59)#
> got: ''# expected: 'su
Alek Storm <[EMAIL PROTECTED]> wrote:
On 4/19/07, Allison Randal via RT <[EMAIL PROTECTED]> wrote:
> Do you have a test case that shows where the current behavior is incorrect?
The attached test case...
Looks like either (a) you forgot to attach the patch or (b) RT ate it.
Care to try again? :
On 4/17/07, chris <[EMAIL PROTECTED]> wrote:
I am installing Parrot both on Mandriva ans Debian.
This error only occurs on Debian distrib.
./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
real_exception (severity:2 error:30): Complex: malformed string
likely reason: argument cou
On Sunday 22 April 2007 17:57, Alek Storm wrote:
> > That's as far as I've been able to trace however. The tests do pass if I
> > revert the patch. Any ideas?
>
> I think the patch exposed either a GC or SMOP bug. Here's the smallest I
> could get the test case and still have it segfault withou
chromatic wrote:
On Sunday 22 April 2007 18:35, Allison Randal wrote:
(I've been getting intermittent test
hangs with STM on various different tests for a few weeks now, and they
always go away when I run 'realclean'. And, when I set out to track them
down, they disappear.)
(For the record, th
tewk wrote:
This is a clean up attempt.
Passes tests.
Excellent! I applied tewk's patch and Patrick R's comments, then pulled
more comments out of the thread and cleaned up the code a bit (reusing
the new macros where relevant). What I ultimately ended up with (based
on which idioms were rep
30 matches
Mail list logo
