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
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
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
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
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: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
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
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?
>
>
> "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).
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,
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).
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
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
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?
> >
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
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
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 Saturday 21 April 2007 22:49, Patrick Rutkowski wrote:
> I'm not looking at it for any particular reason. My interest in
> helping work on parrot began only yesterday. First I spent last night
> reading a few pdds. Then this morning in an effort to familiarize
> myself with the implementation d
On Apr 21, 2007, at 8:24 PM, chromatic wrote:
Parrot_alloc_context() performs some calculations about the number of
registers used to determine how much memory to allocate:
const size_t size_n = sizeof (FLOATVAL) * n_regs_used[REGNO_NUM];
const size_t size_nip = size_n +
sizeof
On Apr 22, 2007, at 12:59 AM, chromatic wrote:
On Saturday 21 April 2007 21:26, Patrick Rutkowski wrote:
I was just reading (s/reading/trying to read/) the same routine
earlier this morning. I'm glad to see that I'm not alone in my
confusion.
Me too, but I'm now seriously wondering *why* yo
On Saturday 21 April 2007 21:26, Patrick Rutkowski wrote:
> I was just reading (s/reading/trying to read/) the same routine
> earlier this morning. I'm glad to see that I'm not alone in my
> confusion.
Me too, but I'm now seriously wondering *why* you were reading it. It's not
the lightest, bri
I was just reading (s/reading/trying to read/) the same routine
earlier this morning. I'm glad to see that I'm not alone in my
confusion.
Is it possible to track down the author of those odd bit-shifting
statements in order to ask him about it directly? I would do it myself
but I'm still learning
23 matches
Mail list logo