Hi kids,
I have work-related reason to add a B backend for Perl 5 to the perl6
compiler. I'm looking at creating an assembler for Perl 5's B bytecode
along the lines of IMCC, and creating patches against languages/perl6/IMCC.pm
and languages/perl6/IMCC/* to conditionally, using some sort of
Mike,
Part of the beauty of PMCs is that you can have very compact
storage given a dedicated eg int array type. Generating these
would not be a bad thing. The typical case still remains, that
arrays will contained mixtures of all datatypes.
On Wed, 24 Jul 2002, Mike Lambert wrote:
This patch
Mike,
Was very happy to see your message. People don't often agree with
me. I'm not very agreeable.
On Thu, 25 Jul 2002, Mike Lambert wrote:
Scott Walters wrote:
Part of the beauty of PMCs is that you can have very compact
storage given a dedicated eg int array type. Generating
On Wed, 24 Jul 2002, Mike Lambert wrote:
Mike,
I submit some patches a few days back, one with updates to the documentation
from my reverse engineering and probing efforts. I also implemented a patch
to make Array.PMC handle keys recursively. I'm kind of testing the waters
here. If they are
When a KEY * key datastructure is passed to a keyed method in array.pmc,
and key-next is true...:
array.pmc will recurse into the keyed lookup method of the PMC that it
contains, passing it key-next.
This implements the recursive indexing behavior as described in PDD08.
-scott
Index:
On Mon, 22 Jul 2002, Angel Faus wrote:
In my opinion, there are actually two different things to dicuss:
- keyed opcodes
- keyed methods on the PMC vtable
...
Keyed opcodes can stay in the interest of code density.
No. Keyed access for all methods stays. You're forgetting one
On Mon, 22 Jul 2002, Nicholas Clark wrote:
I will now demonstrate my ignorance of the parrot build system:
Do pmc files get turned pretty directly into C code?
Yes, via classes/pmc2c.pl. I don't see any code in there to replace the
// style comments, but I didn't read too carefully.
Dan,
As it stands, KEY * is a win when:
1) All of the array indices are constants and hardcoded into the instruction
stream
2) The PMC handling the index does not have to recurse.
In all other cases, as it currently stands, it is a loose. I hate to come out
and be so blunt, but I
Dan,
Thanks for being a good sport. I'm not in a hurry here - don't feel like you
need to be.
I propose that keyed access do exactly eight things:
* fetch a PMC using a key
* fetch a integer using a key
* fetch a number using a key
* fetch a string using a key
* store PMC
Btw, to the best of the ability of my backscroll, I'm trying to archive useful
conversations on http://www.slowass.net/wiki/?ParrotVirtualMachine. If I miss
something, feel free to add it.
-scott
On Sun, 14 Jul 2002, Dan Sugalski wrote:
At 10:09 AM +0100 7/14/02, Simon Wistow wrote:
On
Still trying to solve the assembly/PMC vector interface. Accosted Dan on IRC re:
multidimentional indices.
Looking for thoughts on this.
Working under assumptions:
* There is no assembler syntax yet, or atleast not final.
* Hardcoding KEY *'s into the assembly is the only way so far.
*
Melvin co,
Which IRC network, which channel?
Sorry for past, present, and future newbie questions. Doubly so for having
overlooked documentation. Docs are in excellent condition, considering.
Since I can't help but to pipe up, I should disclaim myself: Parrot is
extremely coo. The core team
12 matches
Mail list logo
