On Tue, Jul 15, 2003 at 10:15:57AM +0200, Leopold Toetsch wrote:
How is the described scheme supposed to work with JIT generated code ?
--
Jason
On Sun, Mar 23, 2003 at 03:54:21PM +0100, Leopold Toetsch wrote:
> Not really, but I don't see, how this set of macros would influence
> debugging negatively.
You can't step through the expanded code for a macro in the debugger.
--
Jason
On Fri, Mar 07, 2003 at 11:38:41PM +, Jason Gloudon wrote:
> # New Ticket Created by Jason Gloudon
> # Please include the string: [perl #21508]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=21508 >
On Mon, Mar 03, 2003 at 01:07:36PM +, Piers Cawley wrote:
> > I think you're overlooking the "restoreall" done just before the
> > jump-no-save-returnaddress operation... I see two "saveall"s and
> > two "restoreall"s.
>
> But with proper tail call optimization you'd only need *one*
> saveal
On Wed, Feb 26, 2003 at 09:31:39AM -0800, Sean O'Rourke wrote:
> Dan -- you might be interested in
> http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX
Research wants to be free:
http://www-hydra.stanford.edu/publications/JVM02.pdf
--
Jason
On Tue, Feb 25, 2003 at 07:18:11PM +0100, Angel Faus wrote:
> I believe it would be smarter if we instructed IMCC to generate code
> that only uses N parrot registers (where N is the number of machine
> register available). This way we avoid the risk of having to copy
> twice the data.
It's not
On Sat, Feb 08, 2003 at 03:10:58PM +, Nicholas Clark wrote:
> The bytecode is "compiled" by the JIT (at some point) - if there are a run
> of consecutive JIT-able ops, then issue a section (an isolated section) of
> machine code for those ops, and replace those ops in the bytecode with an op
>
On Fri, Feb 07, 2003 at 05:49:35PM +0100, Leopold Toetsch wrote:
> I don't know yet, how multi threading will be done. But when multiple
> interpreters share the ->code data member (as newinterp/runinterp) do,
> then they will use the same JIT/prederef or whatever data.
You can't do that for pr
On Fri, Feb 07, 2003 at 09:49:29AM +0100, Leopold Toetsch wrote:
> Yesterday night I hacked together a switched prederefed run loop. It's
> running ~50% faster then fast_core but a lot slower then the CGoto based
> loops.
The speedups are great. The next question is how do you do use this in a
On Sun, Feb 02, 2003 at 12:46:50AM +0100, Leopold Toetsch wrote:
> #define IREG(i) interpreter->ctx.int_reg.registers[code_start[offs+i]]
Where does the value of code_start coming from ?
code_start in an opcode function is not a constant, so the above is really:
interpreter->ctx.int_reg.register
On Thu, Jan 30, 2003 at 10:07:26AM +0100, Leopold Toetsch wrote:
> code_start = interpreter->code->base.data; // new syntax
> while (offs)
> offs = interp->func_table[*(code_start+offs)](offs, ..)
It's unclear to me whether you are saying the opcode functions would still be
passed the PC
On Thu, Jan 23, 2003 at 08:39:21PM +, Dave Mitchell wrote:
> This means that a Perl server that relies on a lot of modules, and which
> forks for each connection (imagine a Perl-based web server), doesn't
> consume acres of swap space just to have an in-memory image per Perl
> process, of all
On Wed, Jan 22, 2003 at 03:00:37PM -0500, Dan Sugalski wrote:
> Destinations. These are a pain, since if we can go anywhere then the
> JIT has to do all sorts of nasty and unpleasant things to compensate,
> and to make every op a valid destination. Yuck.
Arbitrary jumps are not that difficult t
On Tue, Jan 21, 2003 at 08:21:42PM +0100, Leopold Toetsch wrote:
> >>For such a branch, imcc generates this opcode seqence:
> >>
> >> inter_cs
> >> if i, ic # or whatever
>
> >Why do we need branches to go to different code segments ?
>
>
> Because of this nasty piece of little code:
> t/sy
On Tue, Jan 21, 2003 at 12:08:29AM +0100, Leopold Toetsch wrote:
> Here is a proposal for inter code segment jumps:
>
> The assembler (imcc) can recognize when a branch ins goes to a different
> code segment.
>
> For such a branch, imcc generates this opcode seqence:
>
>inter_cs
>if i,
On Mon, Jan 13, 2003 at 09:51:13AM -0800, Steve Fink wrote:
> > reference or being a member of an aggregate.
> >
> > 2) A vtable function obtains a PMC* to that PMC.
> >
> > 3) The vtable calls some code deletes the reference to the PMC, which is now
> > no longer accessible from the root set. T
On Fri, Jan 10, 2003 at 01:05:05PM +0100, Leopold Toetsch wrote:
> >While I'd like no stack walking, as it's pricey, I'm not sure it's
> >tenable.
>
> As the current clone changes does show, it's possible.
>
> BTW current tests do succed w/o stackwalking - its disabled.
>
> >... Skipping it m
On Wed, Jan 01, 2003 at 08:09:05PM -0800, Steve Fink wrote:
> To anyone out there who is thinking of a Grand Unified Infant
> Mortality Solution, here's another thing that vastly complicates
> things, and that we don't yet have a workable solution for yet: prompt
> finalization.
Timely finalizati
This patch should also be applied, or initialize_core_pmcs will fault with
PARROT_GC_DEBUG set.
diff -u -r1.52 embed.c
--- embed.c 21 Dec 2002 10:07:34 - 1.52
+++ embed.c 21 Dec 2002 21:34:32 -
@@ -32,6 +32,8 @@
we set up our own in embed.c:Parrot_runcode()?
*/
{
+
We have indeed gone through this before. The last time the dominant argument
was that these types of mark/unmark operations can be mis-used just as readily
as malloc/free, because the programmer has to know when and where to call them.
I'm just repeating this for everyone's benefit, not giving an
On Fri, Nov 22, 2002 at 02:04:20PM +0100, Leopold Toetsch wrote:
> Parrot_sub_i_i {
> Parrot_binop_x_x s//sub/ s/<_N>//
> }
The only question I have is .. How am I supposed to read/translate the above ?
--
Jason
On Thu, Nov 21, 2002 at 11:59:36AM -0500, Andy Dougherty wrote:
> While compiling, I did get the warnings:
>
> "cpu_dep.c", line 24: warning: initializer does not fit or is out of
> range: 0x91d02003
> "cpu_dep.c", line 26: warning: initializer does not fit or is out of
> range: 0x81c3e008
That
On Thu, Nov 21, 2002 at 10:28:42AM -0500, Andy Dougherty wrote:
> > +#ifdef HAS_HEADER_SETJMP
> > +jmp_buf env;
> > +
> > +/* this should put registers in env, which then get marked in
> > + * trace_system_stack below
> > + */
> > +setjmp(env);
> > +#endif
>
> Alas, no, though
On Thu, Nov 21, 2002 at 08:34:04AM +0100, Leopold Toetsch wrote:
My patch in 16237 has the code to flush register windows on v8 and older and v9
(64-bit) SPARC systems, which is what one is really trying to achieve via
setjmp.
--
Jason
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
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 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:
> - 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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
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
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:
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
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 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 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
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 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 >
>
>
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
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
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
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
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
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, 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
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
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
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
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
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 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 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 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
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 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
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
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 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
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 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
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 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
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
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
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
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
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);
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
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_
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
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
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 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
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
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 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
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 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 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 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 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 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 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 Fri, Nov 16, 2001 at 03:40:57PM +, Simon Cozens wrote:
Hurrah!
--
Jason
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 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 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
1 - 100 of 112 matches
Mail list logo
