# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #21033]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21033 >
Hello,
I just implemented macro expansion in imcc.
This brings us one step closer to
Dan Sugalski wrote:
At 5:36 PM +0100 2/8/03, Leopold Toetsch wrote:
[ threaded JIT/prederef ]
Ouch, yes. So does JIT.
So JIT/prederefed code must be separated for threads.
Yup. This was a decision made a long time ago, back when Daniel started
the first JIT stuff.
Not necessarily so
At 11:40 PM +0100 2/14/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
The challenge system is x86 Linux with GCC, FWIW.
Nice ;-)
And not even my choice, but who am I to argue, right? :)
--
Dan
--"it's like this"---
At 12:49 PM + 2/8/03, Leon Brocard (via RT) wrote:
Attached is a bf compiler for languages/bf/ and a patch to the
makefile to make and test it.
The actual compiler is a bit slow on large bf programs - the culprit
being concat. Oh well, at least they run fast once compiled.
Applied, thanks.
Dan Sugalski wrote:
The challenge system is x86 Linux with GCC, FWIW.
Nice ;-)
leo
At 3:50 PM +0100 2/13/03, Juergen Boemmels wrote:
imcc is the only Makefile which does these kind of inplace
changes. This perl -pi seems to fail in your case and only deletes the
newly generated Makefile. As these are only warning fixes just comment
out these 3 system lines.
Why is this Makefile
At 2:11 PM -0500 2/10/03, [EMAIL PROTECTED] wrote:
What is the recommended mechanism for reading data from stdin for a
PASM application. The readline operation is considered a hack and I
would rather implement the correct mechanism for reading data into
stdin than use such a reviled operation.
At 5:36 PM +0100 2/8/03, Leopold Toetsch wrote:
Jason Gloudon wrote:
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 us
At 9:02 PM + 2/14/03, Nicholas Clark wrote:
On Fri, Feb 14, 2003 at 03:45:20PM -0500, Dan Sugalski wrote:
The challenge system is x86 Linux with GCC, FWIW. I have this nagging
feeling we'll be able to muster something that'll run on it... :)
Are we free to use whichever runops core we fe
Dan Sugalski wrote:
*) The vtable split needs to be defined and implemented. I'd like some
macros to access the vtable entries themselves, since there may be a
number of structural changes and I don't want to have to keep redoing
the code every time some element shifts from one spot to anothe
On Fri, Feb 14, 2003 at 03:45:20PM -0500, Dan Sugalski wrote:
> The challenge system is x86 Linux with GCC, FWIW. I have this nagging
> feeling we'll be able to muster something that'll run on it... :)
Are we free to use whichever runops core we feel like?
Nicholas Clark
At 2:46 PM -0500 2/10/03, attriel wrote:
>>Just to confuse things more, there is a question I have reguarding
multi-methods and inheritance.
Consider class A defines foo() as a multi-method with 3 different
signatures
If class B then sub-classes A and defines a method foo() does it
1 overri
At 4:17 PM +0100 2/11/03, Leopold Toetsch wrote:
[EMAIL PROTECTED] wrote:
The 2004 Performance challenge
Dan announced that he'd made a bet with Guido van Rossum that Parrot
would be faster at executing a pure python benchmark
You missed the pie as part of the penalty, though tha
At 1:09 PM -0500 2/14/03, [EMAIL PROTECTED] wrote:
Dan --
*) There's going to be a bunch of named argument stuff that we should
(though don't have to) put support in for. Perl 6 is going to make
heavy use of them.
I may be terminologically challenged here (if so, please forgive), but
this s
Dan --
> *) There's going to be a bunch of named argument stuff that we should
> (though don't have to) put support in for. Perl 6 is going to make
> heavy use of them.
I may be terminologically challenged here (if so, please forgive), but
this sounds like passing a single pad as *the* argument
While most of what we discussed last week about perl 6 doesn't
directly impact parrot, there are a few things that will. I'm pretty
late as it is, so I figured I'd give a quick summary before digging
through the pending p6i mail and dealing with these in depth. In
order:
*) We need to get Leo'
Jerome Vouillon wrote:
[ prederef/JIT and threads ]
I'm not sure this is the right think to do. If we force gcc to store
in a machine register the address of the Parrot registers, it should
generate some code which is just as fast as the prederefed one. For
instance, the sub opcode would be
On Sat, Feb 08, 2003 at 05:36:58PM +0100, Leopold Toetsch wrote:
> Jason Gloudon wrote:
> >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/runinter
Ok, here is the hairy thing, discussed in the CGP thread.
hange in core.ops
This patch introduces the 1000th opcode, a asm("ret") for gcc/i386, a
noop else. This opcode is referenced directly as #2, so it should
better stay on the spot - and be documented :)
Changes in jit.c:
- The building of
Nicholas Clark wrote:
I'd suggest committing it, rather than sending it to the list.
Ok, I'll do that after checking again on a second machine
... I think it would be better to write them into a design doc
I'll include docs/dev/jit_i386.dev with has most of the gory details.
Nicholas
20 matches
Mail list logo
