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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21508
This adds
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 savealls and
two restorealls.
But with proper tail call optimization you'd only need *one*
saveall. That's why
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 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
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
that
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 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 or
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:
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 the
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 to
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, ic # or
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/syn/eval_3.imc:
#
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. The vtable
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 finalization
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 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 it seems to me
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 in itself
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 function
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 ?
* gets
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 thought
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 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
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
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 this affects
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/array
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 DOD
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
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, but
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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16278
Moved
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
---
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
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:
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 instruction
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
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 PROTECTED
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.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=702
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:
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
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 us
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
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
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
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
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 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 only
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
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
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, savec
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 easter
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
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. Only
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
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
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
---
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
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:
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
---
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)
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 store
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 existing PMC's the
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 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. My
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
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_type](i,
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
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
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 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 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, 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:
typedef void
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
---
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
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
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
correct fix
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 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 other folks
have posted
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
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) {
-
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
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
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 various
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
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
instead of the .ops 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;
+
1 - 100 of 103 matches
Mail list logo
