Re: Introduction and cygwin results
At 10:51 AM -0800 1/3/03, James Michael DuPont wrote: Can someone tell me if anyone uses packdump from cvs? is that an equivalent to ildasm in dotnet? It seems to be broken. Can I dump an set of instructions from a program into a file, and reassemble them? If not, is there a way to dump a parrot program? Not that I know of, I think so, damn, you should be able to, and no no other way. Is there a way to capture the line number, and comments of a perl6 program in parrot? What about high level type information? Line number, yes. Comments, probably not, though it's possible that info can get embedded. What type of high-level info are you looking for? We've all sorts. :) Seriously, if you're looking for variable type info, it'll potentially be there, assuming that it's not been stripped out. I would be willing to port my code to the subset of perl/parrot that is currently supported, where I can i find that? Perl 6 is in languages/perl6, though I think that there's still some stuff missing. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: GC/DOD feedback & runtime tuning
At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote: Dan Sugalski wrote: I'm not willing to go so radically to start, but I did have an idea. I think part of the extra cost is just in cache fluffiness--the sync info just isn't being used much. I don't think that it, or the property info, will be used most of the time. We could yank the metadata and sync fields out of the PMC itself and put them in a separate segment of the PMC's arena, and replace them with a single pointer to the PMC's particular section. A little bit more radically: - a PMC has a PObj and a vtable (= 16 byte) - if a PMC needs data, metadata or synchronize then cache.pmc_val points to the "Extra PMC data" (our current PMC ) containing this fields so we do nether resize, but have for aggregates or PMCs with properties one more indirection. - PerlStrings move from ->data to ->cache.string_val As programs tend to have much more scalars then aggregates and probably more scalars w/o properties then with, this would win a lot of precious cache mem. Fair enough, though there's something just so bizarre about having the cached value be a required part, and the data the cache is supposed to be based on optional... :) It ultimately increases the size of a PMC by one pointer if we preallocate all the property/sync pairs, but it makes the PMC itself more dense and, if I'm calculating things right, makes it fit on an 8-byte boundary better. Not here: current PMC 32 byte, simple PMC 16 byte. Hrm, did the math wrong. Need to go double-check that. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: GC/DOD feedback & runtime tuning
At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote: Ok. Here ist the rest. - No stackwalk, as already sent by separate #19668, which is included if this is a problem for $architecture, please enable trace_system_areas in dod.c again - feedback still welcome I think we're always going to have to walk the stack, no matter how much I'd rather not. It's an expensive walk too, alas. - a hack to reduce DOD runs by some amount, helping for this test, where only allocations happen. If we keep it, it should be reworked to have the stats in interpreter and "skip" has to be disabled for explict "sweep" calls. Twiddling the default numbers seems reasonable, though doing it for this one test is silly. - allocation constants give good results on my systems which might probably not apply to yours. In the long run some sself tuning will be necessary, we will definitely need lower allocation sizes, when e.g such a big allocation is gone, and we have plenty of free PMCs - we currently do only increase headers_per_alloc. Dynamic feedback on the allocation & GC system is definitely in order. We should find a victim^Wvolunteer to do this--it could be a very interesting project. - statistics need to be reworked, they are only valid after a DOD run, though I update num_free_objects now immediately. Hrm. We should get at least the allocation numbers right, though I do wonder at the impact of keeping buffer/pmc allocation counts. (Yeah, I know, I added that code, as I thought the stats would be useful for GC feedback) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: GC/DOD feedback & runtime tuning
At 9:35 PM -0500 1/3/03, Mitchell N Charity wrote: I'm not willing to go so radically to start, but I did have an idea. I think part of the extra cost is just in cache fluffiness--the sync info just isn't being used much. I don't think that it, or the property info, will be used most of the time. We could yank the metadata and sync fields out of the PMC itself and put them in a separate segment of the PMC's arena, and replace them with a single pointer to the PMC's particular section. It does seem a lot of time is being spent by free_unused_pobjects walking arrays of PMCs (pool arenas) to twiddle flags. An similar alternative might be to yank the gc flags to the head of their arena. It looks like they might even fit in a short. So an arena has an array of flag ints, and a corresponding array of PMCs. The contiguous flags would speed the walk, and _might_ stick in cache enough that the cache miss cost wouldn't just reappear in random PMC access. One would need a fast way to get from a PMC address to its arena address, eg page aligned arenas. That's an interesting idea. I'd originally wanted to yank a lot of stuff out of band and get it in a separate segment of the PMC arena, to make the commonly used parts of PMCs denser, but I'd given up that idea because of the cost of figuring out where the extra bits were held. I'm leaning more and more towards ebbedding a pointer to the extra info into the main PMC body and taking the dereference hit on those occasions when we actually need to get to it from the main PMC body. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: This week's Perl Summary
Damian Conway wrote: Piers Cawley wrote: Acknowledgements But, of course, modesty forebade him from thanking the tireless Perl 6 summarizer himself, for his sterling efforts wading through the morasses that are P6-language and P6-internals Remembering e.g. perl6 operator threads, brrr, I just can say ... Thank-you, Piers! me2 Damian leo
Re: GC/DOD feedback & runtime tuning
Dan Sugalski wrote: At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote: As programs tend to have much more scalars then aggregates and probably more scalars w/o properties then with, this would win a lot of precious cache mem. Fair enough, though there's something just so bizarre about having the cached value be a required part, and the data the cache is supposed to be based on optional... :) "Hysterical raisins" did Dan write. Integers and floatvals are stored in the union, which happens to be named "cache", they don't have data. Renaming cache to val would make it more obvious. Strings are attached to data, cache is unused. leo
Re: GC/DOD feedback & runtime tuning
Dan Sugalski wrote: At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote: - No stackwalk, I think we're always going to have to walk the stack, no matter how much I'd rather not. It's an expensive walk too, alas. This depends on. I think a mixed strategy of: - code reordering (e.g. $1=pmc_new_noinit(); pmc->vtable->init() instead of pmc=new_pmc() like done in setprop - passing a **dest_ptr for e.g. string_concat - disabling DOD (with optional DOD run befor, if header count is below wanted header count, e.g. for clone) - and may be some active anchoring to the root set will do it. - a hack to reduce DOD runs by some amount, helping for this test, Twiddling the default numbers seems reasonable, though doing it for this one test is silly. Of course. But the "skip" thingy is different. It triese to detect, if we are allocating only and skips the next DOD run for this case. Instead of twiddling some number we need: Dynamic feedback on the allocation & GC system is definitely in order. We should find a victim^Wvolunteer to do this--it could be a very interesting project. - statistics need to be reworked, Hrm. We should get at least the allocation numbers right, though I do wonder at the impact of keeping buffer/pmc allocation counts. (Yeah, I know, I added that code, as I thought the stats would be useful for GC feedback) I did add num_free_objects in the fast path with very little impact on performance. I'll rearrange current interpinfo interface and move it to interpreter.c. Numbers like active_PMCs can be calculated on demand. leo
Re: GC/DOD feedback & runtime tuning
Leopold Toetsch wrote: Leopold Toetsch wrote: $ time parrot -j stress.pbc A total of 9 DOD runs were made real0m0.708s But this still could go faster: $ parrot -j stress.pbc # w/o pmc->synchronize (-10% size) A total of 9 DOD runs were made real0m0.635s $ time parrot -j stress.pbc $ make -s && time parrot -j stress.pbc A total of 13 DOD runs were made real0m0.378s user0m0.310s sys 0m0.060s This is with DISABLE_GC_DEBUG and a 16 byte small PMC for PerlInt. So it is actually ~doubling speed with a half sized PMC. If someone wants to further experiment on this issue, I could commit the changes, with one #define in parrot.h for enabling this feature. leo
[CVS ci] interpinfo - GC/DOD/Mem stats reworked
- {active,total}_{PMC,BUFFER}S are calculated now on demand and
therefore always valid, not only after a DOD run (active)
- these vars are no more in the interpreter struct
- removed duplicate printing of interpinfo
Accessing info from these interpreter stat fields shall be done only via
the interpinfo() function call.
leo
Re: Object semantics
On Sat, 2003-01-04 at 04:05, Dan Sugalski wrote:
> At 7:27 PM +0100 1/3/03, Erik Bågfors wrote:
> >On Sat, 2003-01-04 at 00:28, Gopal V wrote:
> >> If memory serves me right, Dan Sugalski wrote:
> >> > language-level "we're object-oriented dammit!" objects, not the
> >> > lower-level stuff we're currently working with) should/will behave.
> >>
> >> yay ! ... finally !
> >
> >The moment we've all been waiting for :)
>
> Sheesh, everyone lay on the guilt, why don't you? :-P
Working on it
To be honest, I won't have much time from next week so now is probably
the only time I have to do something for a long time. So all I can do
is lay on the guilt :)
> > > > reference-style objects and non-reference values.
> >>
> >> How large can a non-reference value be ? ... (in the .NET opcodes the
> >> 'struct' seems to be unlimited in size ...) But well, I'd settle for
> >> a non-reference of at least large integers (64bit)...
> >>
> >> And how will non-reference values dispatch methods ? ... would they be
> >> "boxed" into a reference for each method call, so that the method call
> >> can modify them ? ...or are all non-reference values immutable ?
> >>
> >> to put it down clearly ...
> >>
> >> MyValueType a;
> >> a.Modify();
> >>
> >> would a be able to modify itself ? (unfortunately C# allows that)
> >
> >So does ruby. We need that :)
>
> I wasn't aware that ruby had value types--I thought it was all
> reference types. Time to crack open the nutshell book again,
> apparently.
Well, An object can certainly modify itself.
: [bagfors@detrius]$ ; irb
irb(main):001:0> a="test"
"test"
irb(main):002:0> a.sub!('e','s')
"tsst"
irb(main):003:0> p a
"tsst"
nil
But they are still reference types.
irb(main):006:0> a="test"
"test"
irb(main):007:0> b=a
"test"
irb(main):008:0> a.sub!('e','s')
"tsst"
irb(main):009:0> p a
"tsst"
nil
irb(main):010:0> p b
"tsst"
nil
So I guess it just modifies the reference. (oh.. I really need to learn
more about low-level language-stuff...)
/Erik
--
Erik Bågfors | [EMAIL PROTECTED]
Supporter of free software | GSM +46 733 279 273
fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Object semantics
If memory serves me right, Erik Bågfors wrote:
> > >> would a be able to modify itself ? (unfortunately C# allows that)
> > >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=42; }
public override String ToString(){ return val.ToString(); }
}
public class FooBar
{
public static void Main()
{
MyStruct m1=new MyStruct(10);
MyStruct m2=m1;
m1.Modify();
Console.WriteLine(m1);
Console.WriteLine(m2);
}
}
=end cut
Which gives
42
10
If in anycase Parrot wants to avoid this , we could always add a special
case to the ILNode_Assign to generate an explicit copy step in parrot for
valuetypes...
So, workarounds are possible .. and neither the host nor the compiler
is there yet ;) ...
Gopal
--
The difference between insanity and genius is measured by success
Re: Introduction and cygwin results
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:51 AM -0800 1/3/03, James Michael DuPont wrote:
> >Can someone tell me if anyone uses packdump from cvs? is that an
> >equivalent to ildasm in dotnet? It seems to be broken.
> >Can I dump an set of instructions from a program into a file, and
> >reassemble them?
> >If not, is there a way to dump a parrot program?
>
> Not that I know of, I think so, damn, you should be able to, and no
> no other way.
Here is my patch for pdump :
But the pdump does not disassemble... i have to look into
dissassemble.pl
Index: packdump.c
===
RCS file: /cvs/public/parrot/packdump.c,v
retrieving revision 1.6
diff -u -r1.6 packdump.c
--- packdump.c 2 Nov 2002 14:57:47 - 1.6
+++ packdump.c 4 Jan 2003 16:18:37 -
@@ -107,8 +107,13 @@
case PFC_STRING:
PIO_printf(interpreter, "[ 'PFC_STRING', {\n");
-PIO_printf(interpreter, "FLAGS=> 0x%04lx,\n",
+
+#ifdef HAS_parrot_string_t_flags
+
+PIO_printf(interpreter, "FLAGS=>
0x%04lx,\n",
(long)self->string->flags);
+#endif
+
PIO_printf(interpreter, "ENCODING => %s,\n",
self->string->encoding->name);
PIO_printf(interpreter, "TYPE => %s,\n",
Anyone working on cross compiling? I have a setup here for cross
compiling from debian to windows, but always use autoconf to do that.
Anyone have an idea?
>
> >Is there a way to capture the line number, and comments of a perl6
> >program in parrot? What about high level type information?
>
> Line number, yes. Comments, probably not, though it's possible that
> info can get embedded. What type of high-level info are you looking
> for? We've all sorts. :)
well as much as you can give me.
> Seriously, if you're looking for variable
> type info, it'll potentially be there, assuming that it's not been
> stripped out.
OK, that is good.
>
> >I would be willing to port my code to the subset of perl/parrot that
> is
> >currently supported, where I can i find that?
>
> Perl 6 is in languages/perl6, though I think that there's still some
> stuff missing.
Well, I will try that out. Thanks,
mike
=
James Michael DuPont
http://introspector.sourceforge.net/
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Infant mortality
Steve Fink wrote: I was assuming the generation would be automatically incremented per op, either in the runops loop or (if that is too slow) in the implementation of selected ops. In the runops loop would be slow, and not very practical for e.g. JIT or CGoto. But e.g. branch instructions would be a good point, though we have a lot of these. leo
cvs commit: parrot/tools/dev rebuild_miniparrot.pl (fwd)
FYI
--- Forwarded Message
Date:05 Jan 2003 00:41:55 +
From:Josh Wilmes <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: cvs commit: parrot/tools/dev rebuild_miniparrot.pl
cvsuser 03/01/04 16:41:54
Modified:config/auto jit.pl sizes.pl
config/gen/makefiles root.in
tools/dev rebuild_miniparrot.pl
Log:
Fix the miniparrot build.
- add missing header dependency (thread.h) in makefile
- add miniparrot settings for a few new config variables
- make the jit_debug stuff conditional on jit being enabled. (miniparrot
turns jit off, so required files were missing otherwise)
Reminder- to build miniparrot, do "make miniparrot-update", then run
"sh build_gcc.sh" in the miniparrot directory.
Revision ChangesPath
1.13 +3 -2 parrot/config/auto/jit.pl
Index: jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -w -r1.12 -r1.13
--- jit.pl4 Jan 2003 04:01:35 - 1.12
+++ jit.pl5 Jan 2003 00:41:51 - 1.13
@@ -23,7 +23,8 @@
jitcapable => 0,
cc_hasjit => '',
jit_h => '',
-jit_o => ''
+jit_o => '',
+ asmfun_o=> ''
);
return;
}
@@ -89,7 +90,7 @@
jitcapable => 1,
cc_hasjit => " -DHAS_JIT -D\U$jitcpuarch",
jit_h => '$(INC)/jit.h',
- jit_o => 'jit$(O) jit_cpu$(O)'
+ jit_o => 'jit$(O) jit_cpu$(O) jit_debug$(O)'
);
# test for some instructions
1.6 +4 -0 parrot/config/auto/sizes.pl
Index: sizes.pl
===
RCS file: /cvs/public/parrot/config/auto/sizes.pl,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -w -r1.5 -r1.6
--- sizes.pl 25 Nov 2002 15:54:40 - 1.5
+++ sizes.pl 5 Jan 2003 00:41:51 - 1.6
@@ -26,6 +26,10 @@
'hugeintvalsize' => 4,
'hugefloatval' => 'double',
'hugefloatvalsize' => 8,
+ 'int2_t' => 'int',
+ 'int4_t' => 'int',
+ 'float4_t' => 'double',
+ 'float8_t' => 'double',
);
return;
}
1.64 +3 -2 parrot/config/gen/makefiles/root.in
Index: root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.63
retrieving revision 1.64
diff -u -w -r1.63 -r1.64
--- root.in 27 Dec 2002 09:33:27 - 1.63
+++ root.in 5 Jan 2003 00:41:53 - 1.64
@@ -81,7 +81,8 @@
$(INC)/method_util.h $(INC)/list.h $(INC)/datatypes.h \
$(INC)/regfuncs.h $(INC)/string_funcs.h $(INC)/encoding.h \
$(INC)/chartype.h $(INC)/oplib.h $(INC)/sub.h $(INC)/unicode.h \
- $(INC)/perltypes.h $(INC)/exit.h $(INC)/nci.h $(INC)/pobj.h
+ $(INC)/perltypes.h $(INC)/exit.h $(INC)/nci.h $(INC)/pobj.h \
+ $(INC)/thread.h
ALL_H_FILES = $(GENERAL_H_FILES)
@@ -102,7 +103,7 @@
register$(O) core_ops$(O) core_ops_prederef$(O) memory$(O) \
packfile$(O) stacks$(O) string$(O) sub$(O) encoding$(O) \
chartype$(O) runops_cores$(O) trace$(O) pmc$(O) key$(O) hash$(O) \
- core_pmcs$(O) platform$(O) ${jit_o} jit_debug$(O) \
+ core_pmcs$(O) platform$(O) ${jit_o} \
${gc_o} rx$(O) rxstacks$(O) intlist$(O) list$(O) \
embed$(O) warnings$(O) ${cg_o} \
packout$(O) byteorder$(O) debug$(O) smallobject$(O) \
1.3 +2 -1 parrot/tools/dev/rebuild_miniparrot.pl
Index: rebuild_miniparrot.pl
===
RCS file: /cvs/public/parrot/tools/dev/rebuild_miniparrot.pl,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -w -r1.2 -r1.3
--- rebuild_miniparrot.pl 1 Nov 2002 03:34:36 - 1.2
+++ rebuild_miniparrot.pl 5 Jan 2003 00:41:54 - 1.3
@@ -89,6 +89,7 @@
## GCC ##
+print "- miniparrot/build_gcc.sh\n";
open(F, ">miniparrot/build_gcc.sh") ||
die "Unable to write miniparrot/build_gcc.sh: $!\n";
print F "#!/bin/sh\n";
--- End of Forwarded Message
Re: Infant mortality
On Jan-02, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >Another (maybe silly) possibility suggested itself to me based on a
> >private mail re: infant mortality from Thomas Whateley: could we try
> >optimistic allocations?
>
>
> > if (alloc_object() == NULL) {
> >undo everything
> >do_DOD_run
> >interp->on_alloc_fail = CRASH_AND_BURN
> >start over
> > }
>
> What if e.g. clone needs more headers then one dod run can provide? With
> CRASH_AND_BURN it would not succeed. With RETURN_NULL it would start
> over and over again, until objects_per_alloc increases the needed header
> count.
I think it's reasonable to not guarantee 100% perfect memory usage, if
it makes the problem significantly easier. _How much_ to relax that
constraint is another question. I was thinking that it might be okay
to say that any single operation (even those that could conceivably
trigger many other operations) must fit all of its allocations within
the total amount of available memory when it starts. Or, in short, I'm
saying that maybe it's all right for it to crash even though it could
actually succeed if you ran a DOD immediately before every single
allocation.
A single opcode is probably too constraining, though. We'd probably
have to do better for operations that can trigger arbitrary numbers of
other operations. I'm not convinced enough of the utility of the
general approach, though, so I'm not going to try to figure out how to
make the granularity smaller.
Re: Object semantics
On Jan-04, Gopal V wrote: > So, workarounds are possible .. and neither the host nor the compiler > is there yet ;) ... Good point -- we'd better speed up on this Parrot stuff, so we can push more of the really hard things onto you compiler guys. ;)
Re: Infant mortality
Steve Fink wrote: It's late here, but I'll try an answer ;-) ... I was thinking that it might be okay to say that any single operation (even those that could conceivably trigger many other operations) must fit all of its allocations within the total amount of available memory when it starts. We don't know that. There could be a clone of a PerlArray with size 10^6 elements. Or one element containing another element which is a PerlArray nested (until (program (syntax (or (I (dont (know (ends));-) ... Or, in short, I'm saying that maybe it's all right for it to crash even though it could actually succeed if you ran a DOD immediately before every single allocation. We can only increase allocating resources by some heuristic. It was by 4, now by 1.75, but you can never allocate for the future, you might have more crahses - and a DOD run does not help, when you just clone and you have no free headers. You just get increasing crash numbers causing more DOD runs and bigger allocations, until you reach the needed header limit. Or for short, it doesn't work (all IMHO of course). leo
[perl #19729] [PATCH] SPARC JIT support for restart
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #19729]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19729 >
This patch adds JIT support for restart and similar ops.
--
Jason
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/46899/36851/696709/restart.patch
Index: jit/sun4/jit_emit.h
===
RCS file: /cvs/public/parrot/jit/sun4/jit_emit.h,v
retrieving revision 1.18
diff -u -r1.18 jit_emit.h
--- jit/sun4/jit_emit.h 1 Dec 2002 12:51:23 - 1.18
+++ jit/sun4/jit_emit.h 5 Jan 2003 04:01:03 -
@@ -287,7 +287,7 @@
#define Parrot_jit_intrp emitm_i(0)
/* The register holding the address of I0 */
-#define Parrot_jit_regbase emitm_i(1)
+#define Parrot_jit_regbase emitm_i(2)
/* The register containing the address of the opmap */
#define Parrot_jit_opmap emitm_i(3)
@@ -300,6 +300,32 @@
/* The offset of a Parrot register from the base register */
#define Parrot_jit_regoff(a, i) (unsigned)(a) - (unsigned)(Parrot_jit_regbase_ptr(i))
+/* Generate a jump to a bytecode address - uses the temporary register */
+static void
+Parrot_jit_bytejump(Parrot_jit_info_t *jit_info,
+struct Parrot_Interp *interpreter, int reg_num)
+{
+
+/* Construct the starting address of the byte code */
+emitm_sethi(jit_info->native_ptr, emitm_hi22(interpreter->code->byte_code),
+Parrot_jit_tmp);
+emitm_or_i(jit_info->native_ptr, Parrot_jit_tmp,
+emitm_lo10(interpreter->code->byte_code), Parrot_jit_tmp);
+
+/* Calculates the offset into op_map shadow array
+ * assuming sizeof(opcode_t) == sizeof(opmap array entry) */
+emitm_sub_r(jit_info->native_ptr, reg_num, Parrot_jit_tmp,
+Parrot_jit_tmp);
+
+/* Load the address of the native code from op_map */
+emitm_ld_r(jit_info->native_ptr, Parrot_jit_opmap, Parrot_jit_tmp,
+ Parrot_jit_tmp);
+
+/* This jumps to the address from op_map */
+emitm_jumpl_i(jit_info->native_ptr, Parrot_jit_tmp, 0, Parrot_jit_tmp);
+emitm_nop(jit_info->native_ptr);
+}
+
/* Generate conditional branch to offset from current parrot op */
static void Parrot_jit_bicc(Parrot_jit_info_t *jit_info, int cond, int annul,
opcode_t disp)
@@ -505,9 +531,14 @@
}
}
-void Parrot_jit_begin(Parrot_jit_info_t *jit_info,
+void
+Parrot_jit_begin(Parrot_jit_info_t *jit_info,
struct Parrot_Interp * interpreter)
{
+/* generated code is called as jit_code(interpreter, pc)
+ * so interpreter is in i0 and pc in i1.
+ * i1 is reusable once past the jump. interpreter is preserved in i0
+ */
int ireg0_offset;
/* Standard Prolog */
@@ -531,8 +562,10 @@
emitm_sethi(jit_info->native_ptr,
emitm_hi22(jit_info->arena.op_map), Parrot_jit_opmap);
emitm_or_i(jit_info->native_ptr,
-emitm_i(3), emitm_lo10(jit_info->arena.op_map), Parrot_jit_opmap);
-/* TODO emit restart code s. i386 */
+Parrot_jit_opmap, emitm_lo10(jit_info->arena.op_map), Parrot_jit_opmap);
+
+/* Jump to the current pc */
+Parrot_jit_bytejump(jit_info, interpreter, emitm_i(1));
}
void Parrot_jit_normal_op(Parrot_jit_info_t *jit_info,
@@ -555,21 +588,27 @@
struct Parrot_Interp * interpreter)
{
Parrot_jit_normal_op(jit_info, interpreter);
+Parrot_jit_bytejump(jit_info, interpreter, emitm_o(0));
+}
-emitm_sethi(jit_info->native_ptr, emitm_hi22(interpreter->code->byte_code),
-emitm_l(1));
-emitm_or_i(jit_info->native_ptr, emitm_l(1),
-emitm_lo10(interpreter->code->byte_code), emitm_l(1));
-
-/* This calculates offset into op_map shadow array */
-emitm_sub_r(jit_info->native_ptr, emitm_o(0), emitm_l(1), emitm_o(0));
+#undef Parrot_jit_restart_op
+void Parrot_jit_restart_op(Parrot_jit_info_t *jit_info,
+struct Parrot_Interp * interpreter)
+{
+Parrot_jit_normal_op(jit_info, interpreter);
-/* Load the address of the native code from op_map */
-emitm_ld_r(jit_info->native_ptr, emitm_i(3), emitm_o(0), emitm_o(0));
+/* Test whether the return value is 0 */
+emitm_subcc_r(jit_info->native_ptr, emitm_o(0), emitm_g(0), emitm_g(0));
-/* This jumps to the address from op_map */
-emitm_jumpl_i(jit_info->native_ptr, emitm_o(0), 0, emitm_g(0));
+/* If the return pc is not zero skip the next 3 instructions */
+emitm_bicc(jit_info->native_ptr, 0, emitm_bne, 4);
emitm_nop(jit_info->native_ptr);
+
+/* Return if the return pc is 0 */
+emitm_ret(jit_info->native_ptr);
+emitm_restore_i(jit_info->native_ptr, emitm_g(0), emitm_g(0), emitm_g(0));
+
+Parrot_jit_bytejump(jit_info, interpreter, emitm_o(0));
}
/* move reg to mem (i.e. intreg) */
