Jason --
> Making the distinction between the three cases enables a number of
> optimizations of native code based on analysing data flow. 'in' would be good
> as an implicit default, as many PMC opcodes will not overwrite any PMC
> registers.
>
> An optimizing native code generator (whether st
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 08:03 PM 12/18/2001 -0800, Benjamin Stuhl wrote:
> >--- Melvin Smith <[EMAIL PROTECTED]> wrote:
> > > 3) Perl IO has conditional compilation for using
> stdio.
> > > Dan has said no
> > > STDIO
> > > but are we going to abandon conditional supp
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
Folks,
To make life a bit easier for the JIT, and to speed things up in the
general case, we're changing the way the registers are implemented a bit.
Instead of floating on top of the register file the way they are now, the
registers will be part of the interpreter structure. This means we onl
At 08:42 AM 12/26/2001 -0800, Boris Tschirschwitz wrote:
>On Wed, 26 Dec 2001, Jason Gloudon wrote:
>
> > branch is a relative branch, look at the code generated for it:
> >
> > static opcode_t *
> > Parrot_branch_ic (opcode_t cur_opcode[], struct Parrot_Interp *
> interpreter) {
> > return cur
On Mon, Dec 24, Gregor N. Purdy wrote:
> Nicholas --
>
> > Parrot_set_i_i(in,out): \x8b \x0d &IR2 \x89 \x0d &IR1
>
> I'm tempted to push the specification of this information all the way
> back to the syntax of .ops files, since the code that lives there
> should behave the same wrt read/write o
At 03:19 AM 12/26/2001 -0800, Boris Tschirschwitz wrote:
>Hi.
>When I am reading about Perl internal datatypes I wonder if they are going
>to be Parrot internal types, especially the BIGINTs and BIGNUMs.
>
>Will I be able to do someting like
> mov I3,45e3
>or are the BIGs going to be imple
On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > To run a program with the JIT, pass test_parrot the -j flag and watch it
> > scream. Well, scream if you're on x86 Linux or BSD (I get a speedup o
On Wed, 26 Dec 2001, Jason Gloudon wrote:
> branch is a relative branch, look at the code generated for it:
>
> static opcode_t *
> Parrot_branch_ic (opcode_t cur_opcode[], struct Parrot_Interp * interpreter) {
> return cur_opcode + cur_opcode[1];
> }
Yes, I see.
In parrot assmebly it looks li
Boris Tschirschwitz:
# Why is parrot/docs/core_ops.pod not under version control?
#
# For example we should change the explanation under
# =item B(ic) to
#
# Branch to the location specified by $1
#
# since that's what it does.
Because core_ops.pod is generated automatically from core.ops.
--
Why is parrot/docs/core_ops.pod not under version control?
For example we should change the explanation under
=item B(ic) to
Branch to the location specified by $1
since that's what it does.
Boris.
> Will I be able to do someting like
> mov I3,45e3
> or are the BIGs going to be implemented as PMCs?
Ok, a look at he actual interpreter shows that this is possible, but it
should really be
set I3,45e3
Then I really believe that the vector thing would be worthwhile.
Is there an ar
Hi.
When I am reading about Perl internal datatypes I wonder if they are going
to be Parrot internal types, especially the BIGINTs and BIGNUMs.
Will I be able to do someting like
mov I3,45e3
or are the BIGs going to be implemented as PMCs?
I ask because I have the following idea:
I think
13 matches
Mail list logo
