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 +
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
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
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 like it's
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 start not to understand.
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?
I'm not
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
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
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
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 the slot
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 (23).
# New Ticket Created by Steve Peters
# Please include the string: [perl #42662]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42662
The const char * f below causes failures when compiled with C++. The
patch below
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 (23).
and those sort of
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 That's just a rounding
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
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
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 right by 3?
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 of 8 is
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:
const
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
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
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. I
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: 'sum is
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 count
29 matches
Mail list logo
