I'd have to agree with Andrew. With only 32 registers of each type in
Parrot (the last time I checked) using most of them for function arguments
would cause much needless register copying within each function.
Surely 8 registers of each type would be more than sufficient for
function
Andrew J Bromage [EMAIL PROTECTED] writes:
G'day all.
On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
I don't think I and Andrew were saying we shouldn't do caller-save,
we were just discussing that the calling convention (read
activation record of a subroutine) should
So, I was thinking about how symbol tables are going to work, and I
remembered that Dan had said that he wanted hashes to preserve their
insertion order on print out.
Which led me to think that it'd be really nice if there was some way
of addressing hashes with integers to get the 'nth thing'
Actually, I _was_ saying we shouldn't do caller-save (except
possibly for a small number of registers designated for the
purpose).
Remember that the caller only has to save the stuff that is important
to it, after all, anything that might be of importance to *its*
callers will already
G'day all.
On Mon, Apr 29, 2002 at 07:57:08AM +0100, Piers Cawley wrote:
Remember that the caller only has to save the stuff that is important
to it, after all, anything that might be of importance to *its*
callers will already have been saved. If the callee saves then it's
going to be
Hi, again!
Sorry but I didn't have the time to read all I should about parrot, but
this question can be usefull to know if I should continue looking at it,
or not... is parrot ready (or will be, soon) to use external libraries?
And another simple... can parrot be used as a filter? assembler
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.130
diff -u -d -u -r1.130 core.ops
--- core.ops24 Apr 2002 20:31:39 - 1.130
+++ core.ops29 Apr 2002 14:00:28 -
-2823,7 +2823,7
Herewith the first set of patches to the memory allocation routines.
There is no new functionality here yet; basically I have been working on
trying to remove some of the code that is duplicated between the various
pools, before even more copies get made for the new stuff.
The result is some
At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
G'day all.
On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
We're going caller-save. I think I made this declaration before, but
now it's backed up with pure PDD goodness. :)
The first thing to realise is that this violates
Dan Sugalski
[EMAIL
At 4:44 PM +0200 4/29/02, Peter Gibbs wrote:
Herewith the first set of patches to the memory allocation routines.
There is no new functionality here yet; basically I have been working on
trying to remove some of the code that is duplicated between the various
pools, before even more copies get
I just started playing with Parrot assembly and it looks like I have
found a bug with entrytype OP.
This test case causes segfault:
save I1
entrytype I2, 0
Another test case
save I1
entrytype I2, -1
This one causes 'Stack Depth wrong' error instead of getting
On Sun, Apr 28, 2002 at 10:08:01PM -0400, Jeff wrote:
And a long time coming...
An assembler supporting keyed aggregates. Because of the current lack of
macro support (that will be added in a few days), it's not built by
default and isn't invoked in the test suite.
Yay! Thank you.
Since
I suspect the bug may be in my understanding of the memory
management API, though. If I want to maintain a linked-list of my own
objects, how do I do it? If I carve out my objects (hash buckets) from
a Buffer, then GC would keep moving them around and breaking the
-next link pointers.
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
I suspect the bug may be in my understanding of the memory
management API, though. If I want to maintain a linked-list of my own
objects, how do I do it? If I carve out my objects (hash buckets) from
a Buffer, then GC would
Btw, this is only a weak guess about what's going on, because the
corruption I'm seeing isn't even in the linked list nodes. It only
happens with GC_DEBUG, but it's not an infant mortality bug.
GC_DEBUG adds extra calls to do_dod_run (infant mortality), and
do_collect. You're
Steve Fink:
The assembler needs to be taught about the PMC constants:
I disagree. Once you start adding assembler functions to make it easier
for humans to use, you won't stop. I consider the assembler a tool for
machines to use. But if you want to do it, here's a patch.
--- newasm~ Mon
On Mon, Apr 29, 2002 at 07:34:22PM +0100, Simon Cozens wrote:
Steve Fink:
The assembler needs to be taught about the PMC constants:
I disagree. Once you start adding assembler functions to make it easier
for humans to use, you won't stop. I consider the assembler a tool for
machines to
Steve Fink [EMAIL PROTECTED] writes:
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
- Make an array of buffer data, in order of insertion into the hashtable.
set pmc_pointer and buffer_ptr and let the GC rip through it.
- The hashtable itself just uses indices into this array.
On Mon, Apr 29, 2002 at 09:42:46PM +0100, Piers Cawley wrote:
Steve Fink [EMAIL PROTECTED] writes:
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
- Make an array of buffer data, in order of insertion into the hashtable.
set pmc_pointer and buffer_ptr and let the GC rip
OO code is full of subs which a) are called very often and b) look
like this:
sub code
{
my $self = shift;
return $self-{CODE};
}
sub body
{
my $self = shift;
if (_) {
$self-{BODY} = shift;
}
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
G'day all.
On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
We're going
Ilya Martynov wrote:
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.130
diff -u -d -u -r1.130 core.ops
--- core.ops24 Apr 2002 20:31:39 - 1.130
+++ core.ops29 Apr 2002
On Mon, 29 Apr 2002 18:58:18 -0400, Jeff [EMAIL PROTECTED] said:
J Ilya Martynov wrote:
Index: core.ops
[..snip..]
J Applied, thanks.
I've just found other POD bugs in core.ops
Index: core.ops
===
RCS file:
G'day all.
On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
Understood.
Isn't compiler convienience a (the?) major issue here?
I wouldn't call it a major issue. I think of it as a constraint.
The major
25 matches
Mail list logo
