Will the buffers associated with a string be managed by Parrot's memory
management, and be visible to the garbage collector ? Or will these buffers be
allocated from their own pool of memory not subject to garbage collection.
--
Jason
Using the current CVS source with perl5.6.1, the assembler runs with the
following warning:
Use of uninitialized value in numeric eq (==) at assemble.pl line 53.
53 if (($] >= 5.006) && ($PConfig{ivsize} == $PConfig{longsize}) ) {
54 %pack_type = ('i'=>'l!','n'=>'d');
55 }
I
On Sun, Sep 30, 2001 at 11:31:21AM -0400, Gregor N. Purdy wrote:
> And, BTW, the current PackFile_Constant type isn't using a union.
> It has separate members for each type of constant. This could be
> changed once things are working. There's probably a few other
> things that could use some cle
On Mon, Oct 01, 2001 at 03:37:34PM +0100, Simon Cozens wrote:
> On Sun, Sep 16, 2001 at 01:44:12PM -0400, Michael Fischer wrote:
> > Small hack to keep process_opfunc.pl from generating
> > extra return() statements.
>
> Thanks, applied.
That patch is broken or incomplete.
It breaks manual ops
On Mon, Oct 01, 2001 at 03:27:49PM +0100, Simon Cozens wrote:
> On Mon, Oct 01, 2001 at 10:23:11AM -0400, Jason Gloudon wrote:
> > What about the current macros for NUM_REG etc ?
>
> I'd probably rip 'em out too. Stops people accidentally hand hacking the .c file
>
On Tue, Oct 02, 2001 at 07:50:39AM -0400, Gregor N. Purdy wrote:
> All --
>
> > +
>s/NUM_CONST\(([^)]+)\)/interpreter->code->const_table->constants[$1]->number/g;
> > +
>s/STR_CONST\(([^)]+)\)/interpreter->code->const_table->constants[$1]->string/g;
> > +
>s/INT_CONST\(([^)]+)\)/inter
Here is the patch (again) to use the appropriate bitmask determined by
Configure for the different register chunks.
--
Jason
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.29
diff -u -
The "stacktest" patch will fail on the current CVS source, due to a bug in
push_generic_entry.
--
Jason
Index: t/op/stacks.t
===
RCS file: /home/perlcvs/parrot/t/op/stacks.t,v
retrieving revision 1.3
diff -u -r1.3 stacks.t
--- t/
On Sat, Oct 20, 2001 at 11:44:40AM -0400, Jason Gloudon wrote:
>
> The "stacktest" patch will fail on the current CVS source, due to a bug in
> push_generic_entry.
The 1-line patch to fix this was also included.
--
Jason
On Sun, Oct 21, 2001 at 07:56:08PM +0100, Simon Cozens wrote:
> On Wed, Oct 10, 2001 at 11:27:24AM +0200, Paolo Molaro wrote:
> > ... and to go a step further in sanity and maintainability, I'd suggest
> > using a structure with properly typed function pointers instead of an
> > array:
> >
> > ty
On Fri, Oct 26, 2001 at 06:54:32AM -0700, Brent Dax wrote:
> What if I want my compiler to be lazy? Do you have the right to punish
> me for my laziness by making me add constant folding to my optimizer (or
> perhaps making me *write* an optimizer just to do constant folding)?
You don't have to
On Sun, Nov 11, 2001 at 08:57:15PM -0800, Brent Dax wrote:
> You get the idea? And as for multidimensional stuff, what's wrong with:
>
> fetchlex P1, "@lol"
> fetchary P2, P1, 1
> fetchary P3, P2, 2
> #...
Consider (from exegesis 2):
my int @hit_count is dim(100,366,24
On Mon, Nov 12, 2001 at 11:59:08PM -0500, Michael L Maraist wrote:
> 2)
> Can we assume that a "buffer object" is ONLY accessible by a single
> reverse-path-to-PMC? PMC's or array-buffers can point to other PMC's, so
> it's possible to have multiple paths from the root to an object, but I'm
>
On Tue, Nov 13, 2001 at 06:05:51PM -0500, Michael L Maraist wrote:
> treat them separately. We're already having to treat handles differently
> than buffer-objects. I'm also wanting to segregate lists of leaf-buffers,
Ok here is a reference to the thread that mentioned copy-on-write for shar
On Wed, Nov 14, 2001 at 01:11:54PM -0500, Dan Sugalski wrote:
> >Correction (and please correct this correction if I'm wrong):
> >An INTVAL should never get a /native/ pointer in it. However, when we do
> >relitave or absolute jumps in parrot code, the destination is an INTVAL.
Is this really g
On Thu, Nov 15, 2001 at 08:18:32PM +, Simon Cozens wrote:
> I'm under the impression that the signature of the add method should be
>
> void foo (interpreter, destination, left, right)
>
> Shouldn't the above be more like:
>
> P1->vtable->vtable_funcs[VTABLE_ADD + P2->vtable->num_t
On Fri, Nov 16, 2001 at 03:40:57PM +, Simon Cozens wrote:
Hurrah!
--
Jason
On Thu, Nov 15, 2001 at 01:05:49PM -0500, Michael L Maraist wrote:
> I know it's dangerous to compare hardware to a VM, but the required
> equivalent would be to not tear down ANY scoping, and additionally, the
> definition of a subroutine would have to preallocate ALL scopes before-hand.
I th
On Sat, Nov 17, 2001 at 02:22:44PM +, [EMAIL PROTECTED] wrote:
> Alan Burlison <[EMAIL PROTECTED]> wrote:
> > Dave Mitchell wrote:
> > > * Is there ever any need to for a PMC type which holds both an int and
> > > a
> > > num? In the Perl 5 case we were constrained by code that expected to
> >
On Sat, Oct 13, 2001 at 11:08:28AM +0100, Simon Cozens wrote:
> On Sat, Oct 13, 2001 at 10:40:06AM +0100, Jonathan Stowe wrote:
> > Did I just pick a bad moment to checkout ?
>
> No. Unfortunately, someone's done something pretty stupid.
> Brent? The testparrotsizes isn't going to work, since var
I get the following trying to do a cvs checkout or update:
.
.
.
cvs server: Updating include
cvs server: Updating include/parrot
cvs server: [17:11:59] waiting for cvsanon's lock in
/home/perlcvs/parrot/include/parrot
cvs server: [17:13:33] waiting for cvsanon's lock in
/home/perlcvs/parrot/in
Patch for Configure.pl to create an empty vtable.h so that
testparrotsizes will compile instead of running make, and to remove it once
done.
--
Jason
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrievi
On Sun, Oct 14, 2001 at 10:21:06AM -0400, Jason Gloudon wrote:
>
>
> Patch for Configure.pl to create an empty vtable.h so that
> testparrotsizes will compile instead of running make, and to remove it once
> done.
Ignore this. I generated the patch on the wrong file. Some o
Two patches inline...
A small change to Makefile.in so that 'make test' doesn't try to run without an
interpreter or missing assembler libraries.
Index: Makefile.in
===
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revisio
On Fri, Oct 12, 2001 at 11:16:55AM -0400, Dan Sugalski wrote:
> Anyone care to throw together some tests for configure.pl to figure out the
> *real* sizes for the register chunks (courtesy of a quick test program that
> does some sizeof() checks?) and figure out the power-of-two boundary these
Fixes wayward copy and paste for register save ops:
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.4
diff -u -r1.4 core.ops
--- core.ops2001/10/15 21:18:42 1.4
+++ core.ops2001/10/16 01:40:34
@@ -1745,15 +1745,15 @@
}
AUTO_OP restore(n) {
- pop_generic_entry(in
This patch replaces the existing CHUNK_BASE macro used for all the register
sets with separate (INT|NUM|STR|PMC)_CHUNK_BASE macros. The bit masks are
already determined by Configure thanks to Dan.
--
Jason
Index: Configure.pl
==
sys/time.h must be included for struct timeval for gettimeofday(). The current
CVS source is not compiling for me without this. Perl's Config module contains
a symbol for gettimeofday's availability, so it would be possible to make the
numeric time operator conditional on this define.
--
Jason
On Wed, Oct 17, 2001 at 12:13:51PM +0100, Simon Cozens wrote:
> On Tue, Oct 16, 2001 at 10:54:54PM +0200, Dav?? Helgason wrote:
> > > # Temporary hack
> > > system("make include/parrot/vtable.h");
> >
> > So I decided to try to fix it.
>
> Why are you trying to entrench a temporary hack? :) The
In fact, something similar to the check for reasonable sizes will need to be
done to guarantee that INTVAL is large enough to hold "opcode_t *" in order to
support jumps to absolute addresses held in registers, if jump Ix is fixed to
match its definition.
--
Jason
On Wed, Dec 05, 2001 at 12:18:53AM -0800, Brent Dax wrote:
> I'm probably just inexperienced and idiotic, but what's wrong with
> simple 'get_from_aggregate target, aggregate, key' and maybe
> 'get_list_from_aggregate target_list, aggregate, key_list'? (Obviously
> we'd shorten the names, but yo
On Thu, Dec 13, 2001 at 05:18:07PM -0500, Dan Sugalski wrote:
> I'm not sure we'll ultimately go this way, but I've added the following ops
> to the core:
>
> setline
> setpackage
> setfile
> getline
> getpackage
> getfile
The debuginfo.t tests are missing 'end' opcodes.
On Fri, Dec 14, 2001 at 09:59:30AM -0800, Brent Dax wrote:
> # > > new P0, PerlInt
> # > > new P1, PerlString
> # > > set P1, P0
> What I'm basically asking is, in that case are we going to be calling
> $1->vtable->set_string($2->vtable->get_string())
> or
> $1->vta
On Sun, Dec 16, 2001 at 11:56:46PM -0500, Jeff G wrote:
> so it generates code that has commands like 'set P0, P1', so that
> instruction needs to be added. The consensus on that thread seems to be
> that it should perform a deep copy of the PMC, at least to the pointer
> level. I'll hopefully be
On Mon, Dec 17, 2001 at 09:43:28AM -0500, Dan Sugalski wrote:
> >Can you clarify what you mean by "deep copy" at least to the pointer level ?
> >
> >set P0, P1
> >
> >should invoke P0's "assignment" vtable function (does anyone know if it
> >already
> >exists under a different name ?). For the e
On Mon, Dec 17, 2001 at 10:33:00AM -0500, Dan Sugalski wrote:
> >Ok, so set creates an alias. The string set opcode should also create an
> >alias for consistency, no ?
>
> It does. Or it did last I checked...
It was changed to make a copy. A high level language implementor wanted Perl
language
Just some cleanups for consistent access to the interpreter in PMC code.
Index: classes/perlstring.pmc
===
RCS file: /home/perlcvs/parrot/classes/perlstring.pmc,v
retrieving revision 1.7
diff -u -r1.7 perlstring.pmc
--- classes/perls
On Thu, Dec 20, 2001 at 07:37:42AM -0500, Gregor N. Purdy wrote:
> I see Simon already changed 'cp ...' to 'perl -MFile::Copy...'. I just
> changed that to '$(PERL) -MFile::Copy...'.
NT 4.0's cmd shell does not like single quotes.
diff -r1.82 Makefile.in
22c22
< platform$(O) $(CLASS_O_FILES) ji
On Fri, Dec 21, 2001 at 02:59:52PM -0500, Gregor N. Purdy wrote:
> * Eventually getting rid of (all?) references to the implicit args
> of opfuncs (interpreter and cur_opcode). If they are implicit,
> let them stay hidden. Dan is thinking this may become easier
> when/if we can stor
Here is a big diff that removes the interpreter argument from vtable function
calls, and creates macros for obtaining the pointer to an interpreter structure
for the current thread from thread local storage, assuming only that there is
one interpreter per thread. It works on unixish systems with
On Mon, Dec 24, 2001 at 02:11:15PM -0500, Gregor N. Purdy wrote:
> Or, do we really need to have the three-way in/out/inout tagset?
>
> inline op set(out i, in i|ic) {
> $1 = $2;
> }
Making the distinction between the three cases enables a number of
optimizations of native code based on
The PerlInt logical-or is using get_integer instead of get_bool for logical
operations. This patch corrects that.
Perlnum and perlstring have working get_bool's, so the default logical_or and
logical_and should be sufficient. The empty methods are pointed to the default
logical_or.
Index: class
This makes PerlUndef somewhat functional by adding logical,
arithmetic, and repeat methods.
Index: global_setup.c
===
RCS file: /home/perlcvs/parrot/global_setup.c,v
retrieving revision 1.12
diff -u -r1.12 global_setup.c
--- global_
On Fri, Jan 04, 2002 at 03:14:05PM -0500, Dan Sugalski wrote:
> >Adding undef to undef? Why bother? :)
>
> Who needs to initialize variables anyway? :)
>
> We need to add in some warning code, I think. I'll stub out an interface.
Exceptions of some kind would be nice too :)
--
Jason
Actually you need to clarify what the semantics of an 'out' parameter are for S
and P registers. 'out' should indicate whether the value of the register (ie.
the value of the pointer) may change.
For example, in :
inline op set(PMC, NUM) {
$1->vtable->set_number_native(interpreter, $1, $2);
Here is a patch that makes pbc2c generated code work with the bsr opcode. It
creates a new opcode 'enternative', and uses this to support a mixed model of
interpretation and execution of compiled C code.
Initially, an interpreter is created and started in order to execute a modified
copy of the
Here is a patch that fixes prederef with respect to bsr.
--
Jason
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.57
diff -u -r1.57 interpreter.c
--- interpreter.c 12 Jan 2002 1
Pointer arithmetic not quite right in the generated code. Also patches
pbc2c.pl to work with rx.ops.
--
Jason
Index: pbc2c.pl
===
RCS file: /home/perlcvs/parrot/pbc2c.pl,v
retrieving revision 1.12
diff -r1.12 pbc2c.pl
30c30
< my
On Tue, Jan 15, 2002 at 02:58:53PM -0500, Michel Lambert wrote:
> Some more minor fixes and cleanup to parrot's ability to read in pbc data
> off of STDIN. Note that using an MSVC-compiled parrot doesn't work in
> cygwin...it reads in less data than it should, both before and after this
> patch. O
On Wed, Jan 30, 2002 at 03:27:18PM -0500, Andy Dougherty wrote:
> On Solaris, it looks like JIT will now be enabled if the user has also
> installed GNU objdump. However, there is (often) already a disassembler
> in /usr/ccs/bin/dis. It's output is similar, but not identical to,
> objdump. Is a
This should make solaris 'as' happy. There will be an assembler warning, but
it's harmless.
diff -r1.3 sun4Generic.pm
78c78
< return Parrot::Jit->Assemble("ld [\%o0], \%o0\njmpl \%o0, \%g0\n");
---
> return Parrot::Jit->Assemble("ld [\%o0], \%o0\njmpl \%o0, \%g0\nnop\n");
151c151
<
On Tue, Feb 05, 2002 at 02:10:15PM -0500, Andy Dougherty wrote:
> I've applied the following little patch which is required for those using
> Sun's assembler. It helps the make process a bit further along.
> I still get core dumps for test_parrot -j. It might have to do
> with my 64-bit perl, bu
On Wed, Feb 06, 2002 at 12:09:22PM -0800, Steve Fink wrote:
> but I think that's because re_backtrack returns a void*. run_native()
> returns an opcode_t*, which is fine for the regular core_ops.c but
> gets returned as void** in core_ops_prederef.c. I think the computed
> goto path does a third
On Thu, Feb 07, 2002 at 01:38:42PM -0500, Michael G Schwern wrote:
> On Thu, Feb 07, 2002 at 07:12:18PM +0100, Sebastian Bergmann wrote:
> > Is this for real? I can't really believe this...
>
> Yes, I have it on good authority from the Easter Bunny.
In case everyone is not familiar with the ea
The type changes in struct Packfile break the pointer math used in a few places
to calculate the address of the end of the loaded byte code. This causes
segfaults in build_asm in jit.c when using -j. It also breaks the bounds
checking on opcode address in runops_slow_core.
The patch adds the nece
On Fri, Mar 22, 2002 at 10:06:44AM -0500, Joshua Nye wrote:
> Not sure if this is intended though. I though each type (INT,NUM,PMC,STR)
> has it's own stack?
This is the expected behaviour. There are only two stacks visible at the parrot
assembly level. The scratch (or data) stack, and the contr
On Fri, Mar 22, 2002 at 10:13:41AM -0500, Jason Gloudon wrote:
> assembly level. The scratch (or data) stack, and the control flow stack. The
> push, pop, and save ops work on the scratch stack, which as you have found,
> does type-checking.
Corrections:
That should have been save, s
This is a not-yet-suitable for applying patch that removes the dependency on an
external assembler and disassembler for Just-In-Time compiler support. All
assembly is done at run-time via macros. This is sufficient to allow some
flexibility in instruction selection at run-time, but a lot more wo
On Wed, Mar 27, 2002 at 02:55:59AM -0500, Michel J Lambert wrote:
> Attached is a patch to implement computed-goto on gcc, taken from the
> original post by Daniel Grunblatt:
> http:[EMAIL PROTECTED]/msg06255.html
The patch is slightly broken, core_cg_ops.h in interpreter.c versus
core_ops_cg.h e
On Mon, Apr 01, 2002 at 01:33:02AM -0300, Daniel Grunblatt wrote:
> Did you continue working on this or can I take this patch to continue?
I haven't made any changes since then so you can work off this patch.
--
Jason
On Tue, Apr 02, 2002 at 01:33:59AM -0500, Michel J Lambert wrote:
> If instead, registers are aliased onto traditional memory variables, such
> that a PMC pointed to by a register is *also* pointed to by a stash
> somewhere, then it's a bit harder.
I believe this is the desired scheme.
Blocking
On Thu, Apr 18, 2002 at 01:49:20PM +0200, Marco Baringer wrote:
> in trying to make goto ADDRESS($1) work as it should i have come
> across the following doubt:
How are you interpreting that it "should" work ? I don't know of any
documentation that says what it should do, but currently it is onl
On Thu, Apr 18, 2002 at 03:24:58PM +1000, Andrew J Bromage wrote:
> - Nobody is likely to use it any time soon.
People say that about my brain, but they haven't tried to take it from me
yet :)
Having registers provide the destination for some branches makes it possible to
generate code th
I don't have the time right now to do this myself, so here is a simple
idea to evaluate.
Currently, the computed goto decode and dispatch is essentially:
goto *ops_addr[ *cur_opcode ];
Now a big part of the gain of the prederef runops core comes from decoding each
op once instead of each time
The disassembler isn't happy at the moment, this patch appears to fix
the problem it has with the bytecode header.
Index: lib/Parrot/PackFile.pm
===
RCS file: /home/perlcvs/parrot/lib/Parrot/PackFile.pm,v
retrieving revision 1.15
d
The buflen of a new header was not always set to 0, which would cause SIGSEGVs
when parrot_reallocate tries to copy a non-zero length buffer with a bufstart
of NULL. This would happen when buffers get recycled.
I don't know if new_pmc_header has the same problem, but it also does not
initialize
On Thu, Apr 25, 2002 at 01:58:29PM -0400, Dan Sugalski wrote:
> 1) We need to have a set of 'new stack frame' ops that close out the
> current stack frames and start new ones. Should take an optional size
> that presizes the stacks.
> 3) The stack chunks need to be decoupled from the chunk hea
This clarifies some semantics of the get_string and substr vtables.
Index: docs/pdds/pdd02_vtables.pod
===
RCS file: /home/perlcvs/parrot/docs/pdds/pdd02_vtables.pod,v
retrieving revision 1.10
diff -r1.10 pdd02_vtables.pod
175c175,1
On Thu, Jun 06, 2002 at 12:04:03AM -0700, Ask Bjoern Hansen wrote:
>
> Robert Spier and I moved cvs.perl.org to a new server tonight.
> Everything should work as usual, except maybe a bit faster. If
> anything is odd, not working as it used to, working better, not
> working at all, please send u
On Fri, Jun 07, 2002 at 11:23:56PM -0400, Dan Sugalski wrote:
> 2) A revamped stack system so we can support exceptions
What is the intent for stacks ?
--
Jason
This seems like a good time to send in this patch:
It allocates the stack content memory using a buffer. This makes the stack
chunks and the memory used to hold stack contents visible to the garbage
collector. One can incrementally add to this to support copy-on-write
semantics for the chunk co
This fixes the problem with reading .pbc files on win32. Someone may want to
write the code to do something useful with the results of stat() when mmap() is
not being used.
Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemb
Could someone apply this ?
- Forwarded message from Jason Gloudon <[EMAIL PROTECTED]> -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
Delivered-To: mailing list [EMAIL PROTECTED]
Date: Mon, 10 Jun 2002 19:33:56 -0400
From: Jason Gloudon <[EMAIL PROTE
On Tue, Jun 11, 2002 at 12:04:19PM -, Clinton A. Pierce wrote:
> # New Ticket Created by "Clinton A. Pierce"
> # Please include the string: [netlabs #702]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=702 >
>
>
Duh. Here's a unified diff.
--
Jason
Index: docs/jit.pod
===
RCS file: /cvs/public/parrot/docs/jit.pod,v
retrieving revision 1.4
diff -u -r1.4 jit.pod
--- docs/jit.pod29 Jul 2002 21:13:38 - 1.4
+++ docs/jit.pod
On Sat, Aug 03, 2002 at 11:35:08AM +0100, Nicholas Clark wrote:
> I presume in the general case I'd have to know whether to call
> Parrot_jit_normal_op() or Parrot_jit_cpcf_op(), so could there be a subroutine
> in jit.c that I could call to make the correct decision for me?
Here is a patch for
On Sat, Aug 03, 2002 at 12:07:30PM -0400, Ken Fox wrote:
> Nicholas Clark wrote:
> >It seems that foo & (foo - 1) is zero only for a power of 2 (or foo == 0)
> >but is there a fast way once you know that foo is a power of 2, to find out
> >log2 foo?
The ARM doesn't have a find first set bit inst
On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
Here is a workaround for one hash related GC bug.
--
Jason
Index: hash.c
===
RCS file: /cvs/public/parrot/hash.c,v
retrieving revision 1.19
diff -u -r1.19 hash.c
--- h
On Mon, Aug 12, 2002 at 09:48:56PM +0100, Nicholas Clark wrote:
> This is a case of a temporary allocated value being only in a CPU register?
Not in this case. The link to the hash structure from the PMC is not
established, which prevents the custom mark routine in the PMC from identifying
the b
Here is another way of resolving this, as I mentioned in the last message.
Having new_hash() initialize the PMC's data pointer so that the hash is
immediately visible to the collector.
--
Jason
Index: parrot/hash.c
===
RCS file:
The last patch had an issue I didn't see on the test I was working against.
mark_hash() assumes the buffer_pool is always initialized, but with the patch
this is no longer the case.
--
Jason
Index: parrot/hash.c
===
RCS file: /cvs
On Sat, Aug 17, 2002 at 10:23:32PM +0200, Peter Gibbs wrote:
> If you want to get some improvement at the cost of some duplicated
> code, you can remove the * direction logic, and write two copies of the
> loop. (patch attached, but not fully tested)
> I'm sure there is more that can be done, b
On Sun, Aug 18, 2002 at 02:51:34AM +, Jason Gloudon wrote:
> # New Ticket Created by Jason Gloudon
> # Please include the string: [perl #16278]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=16278
Dan Sugalski wrote:
> First, for simple X = Y cases, we need a new assignment opcode. We
> have SET to copy pointers, CLONE to make full clones, but we don't
> have a method to stuff a value from one PMC to another.
> So, what we need to do is add ASSIGN Px, Py, which takes Px and calls
> se
On Fri, Sep 27, 2002 at 09:28:41AM +0200, Leopold Toetsch wrote:
> First and foremost, is there any compelling reason, to have totally
> different structures for PMCs and Buffers?
The reasons stopped being compelling about a month or two ago, when it was
decided to unify the two. No one has had
On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> As already posted I incorparated the allocator from
> http://gee.cs.oswego.edu/dl/html/malloc.html
> in parrot.
Whatever source you are using cannot be the original Lea malloc, since it does
not do garbage collection. There are m
On Mon, Oct 14, 2002 at 08:31:16PM +, Leopold Toetsch wrote:
> headers.c:
> - set PMCs and Buffers initially to "live". This helps somwhat, that
> initially created objects are not killed immediately by a DOD run e.g.
> in midst of string_make
But what happens where there is more than one
On Sun, Oct 20, 2002 at 12:32:24PM +0200, Leopold Toetsch wrote:
> PDD02 specifies the needed methods
>
> exists_keyed
> type_keyed
The vtable PDD refers to type_keyed returning the type of the *PMC*. This
isn't accurate given the question. Should we change the PDD ?
> perlhash/arr
On Wed, Oct 23, 2002 at 11:23:26PM -0400, Josh Wilmes wrote:
> I've got a patch which switches this detection to happen at run-time
> instead of at build-time. This is going to be necessary for miniparrot
> (which has no "Configure" step) anyway.
Have you checked how much this affects the per
On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote:
> > > I've got a patch which switches this detection to happen at run-time
> > > instead of at build-time. This is going to be necessary for miniparrot
> > > (which has no "Configure" step) anyway.
> >
> > Have you checked how much
On Fri, Oct 25, 2002 at 01:01:16PM +0100, Nicholas Clark wrote:
> What is wrong with any of
>
> 1: Duplicating the above loop (which isn't large), one for upwards stack,
>the other for downwards stack, and switching (outside) between the two
>based on an if statement on a global stack dir
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) *
On Tue, Oct 29, 2002 at 12:17:55PM -0600, Garrett Goebel wrote:
> Dan Sugalski wrote:
> > Leopold Toetsch wrote:
> > >
> > > Can we really have e.g. odd aligned PMCs on stack?
> >
> > the specs are available *somewhere*, and we should see
> > about digging them up and getting a final answer one way
On Sun, Nov 03, 2002 at 04:59:22PM -0500, [EMAIL PROTECTED] wrote:
> What I advocate is having possibly only one (maybe too extreme, but
> doable) built-in op pre-loaded
> at opcode zero. This op's name is "useop", and its arguments give an
> opcode (optable index), and
> sufficent information f
On Mon, Nov 04, 2002 at 09:21:06PM +, Nicholas Clark wrote:
> I'm not convinced. Compiling the computed goto core with any sort of
> optimisation turns on *really* hurts the machine. I think it's over a
> minute even a 733 MHz PIII, and it happily pages everything else out while
> it's doing i
On Tue, Nov 12, 2002 at 04:03:35PM +0100, Leopold Toetsch wrote:
> Some notes WRT implementation in i386:
> The first code in JIT is emitted by Parrot_jit_begin, the last 5 bytes
> of this code are 5 nop's now.
> When JIT is called again with a pc != code_start, i.e. for restart at
> pc, then a ju
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
> - Normal runloops don't have a problem with longjmp
>
> - JIT could have it's own low level exception handler:
> * gets jumped to, so registers are still ok
I am not clear how this works if the exception is triggered in a C funct
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
> But I have a proposal:
>
> - Normal runloops don't have a problem with longjmp
>
> - JIT could have it's own low level exception handler:
What happens when C code called from the JIT generated code generates an
exception ?
> *
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
> - JIT could have it's own low level exception handler:
> * gets jumped to, so registers are still ok
> * saves processor registers to parrots
> * then longjmps to parrot handler
I didn't finish my response...
The way I have thoug
On Thu, Nov 14, 2002 at 05:55:21PM +0100, Leopold Toetsch wrote:
> But above is only needed, if there are callee saved registers around
> which hold parrot register values not already saved. So currently not,
> because there are no unsaved registers, when calling external code and
> jitted OPs
1 - 100 of 124 matches
Mail list logo
