G'day all.
On Tue, Feb 19, 2002 at 09:15:02PM +, Nicholas Clark wrote:
> Would it gain us much implementing De Morgan's theorem in the peephole
> optimiser?
I suspect that most code generators for Parrot will translate LOGOPs
as jumps (i.e. the way most compilers do it), in which case the D
G'day all.
I'm working on the Optimizer (adding a new intermediate form to allow
for more aggressive optimization) but mail to Jeff Goff seems to be
bouncing. Does anyone know where he is?
Cheers,
Andrew Bromage
G'day all.
The optimizer needs to know what operands are INTs and which are
actually code targets in disguise in order to be able to restructure
code.
The patch below gives one simple solution, but I'm not sure that it's
the "best". I suspect that code processors (including optimizers) might
ne
G'day all.
On Tue, Apr 16, 2002 at 10:52:05PM +0200, Marco Baringer wrote:
> regarding (2): vector processors would certainly benefit from having
> loops (espicially the ones over arrays of similar things (a large
> percentage of real world loops)) explicitly labeled as such.
A few of comments:
G'day all.
This patch introduces a new op parameter type "inconst", which is like
"in" except that it only produces const versions of the op (i.e. it
will not take values from registers).
This is mostly for the benefit of branch targets. The "feature" of
using register values as branch targets
G'day all.
On Thu, Apr 18, 2002 at 09:35:11AM -0400, Jason Gloudon wrote:
> Having registers provide the destination for some branches makes it
> possible to generate code that eliminates most of the comparisions
> needed to implement C style case/switch statements, so this is not a
> useless fe
G'day all.
On Thu, Apr 18, 2002 at 09:09:59PM -0400, Dan Sugalski wrote:
> I've applied this, with the exception of the branch and bsr ops. At
> the moment, I agree--I can't see any case where "if" or "gte" needs
> to have a variable target. (I can see it for branch, bsr, jump, and
> jsr, as
G'day all.
This patch allows op-writers to store optional metadata to be
associated along with an op. Very simple key-value stuff at the
moment; may get fancier later.
Once again, this is mostly for the optimizer's benefit, so you
can note things like if an op affects the state of the world, or
G'day all.
On Thu, Apr 18, 2002 at 11:31:32PM -0400, Dan Sugalski wrote:
> Interesting. Could you give an example of how an op with metadata would look?
Sure. Here's some of my experimenting with what is the right kind
of metadata to attach. Brief glossary:
- CANNOT_FALL_THROUGH mean
G'day all.
On Fri, Apr 19, 2002 at 12:44:49AM -0400, Dan Sugalski wrote:
> Ah. Hmmm. Well, we're already attaching some metadata to ops in a
> different way--that's what the op and inline keywords are doing. For
> metadata that use parameters I can see a scheme like you're
> proposing, though
G'day all.
On Fri, Apr 19, 2002 at 07:06:04AM +0100, Piers Cawley wrote:
> If I'm going to be doing tail call optimization
> (and I can't call it scheme if I don't) then my first thought was as
> follows.
>
> # This is a tail call
>
> branch FOO_tail
> ...
>
> #
G'day all.
On Fri, Apr 19, 2002 at 09:55:46AM +0100, Piers Cawley wrote:
> It's fine for partial continuations certainly, but less fine if you
> want to implement full continations which require you to save the
> state of the entire stack. I was hoping I'd find a way to do this
> without having
G'day all.
On Fri, Apr 19, 2002 at 05:28:12PM -0300, Daniel Grunblatt wrote:
> Add me to the list, because I'm writting the jit optimizer and ran into
> the same problem, we must add some metadata otherwise I will end up
> hard-coding all the information deep into the optimizer and that is a Bad
G'day all.
On Fri, Apr 19, 2002 at 01:08:46PM -0700, Steve Fink wrote:
> Should it be all one keyword, or should 'const' be an orthogonal
> modifier?
IMO, one modifier, because "const" doesn't make sense on any direction
but "in".
> > - Nobody is likely to use it any time soon.
>
> I will
G'day.
On Sat, Apr 20, 2002 at 10:06:10PM -0700, Steve Fink wrote:
> Do we want to restrict subs to a single entry point? (for example,
> what if you want one "initial" entry point, and one "resume" entry
> point that figures out where processing left off?)
Not necessarily. These are just idea
G'day all.
On Sun, Apr 21, 2002 at 08:24:36PM -0300, Daniel Grunblatt wrote:
> Can you store this info in the 'op_info_table' too?
Yes.
CVSmeisters: Please ignore this patch. A replacement one will be
available once "make test" is finished.
Cheers,
Andrew Bromage
G'day all.
Adds argument direction information into Parrot::Op and the
op_info_table.
Cheers,
Andrew Bromage
Index: ops2c.pl
===
RCS file: /cvs/public/parrot/ops2c.pl,v
retrieving revision 1.22
diff -u -r1.22 ops2c.pl
--- ops2c.pl
G'day all.
On Thu, Apr 18, 2002 at 09:09:59PM -0400, Dan Sugalski wrote:
> >> I've applied this, with the exception of the branch and bsr ops.
[...]
On Mon, Apr 22, 2002 at 11:01:35AM -0400, Dan Sugalski wrote:
> The branches are relative to the current PC, the jumps take
> absolute addresse
G'day all.
On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
> 3) We're having a new rule--you may *not* take a continuation from
> within an opcode function! This is probably one of those "Well, Duh!"
> things but better to have it up front.
I see why you say this, but I'm not su
G'day all.
On Tue, Apr 23, 2002 at 01:18:23PM -0700, Brent Dax wrote:
> Three questions:
>
> 1. Which'll be faster?
It depends on the application, but my money is on mutable strings
built on top of an immutable buffer. That's based on looking at my
own string-based Perl code, a lot of which i
G'day all.
On Mon, Apr 22, 2002 at 01:52:30PM -0700, Brent Dax wrote:
> > How about we instead declare that all subs have One True Entry Point,
> > and the sub does whatever is needed there? Normal subs can just set up
> > scoping and jump to the beginning of the sub's body; coroutines retrieve
G'day all.
On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
> I also vote for reserving some caller-save registers to make
> arg passing faster, however, reserving 16 is probably useless, except
> for symmetry.
>
> I think most texts agree that 5 or so are about all you need.
Fair
G'day all.
On Fri, Apr 26, 2002 at 09:45:24AM -0700, Larry Wall wrote:
> Gee, maybe I should patent this.
Actually, you're binary searching the Stern-Brocot tree representation
of rational numbers. In fact, if you have arbitrary precision integers,
you can convert these strings into rational n
G'day all.
On Sat, Apr 27, 2002 at 07:00:17AM +0100, Piers Cawley wrote:
> I'm trying to see how, if you want genuine continuations and/or tail
> call optimization, you're going to get away with anything but 'caller
> saves everything important to it', and what do you know, I
> can't.
If you ha
G'day all.
On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
> We're going caller-save. I think I made this declaration before, but
> now it's backed up with pure PDD goodness. :)
The first thing to realise is that this violates the principle of
"callee does everything important t
G'day all.
On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
> I don't think I and Andrew were saying we shouldn't do caller-save, we
> were just discussing that the calling convention (read activation record of
> a subroutine) should support the common optimization of passing args
>
G'day all.
On Sun, Apr 28, 2002 at 10:26:12PM -0400, Melvin Smith wrote:
> Ok, agreed. Sorry for speaking for you.
Not a problem. Having people try to speak for you can actually
clarify your thoughts, or so I've found.
> Regarding performance, a decent compiler should be able to
> analyze a m
G'day all.
On Mon, Apr 29, 2002 at 07:57:08AM +0100, Piers Cawley wrote:
> Remember that the caller only has to save the stuff that is important
> to it, after all, anything that might be of importance to *its*
> callers will already have been saved. If the callee saves then it's
> going to be d
G'day all.
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
> Welcome to my world. They're all bad ideas in some way or, rather,
> they're all equally as good.
That's definitely true. :-)
I should also point out that for Perl, all this is moot. Current Perl
semantics require tha
G'day all.
On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
> [ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
Understood.
> Isn't compiler convienience a (the?) major issue here?
I wouldn't call it a "major issue". I think of it as a constraint.
The ma
G'day all.
I have a suggestion for allowing parrot implementations to execute
code more efficiently. Add an "instruction" or other annotation which
denotes what registers are "live" at some point in the code. The
intended usage is that compilers which wish to generate this
information generate
G'day all.
On Mon, Sep 24, 2001 at 10:27:24AM -0400, Michael Maraist wrote:
> Does it have to be in the instruction stream to be useful?
No, of course not. I said "instruction" because that's how I saw it
implemented last, but that was in a compiler backend, not in a virtual
machine specificat
G'day all.
On Mon, Nov 12, 2001 at 03:37:08PM +, Leon Brocard wrote:
> I forgot to point out that details of the JVM are available [...]
I realise that this _is_ a major difference between Parrot and the
JVM, but you don't need to rub it in. :-)
Cheers,
Andrew Bromage
G'day all.
On Mon, Dec 03, 2001 at 01:27:33PM -0500, Adam Turoff wrote:
> =head1 Parrot : A Cross-Language Virtual Machine Architecture
> =head2 What is Parrot?
> =head2 How does this relate to .NET?
> =head2 How does this relate to Mono?
> =head2 Why redesign a VM
G'day all.
On Wed, Dec 05, 2001 at 01:23:34PM -0500, Dan Sugalski wrote:
> Besides, the only p-code machine I could think of was UCSD Pascal running
> on the Apple IIs, and that seemed a bit old to reference.
FWIW, in the last days of Microsoft's 16-bit C compiler (at least V7
and V8), it used
35 matches
Mail list logo
