Re: Using imcc as JIT optimizer
On Tue, Feb 25, 2003 at 11:58:41PM +0100, Leopold Toetsch wrote: Nicholas Clark wrote: [thanks for the explanation] And is this all premature optimisation, give that we haven't got objects, exceptions, IO or a Z-code interpreter yet? And yes: We don't have exceptions and threads yet. The other items, don't matter (IMHO). Well, I think that proper IO would be useful. But I don't think it affects the innards of the execution system greatly - is there any reason why parrot (or at least PBC) can't conceptually treat in the same way that C treats IO - just another standard library? Z-code interpreter is obfuscated shorthand for dynamic opcode libraries and reading foreign bytecode. I regard the first as important, the second as would be nice. I think Dan rates reading foreign bytecode more important than I do. Nicholas Clark
Re: 0.1.0
On Feb-25, Leon Brocard wrote: David sent the following bits through the ether: Thanks. I better upgrade my version, I'm not seeing it in 0.0.9. It's been a while since 0.0.9 (errr, 20th Dec). A lot has changed since then. Maybe it's time for a 0.1.0 release. What are we waiting for? And why do we have so many version numbers? It'd be nice to have objects, otherwise we're restricted to toy languages. We're waiting for objects or exceptions for 0.1.0, but that doesn't mean we can't have a 0.0.10. But while I agree that a lot has changed since 0.0.9, not much is different from a Parrot user's perspective (as opposed to a Parrot implementer's perspective). At least, I didn't think so. Let's see what a diff turns up... - IMCC integration - eval - some more benchmarking - cgp core - optimized math ops - intersegment branches - more complete use of PObjs - beefed up packfiles - sub/continuation/coroutine fixes - better NCI (native calling interface) - many imcc improvements - jako improvements So the user-visible stuff would appear to be: imcc integration (speedup!), eval, sub stuff, and NCI. Okay, you're right -- that's easily enough to warrant a release. I'll announce a code freeze soon.
Re: stabs support
On Feb-22, Leopold Toetsch wrote:
Steve Fink wrote:
In my local copy (currently locked away on my home hard drive, so I
can't post it from here at work), I also added stabs entries for all
the PMC registers (in addition to the current S, I, and N registers.)
You can see the PMC's data fields and type. It looks something like:
(gdb) p P0
(PMC*) 0xdeadbeef
(gdb) p *P0
{ vtable = 0xdeadbeef, pobj = { u = { int_val = 17, pmc_val = 0x17 },
flags = 381741 } }
(gdb) p *P0-vtable
{ base_type = PerlArray }
(I added an enumeration for the PMC types).
Wow, fine, fine.
Ok, committed, along with detailed instructions on how to use this and
various other debugging tricks in docs/debug.pod.
When I wrote it, I took a look at GC_VERBOSE. It's a bit changed, and
I can't figure out how it works anymore. Does it still work? I didn't
try.
Anyone with debugging tips, please add them to docs/debug.pod. (Well,
imcc-specific stuff should probably be elsewhere. I already have a
pointer to the command-line flags in languages/imcc/docs/running.pod.)
Parrot 0.0.10 freeze
As Leon pointed out in another thread, we're overdue for another release. I'd like to have a feature freeze on March 8, leading to a release within a week after. Any objections? Side note: I'll be gone Feb 26 - Mar 4. I'm assuming this will be 0.0.10, but if anyone sneaks in a complete implementation of exceptions or objects before then, I could be persuaded to call it 0.1.0. (Though at least for objects, I'd much rather have at least one trial release before officially calling it 0.1.)
Parrot 0.0.10 freeze
As Leon pointed out in another thread, we're overdue for another release. I'd like to have a feature freeze on March 8, leading to a release within a week after. Any objections? Side note: I'll be gone Feb 26 - Mar 4. I'm assuming this will be 0.0.10, but if anyone sneaks in a complete implementation of exceptions or objects before then, I could be persuaded to call it 0.1.0. (Though at least for objects, I'd much rather have at least one trial release before officially calling it 0.1.)
Re: Using imcc as JIT optimizer
[snip] Maybe we starting to get to the point of having imcc deliver parrot bytecode if you want to be portable, and something approaching native machine code if you want speed. IMHO yes, the normal options produce a plain PBC file, more or less optimized at PASM level, the -Oj option is definitely a machine optimization option, which can run or will create a PBC that runs only on a machine with equally or less mapped registers and the same external (non JITted instructions) i.e. on the same $arch. But the normal case is, that I compile the source for my machine and run it here - with all possible optimizations. I never did do any cross compilation here. Shipping the source is enough. Plain PBC is still like an unoptimized executable running everywhere - not a machine specific cross compile EXE. ... Or maybe if you want the latter we save fat bytecode files, that contain IMC code, bytecode and JIT-food for one or more processors. There is really no need for a fat PBC. Though - as already stated - I could imagine some cross compile capabilities for -Oj PBCs. Seems to me it would be good if - mycode.pl -- my original code would be compiled into - mycode.pbc/imc -- platform neutral parrot bytecode with (as I sort of suggested a day ago) no limitations on what registers there are, no spilling code, as that comes next... In someways, this is what IMC code is right now. Although it might be nice if IMC were binary at this stage (for some feel-good-reason?). The current bytecode from parrot already has potential for slowing things down, and that's what worries me here. which when run on any system would generate - mycode.jit -- a platform specific thing with native compiled code And as a worst case, if a system didn't have a jit module would just run the mycode.pbc, albeit not very speedily. This gives the developer several choices: 1. He can hand out his original source (which would require the target to be able to compile, jit) 2. He can hand out a platform neutral pbc/imc of compiled code that can be compiled to full speed (which would require the target to be able to either jit or just run it.) 3. He can hand out a platform specific .jit (which would require the target to be able to run it.) I suspect most end users would be able to use #1 or #2. However for use on embedded systems where size is an issue, having #3 an option would be useful, as I suspect it would shrink the footprint of parrot somewhat. Just the thoughts of a future parrot user :) Hope they benefit someone. Cheers, Phil
Re: Parrot 0.0.10 freeze
Steve Fink wrote: I'm assuming this will be 0.0.10 codename? I could be persuaded to call it 0.1.0 codename? Jerome -- [EMAIL PROTECTED]
Re: This week's Perl 6 Summary
First off, thanks to our relentless..., er, tireless summarizer for continuing to digest and clarify our wandering discussion. On Tue, 25 Feb 2003, Piers Cawley wrote: Using IMCC as JIT optimizer Apparently, Leo Tötsch finds it unbearable that 'optimized compiled C is still faster than parrot -j' so he's been experimenting with adding smarts to IMCC, making it add hardware register allocation hints to its emitted bytecode. Sean O'Rourke liked the basic idea, but reckoned that the information generated by IMCC should really be platform-independent, suggesting that it'd be okay to pass a control flow graph to the JIT, This isn't really my idea, but is instead an area of active research. A good jumping-off point is http://citeseer.nj.nec.com/krintz01using.html. Dan thought the idea was interesting too, but worried that the JIT might spend more time optimizing code than it could possibly gain from the optimization. Dan -- you might be interested in http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX subsription or a nearby university library). They stuff a full data-flow compiler into a JVM and, by carefully minimizing the number of passes, make it end up faster than a lightweight JIT on a number of programs. Granted, (IIRC) the real wins are on longer-running programs, so the result isn't as relevant to Parrot, but it _does_ show that there's room to put a fair amount of optimization into a JIT. /s
Re: This week's Perl 6 Summary
On Wed, Feb 26, 2003 at 09:31:39AM -0800, Sean O'Rourke wrote: Dan -- you might be interested in http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX Research wants to be free: http://www-hydra.stanford.edu/publications/JVM02.pdf -- Jason
[perl #21385] [PATCH]Patch to eliminate compiler warnings from packfile.c
# New Ticket Created by Steve Peters # Please include the string: [perl #21385] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21385 This patch eliminates compiler warnings generated when compiling packfile.c. In the function, fetch_op_mixed, the variables u and o are defined as local variables. Inside the function, however, one variable is used within different parts of a #if...#else..#endif statement. It then appears that one of the variables is unused. This patch places the variables within their own #if..#else..#endif to stop the warnings. Steve Peters [EMAIL PROTECTED] _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail -- attachment 1 -- url: http://rt.perl.org/rt2/attach/52824/39969/0249ad/packfile.c.patch packfile.c.patch Description: packfile.c.patch
[perl #21386] [PATCH]Patch to eliminate compilier warnings in interpreter.c
# New Ticket Created by Steve Peters # Please include the string: [perl #21386] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21386 This patch fixes compilier warnings generated when compiling interpreter.c. In the function runops_prederef, the local variables code_size and code_end are declared but never used. This patch removes these variable declarations and stops the compilier warnings. Steve Peters [EMAIL PROTECTED] _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- attachment 1 -- url: http://rt.perl.org/rt2/attach/52826/39972/138ed3/interpreter.c.patch interpreter.c.patch Description: interpreter.c.patch
[perl #21387] [PATCH]Patch to prevent compilier warnings in embed.c
# New Ticket Created by Steve Peters # Please include the string: [perl #21387] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21387 This patch is to stop compilier warnings in embed.c. The loop label again is only called inside of code where HAS_HEADER_SYSMMAN is defined. If HAS_HEADER_SYSMMAN is not defined, the loop label causes a warning when compiled. Steve Peters [EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- attachment 1 -- url: http://rt.perl.org/rt2/attach/52828/39975/da6239/embed.c.patch embed.c.patch Description: embed.c.patch
[perl #21388] [PATCH]Patch for jit.c to stop compilier warnings
# New Ticket Created by Steve Peters # Please include the string: [perl #21388] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21388 The attached patch is to stop compilier warnings in jit.c. The local variables i and typ are declared but never used in the function make_sections. Steve Peters [EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
[perl #21389] [PATCH]Patch to stop compiler warnings in dod.c
# New Ticket Created by Steve Peters # Please include the string: [perl #21389] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21389 This patch is to stop warnings from being generated when compiling dod.c. In the function trace_active_buffers, the local variables cur_stack and entry are declared but never used. Steve Peters [EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus -- attachment 1 -- url: http://rt.perl.org/rt2/attach/52832/39979/847da6/dod.c.patch dod.c.patch Description: dod.c.patch
Re: Using imcc as JIT optimizer
Phil Hassey wrote: ... The current bytecode from parrot already has potential for slowing things down, and that's what worries me here. I don't see that. My understanding is that PBC has a limit of 16 (32?) integer registers. When a code block needs more than 16 registers, they are overflowed into a PMC. There are 32 registers per type. When life analysis of all used temporary registers, can't allocate all used vars to a parrot register, then overflowed vars get spilled into a PerlArray. This may be different to just a block needs more than...: set $I0, 10 add $11, $I0, 2 print $I1 add $12, $I0, 3 print $I2 only needs two registers, $11 and $I2 get the same parrot register, because their usage doesn't overlap. But with a processor with 16 registers (do such things exist?). Parrot would be overflowing registers that it could have been using in the JIT. RISC processor have a lot of them. But before there are unused processor registers, we will allocate P and S registers too. When a CPU has more then 4*32 free registers, we will look again. Thanks, Phil leo
Re: Parrot 0.0.10 freeze
Jerome Quelin wrote: Steve Fink wrote: I'm assuming this will be 0.0.10 codename? I could be persuaded to call it 0.1.0 codename? Jerome while trolling for things parrot, I came upon this; http://www.kingsnicknames.co.uk/ Towards the bottom of this paragraph is the HIT, from which one could settle on BO-HO as a codename. is that obscure enough ? * Henry VIII*, /Walter, Bluff King Hal./ (1491-1547). Six times married King of England (1509-47). First marrying Catherine of Aragon the widow of his brother Arthur and daughter of Isabella and Ferdinand of Spain /the Catholic/ /Monarchs,/ they were divorced 1533 she spent the rest of her life in harsh confinement, and Henry married Anne Boleyn who was beheaded 1536 for adultery, Jane Seymour died 1537, Anne of Cleeves a political bride was so dull he had the marriage declared null and void, and Thomas Cromwell his advisor beheaded with Anne receiving a pension and retiring, Catherine Howard was beheaded in 1542, and Catherine Parr survived him. Named for his bluff and burley manners, later in his life nicknamed Bluebeard. Bluff meant broad faced in old English./ Burly King Hal, Copper-nose Harry, Stout Harry, Defender of the Faith/ the title bestowed by Pope Leo X, after Henry published his book On The Seven Sacraments, but revoked by Pope Paul III. An intelligent, cruel, greedy and popular Henry was not the tyrannical figure painted in legend, and he inspired equality, fear and devotion in his subjects. Called /Bo-Ho,/ in the satirical poem of 1521 called /Speake Parrot/ by his former tutor John Skelton, with the Lord Chancellor Cardinal Thomas Wolsey called /Hough/ No, and both represented as dogs.
String plan
Okay, here's the plan for the string rework. All the string functions we have now should keep their names and signatures. They do reasonable things, and that's just fine. What we need is shadow functions that do the same thing, only get passed in the destination string. Or, rather, we need to rename the current functions and change the signature to take a destination string, and add in wrapper functions with the current names that do a string_new and pass that in to the real function. Once we do that, we need to think about how to note that a string op should reuse the destination register. I'm half-tempted to postpend a R to the name, but that's a bit nasty. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using imcc as JIT optimizer
[ you seem to be living some hors ahead in time ] Yep, sorry about that. The problem stays the same: spilling processors to parrot's or parrots to array. Thinking a bit more about it, now I believe that the best way to do it would be: (1) First, do a register allocation for machine registers, assuming that there are N machine registers and infinite parrot registers. (2) Second, do a register allocation for parrot registers, using an array as spill area. The first step assures us that we generate code that always puts data in the availabe machine registers, and tries to minimize moves between registers and the physical memory. The second step tries to put all the data in parrot registers, and if it is not able to do that in the parrot spilling area (currently an PerlArray) For example, code generated by (1) would look like: set m3, 1 # m3 is the machine 3d register add m3, m3, 1 print m3 set $I1, m3 # $I1 is a parrot virtual register etc... Then we would do register allocation for the virtual $I1 registers, hoping to be able to put them all in the 32 parrot registers. I believe this would be the optimal way to do it, because it actually models our priorities: first to put all data in physical registers, otherwise try do it in parrot registers. This is better than reserving the machine registers for the most used parrot registers (your original proposal) or doing a pyhsical register allocation and assuming that we have an infinite number of parrot registers (my original proposal). Hope that it know make more sense, -angel
Re: Using imcc as JIT optimizer
Phil Hassey wrote: [snip] Although it might be nice if IMC were binary at this stage (for some feel-good-reason?). You mean, that a HL like perl6 should produce a binary equivalent to ther current .imc file? Yep - this was discussed already, albeit there was no discussion, how this should look like. And the lexer in imcc is pretty fast. ... The current bytecode from parrot already has potential for slowing things down, and that's what worries me here. I don't see that. 3. He can hand out a platform specific .jit (which would require the target to be able to run it.) I suspect most end users would be able to use #1 or #2. However for use on embedded systems where size is an issue, having #3 an option would be useful, as I suspect it would shrink the footprint of parrot somewhat. The JIT-PBC for #3 has a somewhat larger size then plain PBC due to register load/store ops and an additional CFG/register usage PBC section. But running it does require less memory, because the JIT optimizer doesn't have to create all the internal bookkeeping tables. Cheers, Phil leo
Re: This week's Perl 6 Summary
At 12:41 PM -0500 2/26/03, Jason Gloudon wrote: On Wed, Feb 26, 2003 at 09:31:39AM -0800, Sean O'Rourke wrote: Dan -- you might be interested in http://www.usenix.org/events/javavm02/chen_m.html (if you have a USENIX Research wants to be free: http://www-hydra.stanford.edu/publications/JVM02.pdf And wants to be mine. Snagged, thanks. I do realize that a good optimizing JIT is a win in some cases, and I'd love to have one. The problem is engineering time--I'm not willing to presume on Leo, Daniel, and everyone else who's done JIT work to get two JITs, one for quick programs and one for longer ones. And with that limitation, I'd rather have a lower-overhead JIT with a win for the shorter programs than a high-overhead one with a win for long-running programs. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using imcc as JIT optimizer
Angel Faus wrote: (1) First, do a register allocation for machine registers, assuming that there are N machine registers and infinite parrot registers. This uses equally the top N used registers for processor regs. The spilling for (1) is loading/moving them to parrot registers/temp registers. Only the load/store would be that what spilling code makes out of those. Then you still have 32 parrot registers per kind to allocate. But it is not as easy as it reads: We have non preserved registers too, which can be mapped, but are not preserved over function calls, so they must, when mapped and used, be stored to parrots regs and reloaded after extern function calls, if used again in that block or after. Albeit load/stores of this kind can be optimized, depending on register usage. For example, code generated by (1) would look like: set m3, 1 # m3 is the machine 3d register add m3, m3, 1 print m3 set $I1, m3 # $I1 is a parrot virtual register Not exactly: print is an external function. Assuming ri0 - ri3 are mapped, ri3 is not callee saved: set ri0, 1 add ri0, 1 set $I0, ri0 # save for print $I0 set $I1, ri3 # save/preserve the register, when used print $I0 # external function set ri3, $I1 # load add ri3, ri1, ri2 # do something (For debugging mapped registers are printed ri0..x or rn0..y by imcc) Hope that it know make more sense, More, yes. This would give us 32 + N - (0..x) registers, where x is the amount of non callee saved registers in the worst case, or 0 most of the time. The $1 above can be always a new temp, which would then have a very limited life range inside one basic block. -angel leo
Re: Using imcc as JIT optimizer
Although it might be nice if IMC were binary at this stage (for some feel-good-reason?). You mean, that a HL like perl6 should produce a binary equivalent to ther current .imc file? Yep - this was discussed already, albeit there was no discussion, how this should look like. And the lexer in imcc is pretty fast. ... The current bytecode from parrot already has potential for slowing things down, and that's what worries me here. I don't see that. My post was more a wish-list of what I was hoping parrot would be like in terms of imc/pbc/jit/whatever. Since I don't completely understand how parrot works, my comment above was actually more of a guess. But I'll try to explain what I meant, in the off-chance it was right. My understanding is that PBC has a limit of 16 (32?) integer registers. When a code block needs more than 16 registers, they are overflowed into a PMC. With a processor with 16 registers, I guess this would work. Although the JIT would have to overflow more than what was originally planned in the PBC. (Or does it just switch back and forth between the VM and the JIT, I don't know.) But with a processor with 16 registers (do such things exist?). Parrot would be overflowing registers that it could have been using in the JIT. My guess is that this would slow things down. Anyway, before I strut my ignorance of VMs and JITs and processors anymore, I think I will end this message. :) Thanks, Phil
[perl #21378] can't locate new method in package uri
# New Ticket Created by logo # Please include the string: [perl #21378] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21378 I was trying to install the latest version of libwww-perl with my 5.8.0 installation of perl. Everytime I run make test I get the following error: can't located object method new in package URI at /usr/local/lib/perl5/site_perl/5.8.0/HTTP/Response.pm. One of the prerequisites for libwww is the URI module. However I definately have this module installed and installed properly. I've been able to locate others who have had this problem as well, but noone was able to help them resolve the issue. If anyone knows what's going on and what I can do to fix this I would be very appreciative. _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: [RFC] imcc calling conventions
Piers Cawley wrote:
Benjamin Goldberg [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[snip]
Um... no. tail call optimization implies being able to replace *any*
tail call, not just a recursive one with a simple goto.
[snip]
In perl5, doing a tail call optimization can be done with just a simple
goto... well, 'goto subname', anyway. (Well, first you'd assign
something to @_, then goto subname).
Ah... this discussion has been done in p5p and elsewhere; whilst goto
sub could, in theory, do tail call optimization, in practice it seems
to be as slow as any other function call.
Really? I did not know that.
However, even if it's not significantly faster, at least it saves
memory, by discarding a level of saved stack information.
Since (supposedly) there's going to be a perl5-parrot compiler, there
needs to be support for perl5's goto subname. ISTM that once we have
figured out an efficient way of implementing that, we'll also have an
efficient way of doing native tail call optimization.
As a wild-ass-guess, an optimized tail call will look something like:
.sub _foo # sub foo(int a, int b)
saveall
.param int a # a = pop @_
.param int b # b = pop @_
...
.arg int x # push @_, x
.arg int u # push @_, u
.arg int q # push @_, q
restoreall
jnsr _bar # goto _bar
.end
.sub _bar # sub bar(int q, int u, int x) {
saveall
.param int q # q = pop @_
.param int u # u = pop @_
.param int x # x = pop @_
...
.return int pl # push @_, pl
.return int ml # push @_, ml
restoreall
ret
.end
The 'jnsr' opcode (JumpNoSaveReturn) might be spelled as 'j' or as
'goto', or something else entirely, depending on what's least confusing,
and most aesthetically pleasing.
The problem here is that you've pushed two loads of registers onto the
register stack, and the return is only going to pop one set off.
I think you're overlooking the restoreall done just before the
jump-no-save-returnaddress operation... I see two savealls and
two restorealls.
At the point that 'jnsr _bar' is called, all the stacks should look
exactly as if the code which called _foo had called _bar instead.
(The ret doesn't pop a set of registers, just an address to goto.)
And it'll be the wrong set at that. And you can't add an extra
'restoreall' to _bar because _bar could easily be called normally as
well as via a tailcall.
I would not have suggested such a thing. Tail call optomization in
parrot should be about the same logical semantics as perl5's goto
subname (except maybe being faster).
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0
my$__;s ee substr$;,$,++$__%$,--,1,qq;;;ee;
$__2__}$,=22+$;=~y yiy y;__ while$;;print
Re: Parrot 0.0.10 freeze
Jerome Quelin wrote:
Steve Fink wrote:
I'm assuming this will be 0.0.10
codename?
I could be persuaded to call it 0.1.0
codename?
African Grey, Brotogeris, Parakeet, Budgerigar, Budgie, Cockatiel,
Cockatoo, Conure, Eclectus, Kakapo, Lory, Lorikeet, Lovebird, Macaw,
Parrotlet, Pionus, Poicephalus, Quaker, Ringneck?
Since we don't have any of objects, exceptions, or a real IO system, I
would suggest Kakapo (which is a kind of weird flightless parrot).
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0
my$__;s ee substr$;,$,++$__%$,--,1,qq;;;ee;
$__2__}$,=22+$;=~y yiy y;__ while$;;print
Re: Parrot 0.0.10 freeze
Benjamin Goldberg wrote: African Grey, Brotogeris, Parakeet, Budgerigar, Budgie, Cockatiel, Cockatoo, Conure, Eclectus, Kakapo, Lory, Lorikeet, Lovebird, Macaw, Parrotlet, Pionus, Poicephalus, Quaker, Ringneck? Since we don't have any of objects, exceptions, or a real IO system, I would suggest Kakapo (which is a kind of weird flightless parrot). Once we do have these things (0.1 or 0.2 ? ) how about codename greencheeks for the Green-cheaked parrot? -Tupshin
