On Wednesday 03 March 2004 19:50, Leopold Toetsch wrote:
> Daniel Grunblatt <[EMAIL PROTECTED]> wrote:
> > When updating the old version I had at the TD machine to the current cvs
> > version I realize that it fails right after start running, entering in an
> > eternal
When updating the old version I had at the TD machine to the current cvs
version I realize that it fails right after start running, entering in an
eternal loop, I could not find out exactly what is the problem but I think
it's related to threads.
It's Debian 3.0 on parisc using gcc 3.0.4
Any ide
I can point you to the docs:
docs/jit.pod
There should be an explanation of how it works.
Daniel.
On Wednesday 08 October 2003 13:16, Clemens Eisserer wrote:
> Hi there!
>
> I´m currently interrested a bit in howto write a just in time compilier
> (jit). I searched a long time using googl
On Wednesday 10 September 2003 01:52, Luke Palmer wrote:
> Okay, after some major changes, here's the second revision of my patch.
> This one is fully functional.
>
> On my system, it creates over a 10x speedup for lazy DOD runs!
Yay!
>
> (I'll post the benchmark program if someone wants; it's pre
On Friday 05 September 2003 12:34, Steve Fink wrote:
> Nicholas Clark wrote:
> >On Tue, Sep 02, 2003 at 06:39:23AM +0300, Vladimir Lipskiy wrote:
> >>D. Function parametres in declarations.
> >>
> >>At the monent, pdd7 says that we mustn't omit them in declarations.
> >>I propose to omit them. The
On Thursday 21 August 2003 11:23, Tanton Gibbs wrote:
> I just wanted to let the list know that with the following configure
> options
>
> --cgoto=0 --jitcapable=0 --execcapable=0
Just to let you know --jitcapable=0 implies --execcapable=0.
>
> I had 100% pass rate on all cygwin tests.
Cool.
>
>
If you want to compile your .pbc to $(EXE) but you don't want
blib/lib/libparrot.a included in each one, you can do it by linking the
generated .o with blib/lib/libparrot.so (you can try "make exec_so
EXEC=" but I'm unsure if it will work correctly)
In order to have this working you must recom
On Thursday 14 August 2003 18:24, Mattia Barbon wrote:
> Puts #ifdefs as per the rest of i386/jit_emit.h.
>
> Regards
> Mattia
Applied, Thanks.
Daniel.
I've checked in what I did last year to make the JIT work on MIPS, it's not
finished but IMHO it's a good start, so if anyone wants to continue or gimme
an account in one (which I don't have anymore) I would be glad.
Daniel.
Now EXEC works for ARM (linux) too.
On Wednesday 13 August 2003 12:28, Daniel Grunblatt wrote:
> On Wednesday 13 August 2003 05:07, Leopold Toetsch wrote:
> > I started extending the packfile functions towards multiple code
> > segments. First is still some cleanup, but I already have troubles with
> > the EXEC
On Wednesday 13 August 2003 05:07, Leopold Toetsch wrote:
> I started extending the packfile functions towards multiple code
> segments. First is still some cleanup, but I already have troubles with
> the EXEC stuff :-(
I could not reproduce the error here.
> The debugger doesn't really like this
Now Exec works exactly like the jit, I have checked in the missing restart,
fixed some bugs at Parrot_jit_store_retval and make exec_start call runops
instead of calling run_compiled directly, so now all test are successful.
Have fun.
Daniel.
On Friday 08 August 2003 14:16, Nicholas Clark wrote:
> On Fri, Aug 08, 2003 at 01:48:17PM -0300, Daniel Grunblatt wrote:
> > Now Exec works exactly like the jit, I have checked in the missing
> > restart, fixed some bugs at Parrot_jit_store_retval and make exec_start
> > c
On Monday 04 August 2003 14:03, Dan Sugalski wrote:
> Here's some stuff we need to add to the packfile format and the sub
> header to get things ready for more language work.
>
> Packfiles need to have a symbol table. A series of name/type/location
> tuples so we can have global names that map to v
On Sunday 03 August 2003 15:27, Simon Glover wrote:
> On 3 Aug 2003, Luke Palmer wrote:
> > This fix has worked fine with JIT until now, so I suspect the problem
> > is elsewhere.
>
> Bug confirmed here (although I need a slightly longer string to trigger
> it). Here's a stacktrace:
I couldn't r
On Thursday 31 July 2003 14:31, Brent Dax wrote:
> Daniel Grunblatt:
> > +PIO_eprintf(interpreter, "Parrot VM: Platform " JIT_ARCHNAME
> > +" is not EXEC-capable.\n");
>
> An unprefixed constant like JIT_ARCHNAME should n
On Tuesday 29 July 2003 21:10, chromatic wrote:
> On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote:
> > Therefore the decision was taken that we should not guarantee that
> > Parrot
> > should never segfault when fed bad assembler; the creation of invalid
> > assembler is a compiler bu
I have checked in a patch to make the following work:
./parrot -o life.o examples/assembly/life.pbc
So, don't use test_main anymore.
I made this storing the pointer to the -o argument in the interpreter string
register 0 to make it visible from inside the core, instead of adding another
pointe
On Monday 28 July 2003 20:53, Simon Glover wrote:
> On Mon, 28 Jul 2003, Tim Howell wrote:
> > ?tches from a few days ago to allow executable creation, the current CVS
> > no longer compiles properly on my MacOS X 10.2.6 box. The error I get
> > is:
> >
> > exec_save.c:319:16: #if with no expressi
On Monday 28 July 2003 20:46, Tim Howell wrote:
> ?tches from a few days ago to allow executable creation, the current CVS no
> longer compiles properly on my MacOS X 10.2.6 box. The error I get is:
>
> exec_save.c:319:16: #if with no expression
> make: *** [exec_save.o] Error 1
>
> The following
Yes, it's already fixed, thanks.
On Friday 25 July 2003 17:55, Garrett Rooney wrote:
> Daniel Grunblatt wrote:
> > +# endif
> > +# if EXEC_OS == DARWIN
> > +# define EXEC_MACH_O
> > +# endif
> > +# if (EXEC_OS == FREENBSD) || (EXEC_OS
On Thursday 24 July 2003 22:02, Arcady Goldmints wrote:
> # New Ticket Created by "Arcady Goldmints"
> # Please include the string: [perl #23115]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=23115 >
>
>
> Contrary to popu
On Thursday 24 July 2003 22:02, Arcady Goldmints wrote:
> # New Ticket Created by "Arcady Goldmints"
> # Please include the string: [perl #23115]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=23115 >
>
>
> Contrary to popu
On Thursday 24 July 2003 16:13, Simon Glover wrote:
> On Thu, 24 Jul 2003, Daniel Grunblatt wrote:
> > On Thursday 24 July 2003 15:55, Juergen Boemmels wrote:
> > > Magic: 7f 45 4c 46 01 01 01
> >
> > 00
> > --
> > 00 00 00 00 00 00 00 00
> >
On Thursday 24 July 2003 15:55, Juergen Boemmels wrote:
> Magic: 7f 45 4c 46 01 01 01
00
--
00 00 00 00 00 00 00 00
> OS/ABI:UNIX - System V
Patch is in, please resync and try it.
> boe
Daniel
On Thursday 24 July 2003 15:48, Juergen Boemmels wrote:
> Daniel Grunblatt <[EMAIL PROTECTED]> writes:
> > I have checked in a first attempt to make parrot generate an executable.
>
> This is very cool.
Thanks.
>
> > It works fine on x86 - OpenBSD/linux/FreeBSD and
On Thursday 24 July 2003 15:14, Simon Glover wrote:
> On Thu, 24 Jul 2003, Daniel Grunblatt wrote:
> > I have checked in a first attempt to make parrot generate an executable.
> >
> > It works fine on x86 - OpenBSD/linux/FreeBSD and should also work on
> > NetBSD
>
ut this is not correct for macros
that emits more than 1 instruction (like the floating point ones) hence I
made a horrible hack at jit2h.pl which change the displacement from -4 to,
say, -6. Another way I see to make this is adding a list of macros with their
displacement? (if the macro is n
Back in.
On Tuesday 08 July 2003 11:32, Sean O'Rourke wrote:
> On 7 Jul 2003, Daniel Grunblatt wrote:
> > cvsuser 03/07/07 13:20:40
> >
> > Modified:jit/ppc jit_emit.h
> > Log:
> > * 2 instructions instead of 3 to load a 32 bit integer.
>
&g
On Tuesday 27 May 2003 21:25, Bill Atkins wrote:
> Am I correct in assuming that Parrot's JIT will eventually be able to
> produce directly-executable files, like .exe's?
Yes, you are.
>
> Bill
Daniel.
On Thursday 20 February 2003 18:14, Leopold Toetsch wrote:
> Tupshin Harper wrote:
> > Leopold Toetsch wrote:
> >> Starting from the unbearable fact, that optimized compiled C is still
> >> faster then parrot -j (in primes.pasm)
> >
> > Lol...what are you going to do when somebody comes along with
IW, and I'm not sure if it happens on x86.
>
> Someone care to check it out and poke around a bit?
CG vs JIT (running with non jitted opcdes) wins CG, always.
Daniel Grunblatt.
Applied, thanks.
Daniel Grunblatt.
On Sunday 05 January 2003 01:10, Jason Gloudon (via RT) wrote:
> # 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.or
On Monday 30 December 2002 21:30, Leopold Toetsch wrote:
> Jerome Quelin (via RT) wrote:
> > # New Ticket Created by Jerome Quelin
> > # Please include the string: [perl #19610]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.perl.org/rt2/Ticket/Display.ht
On Sunday 01 December 2002 18:04, Leopold Toetsch wrote:
> Daniel Grunblatt wrote:
> > The problem is that we do want to allocate a hardware register for a
> > Parrot register that is used only once in the section since the section
> > can be executed more than once, if you
is that we do want to allocate a hardware register for a Parrot
register that is used only once in the section since the section can be
executed more than once, if you don't mind I want to remove
ALLOCATE_REGISTERS_ALWAYS.
Daniel Grunblatt.
egisters for the
> memory operands, cisc.jit similar.
> $arch.jit could implement anomalies like i386 shift ops.
>
I don't really know if we should spent too much time on this instead of
creating an intermediate language to write opcodes on it.
Daniel Grunblatt.
On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
> Daniel Grunblatt wrote:
>
> > The problem is when you want to implement an opcode like div, which is
> > easy in ppc but not in arm ideas?
>
> I don't know arm, but this belongs to jit_emit.h, how it&
find some time to finish it
on december).
Daniel Grunblatt.
On Tuesday 19 November 2002 10:04, Leopold Toetsch wrote:
> Currently all architecures have there own core.jit. These are very
> similar, e.g. checking for MAPped registers, but differ depending on
> the processor architecure
On Thursday 14 November 2002 10:32, Leopold Toetsch wrote:
> Daniel Grunblatt wrote:
> > On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
> >>What JIT needs to know is the location of the resume opcode, to mark it
> >>as a jump target properly, so that proce
ddr OP as branch target, so that
> this basic block wouldn't be removed by dead code detection and the
> register allocator does know what to do. When a arbitrary opcode can
> jump out of the current block and resume elsewhere, the register
> allocator can't assign the same registers to these variables.
>
> So we have 3 levels, where we might have troubles:
> - JIT: processor registers
> - IMCC: parrot registers
> - HL: lexicals
>
> leo
Daniel Grunblatt.
You will see it running as fast as mops.c compiled with -O3 if you change
REDO: sub I4, I4, I3
for
REDO: dec I4
But that's obviously part of a higher level optimizer.
On Wednesday 13 November 2002 15:10, Leopold Toetsch wrote:
> Watch the mops ;-)
>
> leo
On Wednesday 13 November 2002 11:48, Leopold Toetsch wrote:
> Daniel Grunblatt wrote:
> > On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote:
> >>I could localize a long outstanding bug in JIT causing 4 perl6 tests to
> >>fail.
> >
> > I wonde
On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote:
> I could localize a long outstanding bug in JIT causing 4 perl6 tests to
> fail.
> When an opcode was a branch target as well as a branch source, the
> branch target got lost, causing wrong basic blocks, implying missing
> register loads
On Mon, 26 Aug 2002, Andy Dougherty wrote:
> Currently, a fresh checkout of the cvs tree contains 2215 files, but only
> 497 of them are listed in MANIFEST. Most are the icu/ files, but there
> are scattered others as well. I'm unsure if all of them are supposed
> to be in MANIFEST yet (e.g. is
> make activestate perl happy. ie, I'm not sure if it breaks other
> platforms.
>
> Thanks,
> Mike Lambert
>
>
> -- attachment 1 --
> url: http://rt.perl.org/rt2/attach/35605/28863/5e145e/fixup.diff
>
>
Applied, thanks.
Daniel Grunblatt.
(Had to make some changes because I committed some stuff
yesterday, I would have applied your patch before doing them but sadly I
get p6 email between 1 and 6 hours late.)
Daniel Grunblatt.
I just added condition breakpoints and watchpoints, now you can do:
(pdb) b 4 if S14 <= "parrot"
See docs/debugger.pod for details.
Is it worst to allow something like this?:
if (((S14 == I0) && (I4 <= N3) && (N3 < 4.5 < N7)) || (I5 == 32))
Daniel Grunblatt.
On 12 Aug 2002, Jason Greene wrote:
> One more safety check (fixes another crash bug). Hopefully this is the
> last patch patch.
Applied, thanks.
Daniel Grunblatt.
on) (and if there
> is one) and tell me if this should be sent as a patch.
>
Applied, thanks.
Daniel Grunblatt.
On Tue, 13 Aug 2002, John Porter wrote:
> Piers Cawley wrote:
> > I'd also like to be able to generate parrot code from within parrot
> > and immediately execute it...
>
> Something like that will be needed for eval() anyway, right?
Yes, like PDB_eval() may be...
Daniel Grunblatt.
ink time spent "tuning" the reference
> > assembler is wasted when it could be spent writing a really fast one
> > in C.
>
> There's a small, mad part of me that wonders if parrot would now
> support an assembler that was implemented in Parrot. Then we'd know
> that the assembler was at least as portable as parrot itself...
Something like languages/parrot_compiler/ but working, right?
Daniel Grunblatt.
On 12 Aug 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Daniel Grunblatt) writes:
> > Oh, no, I was talking about languages/parrot_compiler/. Sorry.
>
> Oh, I hadn't seen that. I can't work out what it is; it seems to be a
> device for generating "Couldn'
On 12 Aug 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Daniel Grunblatt) writes:
> > The assembler is a bit outdated, it shouldn't be too difficult to bring it
> > up to date, I just don't have enough time latetly. But it did work fine
> > and is easy to extend
On 12 Aug 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Daniel Grunblatt) writes:
> > I moved it back to pure-Perl because there were something like half of the
> > tinderboxes failing to assemble anything.
>
> Ah, right. Yeah, the tinderboxes are good slaves but really ba
e assembler I'd call a prototype. The regex engine? The
> GC? ...
>
The assembler is a bit outdated, it shouldn't be too difficult to bring it
up to date, I just don't have enough time latetly. But it did work fine
and is easy to extend it. Why do you think it should be thrown away?
Daniel Grunblatt.
xes failing to assemble anything.
Probably I should have gone the other way and fix it.
Daniel Grunblatt.
ouring?)
> If so, imcc has already done some work about where slightly more JIT effort
> might pay off, so it seems a shame to throw that out.
Yes, that's why we are not going to do any kind of optimization that is
not required to be done at runtime, that means, we expect the most optimal
bytecode.
Daniel Grunblatt.
OK, now we have the JIT working on PPC.
More opcodes coming.
It's not currently using a constant pool but it should.
Thanks to Sean for the sync cache code and helping me.
Daniel Grunblatt.
el as I confess I don't feel motivated to
> attempt to learn other assembly language to write JITs for hardware I don't
> own. Hey, all you Mac fans, where's the PPC JIT?
I'm working on it, as I'm working on the register allocator too.
Daniel Grunblatt.
On Tue, 30 Jul 2002, Nicholas Clark wrote:
> On Tue, Jul 30, 2002 at 01:21:30PM -0400, Dan Sugalski wrote:
> > At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote:
> > >On Mon, 29 Jul 2002, Nicholas Clark wrote:
> > > > As you can see from the patch all it does is i
ting:
> because I need if_i_ic JITted but mops only needs backwards jumps (which are
> easy, and don't require me to write the fixup routine yet)
We can wait, no problem.
Daniel Grunblatt.
mops.c is only slightly faster the jit, i.e. 1%
> - perl6-jit, albeit still totally unoptimized, doesn't compare too bad
>to perl5
> - mops is a silly test ;-)
>
You didn't use -O3 while compiling mops.c, did you?
Daniel Grunblatt.
alks/
>
> FYI The conference went well and I'm sure Dan will get his slides up
> soon. BTW anyone want to work on getting Parrot to use less memory so
> it can run on palmtops? ;-)
>
I'm told it will take much more than just reducing the memory it uses.
Da
Yes, we can do that, we can also try to go in and out from the computed
goto core if available.
Daniel Grunblatt.
On Tue, 30 Jul 2002, Dan Sugalski wrote:
> At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote:
> >On Mon, 29 Jul 2002, Nicholas Clark wrote:
> > > As you can
hese, is there a common instruction set?
>
> * IA64 - reports of the IA64 instruction set tell that it combines
> the "elegance" of the IA32 CISCy instruction set with
> the "elegance" of the HPPA RISCy instruction set... :-)
>
> I intend to do nothing on these except raise gui^H^H^Hawareness :-)
Or give me an acount? ;)
Daniel Grunblatt.
I thing I forgot to tell is that I also have added a constant pool which
could be usefull for the ARM too, it's on my local tree,I don't know
exactly when I'm going to finish it.
Daniel Grunblatt.
On Mon, 29 Jul 2002, Nicholas Clark wrote:
> Here's a very minimal ARM jit framework. It does work (at least as far as
> passing all 10 t/op/basic.t subtests, and running mops.pbc)
Cool, I have also been playing with ARM but your approach is in better
shape. (I'll send you a copy of what I got h
Applied, thanks.
Daniel Grunblatt.
On Tue, 23 Jul 2002, Andy Dougherty wrote:
> # New Ticket Created by Andy Dougherty
> # Please include the string: [perl #15401]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.h
Applied, thanks.
Daniel Grunblatt.
On Mon, 22 Jul 2002, Aldo Calpini wrote:
> # New Ticket Created by Aldo Calpini
> # Please include the string: [perl #15335]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.h
Applied.
Daniel Grunblatt.
On Wed, 17 Jul 2002, Sean O'Rourke wrote:
> # New Ticket Created by "Sean O'Rourke"
> # Please include the string: [perl #15009]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/
We have one vote for docs/dev.
Daniel Grunblatt.
On Wed, 17 Jul 2002, Melvin Smith wrote:
> At 06:14 PM 7/16/2002 -0700, John Porter wrote:
>
> >Melvin Smith wrote:
> > > I put it temporarily in the root dir, which I know is wrong.
> > > Where should .dev files
On Wed, 17 Jul 2002, Andy Dougherty wrote:
> The following patch brings the MANIFEST file up-to-date with recent
> additions. I haven't committed this in case some other reorganization
> (e.g. moving stuff to a src/ or dev/ or doc/ directory) is underway.
>
> There are also a few minor shuffles
The assembler doesn't use the XS stuff anymore, just committed a patch
build from Jeff's code.
Let's hope to see some more tinderboxes green.
Daniel Grunblatt.
I just changed 'kc' to be an integer constant, because it was the
simpliest way to make the warnings go away.
If kc should be a string and k too, tell me.
Daniel Grunblatt.
t don't
hardcode the address of the interpreter anywhere, and either way you will
need to dereference it, and that's slower, leaves us with 1 less cpu
register for the register allocation and requires a total redesing(what is
of course the less important thing).
Daniel Grunblatt.
Err, Jeff just told me to see the -E flag.
Daniel Grunblatt.
On Sat, 22 Jun 2002, Daniel Grunblatt wrote:
> It would be cute if you change the debugger to load all the included files
> as well.
>
> Daniel Grunblatt.
>
>
> On 21 Jun 2002, brian wheeler wrote:
>
> &g
It would be cute if you change the debugger to load all the included files
as well.
Daniel Grunblatt.
On 21 Jun 2002, brian wheeler wrote:
> I've implemented a .include directive for the new assembler. It
> basically changes the preprocessor to shift through the source file, an
On Fri, 21 Jun 2002, Jerome Vouillon wrote:
> On Thu, Jun 20, 2002 at 12:26:11AM -0400, Melvin Smith wrote:
> > Given that it seems capturing and restoring a context is the most
> > expensive part, should we make default routines lightweight (execute
> > on caller stack rather than getting their
Can you let me know if the way I think about exceptions is ok?
Thanks,
Daniel Grunblatt.
set I0,0
set I8,10
try
# User exception
catch !WRONG_NUMBERS, PRINT_WRONG
# Trying to catch an exception that was already catched.
catch !NOT_SUCH_FILE, NEVER_MADE_IT
print
On Wed, 12 Jun 2002, Jason Gloudon wrote:
>
> 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 1
t being a pain. The response to my report was that "This'll be
> fixed when we've got the Parrot IO support rolled out." Have you any idea
> how far down the line that's going to be?
No, I got no idea, but the problem wasn't in the Parrot IO but in the
assembler.
Daniel Grunblatt.
That was me, going to fix, sorry.
Daniel Grunblatt.
On Fri, 7 Jun 2002, Sebastian Bergmann wrote:
> jit.c(73) : error C2039: 'has_jit_op' : Ist kein Element von
> 'Parrot_jit_optimiz
> er_section'
> ./include\parrot/jit.h(50) : Siehe Deklaration von
&g
er files.
When I first saw all those warnings I couldn't understand why, thank you.
Daniel Grunblatt.
On 29 May 2002, Mike Lambert wrote:
> # New Ticket Created by Mike Lambert
> # Please include the string: [netlabs #634]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=634 >
>
>
> Peter recently submitted a patch to RT
On 1 Jun 2002, Simon Glover wrote:
> # New Ticket Created by Simon Glover
> # Please include the string: [netlabs #650]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=650 >
>
>
>
> A few small fixes to the assembler
yed ops simply to set,
> as Jeff suggested, as well as documenting them (slightly). It also
> adjusts the tests accordingly. All tests still pass.
>
> Simon
Applied, thanks.
(with a perl -p -i -e 's/[gs]et_keyed/set/' *.t first)
Daniel Grunblatt.
On 27 May 2002, Peter Gibbs wrote:
> # New Ticket Created by "Peter Gibbs"
> # Please include the string: [netlabs #628]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=628 >
>
>
> Following patch adds dependencies ent
On Wed, 29 May 2002, Mike Lambert wrote:
> Hey all,
>
> After finding out that life.pasm only does maybe 1KB per collection, and
> Sean reminding me that there's more to GC than life, I decided to create
> some pasm files testing specific behaviors.
>
> Attached is what I've been using to test a
Now I attached all the files :)
I also added now the target disassemble, it will emit on stdout the
disassemble of a pbc, this output is (should be) ready to assemble.
(it might have some issues with strings).
Daniel Grunblatt.
On 27 May 2002, Daniel Grunblatt wrote:
> # New Ticket Crea
On 26 May 2002, Mike Lambert wrote:
> # New Ticket Created by Mike Lambert
> # Please include the string: [netlabs #626]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=626 >
>
>
> Looksd like the logic for keeping trac
The patch made it to the RT what is enough.
Daniel Grunblatt.
On 24 May 2002, Tony Payne wrote:
>
> Hmm.. patch didn't make it.
>
> On Fri, 2002-05-24 at 08:51, Tony Payne wrote:
> > # New Ticket Created by Tony Payne
> > # Please include the string: [netlabs #6
On Fri, 24 May 2002, Peter Gibbs wrote:
> I managed to send the wrong version of the patch on the previous post!
>
> Herewith the correct (I hope) one.
>
> Apologies to all.
> --
> Peter Gibbs
> EmKel Systems
>
>
Applied, thanks.
make a call to a C
function like this:
extern Parrot_concat_s_s_s {
Regards,
Daniel Grunblatt.
I prefer it to work like this:
set S0,""
set IO,42
pack S0, 4, I0 ,0
length I1, S0 # is 4
pack S0, 4, I0
length I1, S0 # is 8
pack S0, 4, I0, 1 # no segv :)
length I1, S0 # is 10004
Patch is already applied.
Daniel Grunblatt.
On Thu, 23 May 2002, Sea
interpreter, PARROT_DEBUG_FLAG)) {
> fprintf(stderr, "*** Parrot VM: JITted code at 0x%08x. ***\n",
> jit_info.arena_start);
> }
>
> this way when I start 'parrot -j -d something' it tells me where
> to find the JIT, and I can goto there directly in the debugger.
> it's really a time saver for me.
The -d flag will be use for the parrot debugger, Can't you stop your
debugger at runops_jit?
Daniel Grunblatt.
fine. It's probably a decent stress test for the hash PMC, but especially
Exactly how do you want it to handle null bytes?
Daniel Grunblatt.
On Wed, 24 Apr 2002, Daniel Grunblatt wrote:
> Folks,
> From now on, please every time you want to send a patch send it to
> [EMAIL PROTECTED] so that we can keep track of it and it doesn't
> get lost in space.
>
> Thanks.
>
> Daniel Grunblatt.
>
>
And,
On Wed, 22 May 2002, Aldo Calpini wrote:
> hello,
> I've added the following new ops to i386/core.jit:
> inc_i
> dec_i
> inc_i_ic
> dec_i_ic
> lt_i_ic_ic
> lt_i_i_ic
> gt_i_ic_ic
> gt_i_i_ic
> ge_i_ic_ic
> ge_i_i_ic
> le_i_ic_ic
> le_i_i_ic
> e
1 - 100 of 162 matches
Mail list logo
