Re: Basic compilation example (a + b)?

[Leopold Toetsch]

Jeff Clites wrote:
% cat pythonClass.py
class A:
def __add__(x,y) : return "boo"
Only a few standard methods are implemented. __add__ IIRC isn't.
new P16, 32  # .PerlInt
add P16, P18, P17
That's what worries me, and what prompted the question. You don't know 
at compile-time that the return type should be a PerlInt.
Yes, I've already stated that this needs fixing and I've proposed a 
scheme how to fix it.

leo

Re: Parrot install

[Leopold Toetsch]

Jack J. Woehr <[EMAIL PROTECTED]> wrote:
> A suggestion about Parrot install:

> I thought the --prefix argument was like in Gnu configs, but I find
> that --prefix=/usr/local/uplevel results in a lot of Parrot stuff
> being dumped unceremoniously into that very directory instead of only
> in subdirectories. This install process should either restrict itself
> to subdirs or be more finely grained.

Well, the default is /usr/local/parrot-$(VERSION) but you are of course
right.

leo

Re: [perl #32356] AutoReply: [PATCH] update to embed.pod

[Leopold Toetsch]

Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> Patch attached to get a snipped that compileds without the
> #include "parrot/parrot.h"


Thanks, applied.
leo

Re: [perl #32369] Register Stomping Bug

[Leopold Toetsch]

Matt Diephouse <[EMAIL PROTECTED]> wrote:

> After the new calling scheme was put in place, my Forth implementation
> started having some problems. I've stripped down and attached the files
> along with a trace. Here's the input/output:

>[EMAIL PROTECTED]:~/parrot/forth$ ../parrot forth.pir

Two notes:
Your compiler seems to emit subroutines all called "main".
The compiled subroutines should return with the current continuation.

Finally. Code created through compile is currently not preserving
registers. See yesterdays mail: "Q: eval". This needs some clarification
first and fixing.

leo

[perl #32374] [TODO] Command line support for various compilers

[via RT]

# New Ticket Created by  Will Coleda 
# Please include the string:  [perl #32374]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32374 >


I was talking with Dan on IRC about what we're going to do as a replacement for 
macros. Talk turned to implementing a registered 'compile'r for "pre parsed 
PIR". 

For this to be useful, of course, we'd need to be able to run it from the 
command line. As dan said:

<@Dan> Sure. Add it as a todo, since that's what we should do. The
 bytecode loading system should autodetect based on extension or
 magic info, or with a -switch of some sort

Which I take to mean, something like:

./parrot foo.pimc #parsed imc - automatic detection
./parrot foo.pbc  #magic info in pre-compiled bytecode
./parrot -lang=ppir foo.imc #file contains parsed imc with a sneaky filename.

The primary issue I see is the ability to register official compilers in your 
parrot build. For example, I provide a tcl compiler - but we'd need a way for

./parrot foo.tcl

to be able to find tcl's compiler. (or tell you the reason why.)

This would also eventually let me do something evil, like:

% ln /usr/local/bin/parrot /usr/local/bin/tclsh
% cat foo.tcl
#/usr/local/bin/tclsh
puts "whee!"
% chmod a+x foo.tcl
% ./foo.tcl
whee!
%

Perl 6 Summary for 2004-11-01 through 2004-11-08

[Matt Fowles]

Perl 6 Summary for 2004-11-01 through 2004-11-08
All~

Welcome to yet another summary, brought to you (once again) with the aid
of the musical stylings of Dar Williams and Soul Coughing and a small
stuffed elephant name Aliya. And, without further ado, I give you Perl 6
Language (whose traffic has picked up a little)...

  Perl 6 Language
   What was that anonymous thing?
Juerd wondered what things could be named and what anonymous. Larry
provided the answer: Subtypes, Enums, Lists (Lazy and Eager), Grammars,
and Packages, but then threatened to attack Juerd with hot grits.



   updated Apocalypses and Synopses
Larry proved links to the current versions of the various Apocalypses
and Synopses. Unfortunately he forgot to start a new thread with his
message...



http://www.wall.org/~larry/apo -- apocalypses
http://www.wall.org/~larry/syn -- synopses

   suggested warning for overriding operators
Aaron Sherman wanted to receive a warning for defining things like
"multi sub *infix:+(...) {...}". But Larry reasoned the anyone who'd use
the * there does not care for warnings.



  Perl 6 Compiler
Last week, I bemoaned my lack of google (and thus links). But a couple
kind souls pointed out that I could get links straight from the horses
mouth: nntp.perl.org. All I can say is, ::shrug:: "Who knew that there
was an internet outside of google?". Fortunately, I do not have to admit
to its existence as there were no message this week.

  Parrot Internals
   she-bangs for none!!
Last week James deBoer offered a patch to remove all of the shebang
lines from config/*.pl (after his initial patch to add them to all of
them was turned away). Warnock applies.



   Solaris 9 troubles
Christian Aperghis-Tramoni has some trouble whil trying to install on
Solaris 9. Warnock applies.

   more vtables
Leo wanted to add a finalize vtable entry (in addition to destroy, which
is apparently use for free memory and not active resources). Jeff
commented on the difficulties implicit in finalizing stuff, and the
thread ran out of gas.



   build dynclasses by default
Last week, Leo was stalling to here about success and failures before
adding them to the default build. Brent 'Dax' Royal-Gordon and Sam Ruby
both chimed in with success. And so they did.





   register frame recycling
Leo added in some basic continuation recycling. Dan didn't like that it
required the user to clone return continuations into full ones. Leo
agreed, but felt that a returncc function would be needed first. I
wondered why we needed this recycling and couldn't just let the DOD/GC
do it for us. The answer: speed.



   upcase binary strings
Dan wondered what should happen if you tried to play with the case of a
binary encoded string. The concensus seems to be either throw an
exception or nothing, depending on settings.



   setref poorly named
Sam Ruby was initially confused by the strange behavior of setref. Leo
told him that it was intended to set a reference inside a reference type
and noted that classes needs a clean up. With the advent of dynclasses,
this sounds like a job for some adventurous lurker...



   tracebacks pmc vs ops
Leo wondered if we should have a PMC that could access the entire call
chain and do whatever evil it wanted. Dan conjectured that this sort of
thing was evil enough that ops might be well advised. Leo initially put
some methods into the continuation to do this, but later though about
putting them into the interpreter instead. I like the interp idea.



   parrot -t memory leaks
Last week our fearless leader notice some not insignificant memory leaks
with parrot -t. This week our fearless pumpking fixed them.



   Performance graphs
Matt Diephouse (assisted by Joshua Gatcomb) provided a pointer to a page
of periodic parrot performances, provided as pretty pictures. Please
provide possible improvement pointers.







   uniline yield() and return()
Stéphane Payrard (whose name google objects to strenuously) resent his
patch for uniline yield and return in PIR. Leo applied the patch.



   mod_parrot 0.1
Jeff Horwitz released mod_parrot 0.1. Pretty nifty.





   IO auto-flush troubles
Christian Aperghis-Tramoni wondered how to make stdout not buffer away
his prompt. The answer (provided by Mary Pauley and Luke Palmer) require
using pioctl and strange magic numbers

Re: Basic compilation example (a + b)?

[Jeff Clites]

On Nov 8, 2004, at 2:47 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
What pasm is supposed to correspond to this snippet of Python code
(assume this is inside a function, so these can be considered to be
local variables):

a = 7
b = 12
c = a + b
Run it through pie-thon. It should produce some reasonable code. For
leaf-functions (w/o introspection i.e. calls to locals()), the lexical
handling would get dropped. And a better translator would use lexical
opcodes by index and not by name.
It doesn't do-the-right-thing in the cases I'm interested in:
% cat pythonClass.py
class A:
def __add__(x,y) : return "boo"
x = A()
y = x + 3
print y
% python pythonClass.py
boo
% perl pie-thon.pl pythonClass.py | ./parrot --python -
Can't find method '__get_number' for object 'py::A'
It looks like it's trying to get the float-value of x, rather than 
calling x's __add__ method.

But the part I was really wondering about is the "a + b". This is what 
pie-thon.pl produces for that (you can just run it on the code fragment 
"a + b"--it doesn't matter the context):

$P1 = new PerlInt   # BINARY_ADD
$P1 = a + b
corresponding pasm:
find_global P18, "a"
find_global P17, "b"
new P16, 32  # .PerlInt
add P16, P18, P17
That's what worries me, and what prompted the question. You don't know 
at compile-time that the return type should be a PerlInt. It could be 
anything--it's really up to "a". This is regarding my concern that the 
p_p_p ops aren't very useful (in Python at least), and I can't figure 
out what we should be using instead.

So I'm still left wondering, how *should* this compile?
JEff

[perl #32369] Register Stomping Bug

[via RT]

# New Ticket Created by  Matt Diephouse 
# Please include the string:  [perl #32369]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32369 >


After the new calling scheme was put in place, my Forth implementation 
started having some problems. I've stripped down and attached the files 
along with a trace. Here's the input/output:

   [EMAIL PROTECTED]:~/parrot/forth$ ../parrot forth.pir

   > 1

   > .
   1
   > get_bool() not implemented in class 'RetContinuation'
   [EMAIL PROTECTED]:~/parrot/forth$

And the last two lines of the trace:

 36 print "\n> "
 38 readline S16, P17- S16="", 
P17=RetContinuation=PMC(0x83649b8 Adr:0x8507f54)
get_bool() not implemented in class 'RetContinuation'

You can also get an error (I don't know if it's related) by typing "1 
.\n" in the prompt.

--
matt diephouse
http://matt.diephouse.com



forth.pir
Description: Binary data


forthlib.pir
Description: Binary data


trace.log
Description: Binary data

Re: Win XP problems

[Christian Lott]

Jonathan Worthington wrote:
"Peter Sinnott" <[EMAIL PROTECTED]> wrote:
On Mon, Nov 08, 2004 at 12:56:50PM +0100, Leopold Toetsch wrote:
Christian Lott <[EMAIL PROTECTED]> wrote:
> I have Active State Perl. I have MSVC. I have the POW version of > 
Parrot.

What is POW? Parrot on Windows? Who does maintain it?
Possily he means http://www.jwcs.net/developers/perl/pow/
but that seems to have precompiled for windows parrot binaries
with no source.
The website mentions Jonathan Worthington as the maintainer.
'fraid that'd be me.  From the Parrot On Win32 documentation:-
"This distribution contains the Parrot executables that result from 
compiling the source under Windows, to save you having to compile it 
yourself. Documentation, examples, tests, compilers and interpreters 
for a number of languages at various stages of completion and a few 
other assorted odds and ends are also included."

Which (obviously not clearly enough ;-) implies that the source isn't 
included.  This is like getting ActiveState Perl; you're getting 
something ready to run, not something you have to compile.  To get 
something to compile, look to the Parrot site 
(http://www.parrotcode.org/).

Hope this helps,
Jonathan

So this is what I get:
--
[x] This application has failed to start because MSVCRTD.dll was not 
found. Re-installing the application may fix this problem.
--

Ok. Just downloaded it at -
http://www.dll-files.com/dllindex/dll-files.shtml?msvcrtd
placed it in the MSVC \bin directory and typed "perl t\harness"
At the end this is what I got:
--
t/library/streams..ok 21/21# Looks like you failed 2 tests 
of 21.
t/library/streams..dubious
   Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 14, 18
   Failed 2/21 tests, 90.48% okay
Failed Test   Stat Wstat Total Fail  Failed  List of Failed
--
imcc/t/imcpasm/cfg.t 3   768 33 100.00%  1-3
imcc/t/imcpasm/opt0.t6  1536 66 100.00%  1-6
imcc/t/imcpasm/opt1.t   47 1203249   47  95.92%  1-47
imcc/t/imcpasm/pcc.t 1   256111   9.09%  1
imcc/t/imcpasm/sub.t 2   512 22 100.00%  1-2
t/library/streams.t  2   512212   9.52%  14 18
t/pmc/nci.t  6  1536466  13.04%  33 35-37 42-43
t/pmc/perlnum.t  1   256431   2.33%  36
t/pmc/sub.t255 6528076   28  36.84%  63-76
6 tests and 54 subtests skipped.
Failed 9/111 test scripts, 91.89% okay. 82/1859 subtests failed, 95.59% 
okay.

C:\parrot>
--
Sound right?
Thanks Johnathan.
I get frustrated and side tracked really easy when I have no idea what 
I'm doing. My fault.

Christian

Re: The Saga of Building Parrot : ICU

[Jack J. Woehr]

Matt Diephouse wrote:

> Oops. I forgot to mention that some recent (big) changes to Parrot has
> been causing my Forth implementation some trouble. I filed a bug
> report earlier today; hopefully it'll get fixed soon (generally
> doesn't take long).

No problem ... my interest is tangential at the moment, though I look forward
to Perl 6. Thanks again Matt and Leopold and Dan and everyone for all your
help. Now I'm off to see how far I get with Perl 6 itself.

--
Jack J. Woehr # Ordinator consistetvr,
PO Box 51, Golden, CO 80402   # redintegrandvs tandem
http://www.well.com/~jax  # tangenda qvodvis clavis.

Re: The Saga of Building Parrot : ICU

[Matt Diephouse]

On Mon, 08 Nov 2004 18:41:50 -0700, Jack J. Woehr <[EMAIL PROTECTED]> wrote:
> Matt Diephouse wrote:
> > Enjoy (Parrot). :-)
> 
> I did ... briefly!

[ . . . ]

>  > Segmentation Fault (core dumped)

Oops. I forgot to mention that some recent (big) changes to Parrot has
been causing my Forth implementation some trouble. I filed a bug
report earlier today; hopefully it'll get fixed soon (generally
doesn't take long).

-- 
matt

Re: The Saga of Building Parrot : ICU

[Jack J. Woehr]

Matt Diephouse wrote:

> Enjoy (Parrot). :-)

I did ... briefly!

 [17:33:55 [EMAIL PROTECTED]:/usr/local/src/PerlSource/parrot_stuff/forth]$ 
parrot forth.pir
 Parrot Forth 0.1
 Type `bye` to exit
 > words
 over 2* spaces */ swap 2dup rot drop depth cr 0sp - space words / emit . 
dup ?dup + * pick .s bye -rot

 > Segmentation Fault (core dumped)
 [17:34:00 [EMAIL PROTECTED]:/usr/local/src/PerlSource/parrot_stuff/forth]$

--
Jack J. Woehr # Ordinator consistetvr,
PO Box 51, Golden, CO 80402   # redintegrandvs tandem
http://www.well.com/~jax  # tangenda qvodvis clavis.

Parrot install

[Jack J. Woehr]

A suggestion about Parrot install:

I thought the --prefix argument was like in Gnu configs, but I find
that --prefix=/usr/local/uplevel results in a lot of Parrot stuff being dumped 
unceremoniously
into that very directory instead of only in subdirectories. This install 
process should either
restrict itself to subdirs or be more finely grained.

--
Jack J. Woehr # Ordinator consistetvr,
PO Box 51, Golden, CO 80402   # redintegrandvs tandem
http://www.well.com/~jax  # tangenda qvodvis clavis.

Re: Win XP problems

[Christian Lott]

Having a little trouble with vim.
I think the problem is that imc.vim.in needs to go through ops2vim.
C:\parrot\editor>perl ops2vim.pl imc.vim.in imc.vim
Can't open imc.vim: No such file or directory at ops2vim.pl line 8, <> 
line 85.
syn keyword imcOp

C:\parrot\editor>perl ops2vim.pl imc.vim imc.vim.in
Can't open imc.vim: No such file or directory at ops2vim.pl line 7.
syn keyword imcOp
C:\parrot\editor>perl ops2vim.pl imc.vim.in
syn keyword imcOp

This is in the .NET window (MSVC).
I'm placing these files into the /vimfiles directory which is adjacent 
to the vim63 directory both of which are under the VIM directory.

Re: calling conventions, tracebacks, and register allocator

[Dan Sugalski]

At 9:39 PM +0100 11/8/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
 Okay, aesthetics and making up for a flaw in the implementation of
 how IMCC tracks opcodes and registers.
That flaw is caused by the assymmetry of opcodes, or by indirect
register usage if opcodes like bare C.
But as that shall not be fixed now, lets' keep all these ugly hacks.
It's so nice to see that any design element you don't approve of is 
referred to in such glowing terms...

Regardless, now that this matter's closed it's time to get other 
stuff going. Tail calls, for one.

 > Neither of those are sufficient, individually or together.
Your code is spilling ... ;)
Well, duh. I've got a single sub with over a meg of source and 20k+ 
explicit temps. Of *course* it's going to make the register coloring 
algorithm scream. While the coloring and spilling code needs help, 
feeding it naively generated code is part of the problem.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: calling conventions, tracebacks, and register allocator

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:

> Okay, aesthetics and making up for a flaw in the implementation of
> how IMCC tracks opcodes and registers.

That flaw is caused by the assymmetry of opcodes, or by indirect
register usage if opcodes like bare C.
But as that shall not be fixed now, lets' keep all these ugly hacks.

> Neither of those are sufficient, individually or together.

Your code is spilling ... ;)

leo

Re: [perl #32356] AutoReply: [PATCH] update to embed.pod

[Stéphane Payrard]

No need to modify embed.h.
Patch attached to get a snipped that compileds without the
#include "parrot/parrot.h"


--
 stef--- docs/embed.pod.orig 2004-11-08 10:48:59.0 +0100
+++ docs/embed.pod  2004-11-08 20:42:57.209202168 +0100
@@ -7,7 +7,6 @@
 
 =head1 SYNOPSIS
 
-#include "parrot/parrot.h"
 #include "parrot/embed.h"
 
 int main(int argc, char *argv[]) {
@@ -17,7 +16,7 @@
 
 argc--; argv++; /* skip the program name */
 
-interp=Parrot_new(NULL);
+interp=Parrot_new(0);
 Parrot_init(interp);
 
 if(PARROT_JIT_CAPABLE) {

Re: calling conventions, tracebacks, and register allocator

[Dan Sugalski]

At 2:15 PM -0500 11/8/04, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 The calling conventions and code surrounding them will *not* change
 now. When all the sub stuff, and the things that depend on it, are
 fully specified and implemented... *then* we can consider changes.
 Until then, things stand the way they are.
I missunderstood.  I though you were saying that what is currently in
is final and will *never* be changed.  Thanks for the clarification.
Ah, OK. I was unclear, then. Sorry for the confusion.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: calling conventions, tracebacks, and register allocator

[Matt Fowles]

Dan~

On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The calling conventions and code surrounding them will *not* change
> now. When all the sub stuff, and the things that depend on it, are
> fully specified and implemented... *then* we can consider changes.
> Until then, things stand the way they are.

I missunderstood.  I though you were saying that what is currently in
is final and will *never* be changed.  Thanks for the clarification.

Matt
-- 
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???

Re: calling conventions, tracebacks, and register allocator

[Dan Sugalski]

At 1:38 PM -0500 11/8/04, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:23:36 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 Okay, aesthetics and making up for a flaw in the implementation of
 how IMCC tracks opcodes and registers.
 Neither of those are sufficient, individually or together.
It feels to me like you are dismissing Leo's arguments a little too
lightly here.  I find his logic fairly convincing...
No, I'm not dismissing this stuff lightly. Leo's point to me earlier 
is dead-ion correct -- screwing around with the design before 
everything is specified and we have a working implementation is 
premature optimization. And screwing around with stuff that works 
when there's stuff that doesn't is misdirected effort.

The calling conventions and code surrounding them will *not* change 
now. When all the sub stuff, and the things that depend on it, are 
fully specified and implemented... *then* we can consider changes. 
Until then, things stand the way they are.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: calling conventions, tracebacks, and register allocator

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:

> [calling convention change snippage]

> I've already said no changes to the calling conventions, quite a
> while ago.

This doesn't really change calling convention, it changes call opcodes.
It makes register usage explicit.

> ... I don't see inconvenience in the register allocation code
> as a reason to change it. Got a better reason?

1) please grep -w invoke in imcc. There is quite an amount of code that
tracks register usage of this opcode.

2) I've outlined that the usage of especially P0 - P2 blocks registers
because we've to allocate them as non-volatiles too. This reduces
the usable register count by 3 for methods.

Current produced code looks like this:

   set P16, P1  # preserve our return continuation
   set P17, P2  # preserve self
   set S0, "meth"   # this method unavailable
   set P2, obj
   callmethodcc  # call the meth  P0 gets overwritten
   set P1, P16   # restore P1
   set P2, P17   # restore self

3) We have these variables in the context. Having them in registers too
just duplicates argument copying. It's not needed.

The return continuation works similar to the link register on PPC. There
are 2 opcodes to access this register. You can use it for branches...
Why should we have it additionally in P1, where it clutters the caller's
usage of P1 to be able to return?

leo

Re: calling conventions, tracebacks, and register allocator

[Matt Fowles]

Dan~

On Mon, 8 Nov 2004 13:23:36 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, aesthetics and making up for a flaw in the implementation of
> how IMCC tracks opcodes and registers.
> 
> Neither of those are sufficient, individually or together.

It feels to me like you are dismissing Leo's arguments a little too
lightly here.  I find his logic fairly convincing...

Matt
-- 
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???

Re: calling conventions, tracebacks, and register allocator

[Dan Sugalski]

At 7:17 PM +0100 11/8/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
 At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:

 [calling convention change snippage]

 ... Got a better reason?
And there is of course:
4) invoke's (and friends) register usage is assymmetrical and ugly.
[snip]
Ad 1) again a note: Imcc's instructions have *r[16] attached, a NULL
terminated list of used registers/operands. This list doesn't have the
length of the opcode's arguments because of such opcodes like invoke. The
argument count of a plain C is 0, but in r[0] a reference to P0
is created to track the implicit usage of P0.
Okay, aesthetics and making up for a flaw in the implementation of 
how IMCC tracks opcodes and registers.

Neither of those are sufficient, individually or together.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: calling conventions, tracebacks, and register allocator

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:

> [calling convention change snippage]

> ... Got a better reason?

And there is of course:

4) invoke's (and friends) register usage is assymmetrical and ugly. It's
like defining:

   set 5  # set I0, 5

Ad 1) again a note: Imcc's instructions have *r[16] attached, a NULL
terminated list of used registers/operands. This list doesn't have the
length of the opcode's arguments because of such opcodes like invoke. The
argument count of a plain C is 0, but in r[0] a reference to P0
is created to track the implicit usage of P0.

This all complicates code generation for no good.

This are really reasons enough.

leo

Re: [perl #32356] AutoReply: [PATCH] update to embed.pod

[Dan Sugalski]

At 9:39 AM -0800 11/8/04, Brent 'Dax' Royal-Gordon wrote:
On Mon, 8 Nov 2004 02:38:16 +0100, Stéphane Payrard <[EMAIL PROTECTED]> wrote:
 +#include "parrot/parrot.h"
  #include "parrot/embed.h"
Unless things have changed far more than I thought, this is very,
very, very, very, very wrong.  parrot.h is an internals-only
header--including it exposes all of Parrot's guts to the embedder.
Definitely. It's:
  *) parrot.h for internal code
  *) extend.h for code writing extensions to parrot in C
  *) embed.h for code embedding a parrot interpreter
Neither extend.h nor embed.h should include parrot.h.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: perl6-internals Digest 7 Nov 2004 21:01:00 -0000 Issue 1135

[Michel Pelletier]

> We now have dedicated PMC* pointers in the context that hold 
> current_cont, current_sub, and current_object. This is necessary to 
> create traceback information. But subroutine and return opcodes are not 
> adapted yet.
> 
> We have e.g.:
> 
> invoke # implicitely P0 and use P1 for return
># could also be a method call
> invoke P1  # likely a return
> 
> The implicit usage of P0 in function and method calls is a PITA for the 
> register allocator, all this implicit usage causes special handling n 
> code, so that P0 gets properly tracked.

Special handling on both your end and the PIR programmers end.  I found the 
implicit registers to be pretty confusing.
 
> Additionally, P0 and especially P1 is first created in the callers 
> registers. This implies that the old contents of P1 has to be preserved 
> by copying to another register,

Which Parakeet does in every sub it generates.

> which increases pressure on the register  
> allocator. The same is done for P2 in method calls. This scheme just 
> reduces the usable register count by 3 in methods and by 2 in functions.
>
> To streamline that and take advantage of the current_* pointers in the 
> context, I'd like to adapt call/return ops slightly:
> 
>invoke PSub, PRet   # replaces implicit P0, P1 handling
>invokecc PSub   # replaces implicit invokecc [P0]
>callmethod Pobj, Smeth, Pret  # analog, no implicit S0
>callmethodcc Pobj, Smeth
>ret_cc  # replaces invoke P1
> 
> This gets rid of all hidden register semantics of these opcodes and 
> makes it explicit for the register allocator (and when reading the 
> code), which registers are used. As a minor improvement it also avoids 
> the "set P0, PSub" and such opcodes, to move the needed registers in place.

Please!  Myself being only a PIR user right now this makes so much more sense.  
Explicit is better than implicit.  These objects are lying around in P 
registers or local vars anyway.  This would remove several annoying 
contortions in Parakeet.

This might be heretical, but I think you should change the unprototyped 
calling convention so that *all* of the arguments are in an array, not the 
first 11 in PMCs and the rest in an overflow array.  Most unprototyped high 
level languages or reflection APIs are building their arguments dynamicly 
anyway.  If one unprototyped language were to call into another unprototyped 
language, chances are it would  build the argument list at runtime.  Setting 
up registers is a PITA.  Pass an array, it has a length, your done.
 
> In the called subroutine P2 remains "self". But P0 and P1 (current sub 
> and continuation) are available only on demand, currently with the 
> interpinfo opcode. Maybe two opcodes for that are in order too:
> 
> get_sub Px   # simplifies coroutines
> get_cc  Px   # simplifies call/cc

and a get_self opcode.  I see no reason why it or anything else should be 
implicit.

-Michel

Re: [perl #32356] AutoReply: [PATCH] update to embed.pod

[Brent 'Dax' Royal-Gordon]

On Mon, 8 Nov 2004 02:38:16 +0100, Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> +#include "parrot/parrot.h"
>  #include "parrot/embed.h"

Unless things have changed far more than I thought, this is very,
very, very, very, very wrong.  parrot.h is an internals-only
header--including it exposes all of Parrot's guts to the embedder.

Note this comment at the top of parrot.h:

# /* Only parrot core files should include this file.
#Extensions should include .
#Programs embedding parrot should include .
# */

And the define a few lines down:

# #define PARROT_IN_CORE

-- 
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker

There is no cabal.

Re: Win XP problems

[Ron Blaschke]

On Mon, 08 Nov 2004 10:46:47 -0600, Christian Lott wrote:

> Ron Blaschke wrote:
>>No.  Look for a batch file called vcvars32.bat below the Microsoft Visual
>>C++ 2003 directory, and run it.  It'll setup your environment.
>>"dir /s vcvars32.bat"
> OK. Path set.
> Now what?

Assuming you got the full source, follow the instructions in README.win32.
(I hope we are not still talking about the POW stuff...)

Re: PIR: Arguments are passed without passing them

[Dan Sugalski]

At 10:45 AM +0100 11/8/04, Klaas-Jan Stol wrote:
Hello,
(* I'm trying a lot of things out, to figure out each part of the 
Lua language. This is Yet Another Question , this time concerning 
"missing" arguments *)
Argument counts are there for this purpose.
Named arguments are a separate issue, which needs addressing at some 
point, along with proper MMD for subs and methods. Perl 6, 
unfortunately, makes this reasonably annoying at the lower levels (it 
kills any scheme that assumes named parameters can be identified at 
compile time), so I've been dodging it for now.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: The Saga of Building Parrot : ICU

[Dan Sugalski]

At 10:29 PM -0700 11/7/04, Jack J. Woehr wrote:
Nicholas Clark wrote:
 So I think that deleting the empty directory /usr/local/uplevel for the
 duration of the build should solve your problem.
Removed the dir, finished the build, recreated the dir, and make 
install worked.

Now on to actually *trying out* Parrot ... as a former ANSForth 
Technical Committee
member, think I'll try the Forth first :-)
Uh, oh, all my Forth implementation sins are going to get exposed. :)
I really should go finish it at some point, though I've been hoping 
that parakeet or Matt's reimplementation would get done before I 
rounded up the tuits for it.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Win XP problems

[Jonathan Worthington]

"Peter Sinnott" <[EMAIL PROTECTED]> wrote:
On Mon, Nov 08, 2004 at 12:56:50PM +0100, Leopold Toetsch wrote:
Christian Lott <[EMAIL PROTECTED]> wrote:
> I have Active State Perl. I have MSVC. I have the POW version of 
> Parrot.

What is POW? Parrot on Windows? Who does maintain it?
Possily he means http://www.jwcs.net/developers/perl/pow/
but that seems to have precompiled for windows parrot binaries
with no source.
The website mentions Jonathan Worthington as the maintainer.
'fraid that'd be me.  From the Parrot On Win32 documentation:-
"This distribution contains the Parrot executables that result from 
compiling the source under Windows, to save you having to compile it 
yourself. Documentation, examples, tests, compilers and interpreters for a 
number of languages at various stages of completion and a few other assorted 
odds and ends are also included."

Which (obviously not clearly enough ;-) implies that the source isn't 
included.  This is like getting ActiveState Perl; you're getting something 
ready to run, not something you have to compile.  To get something to 
compile, look to the Parrot site (http://www.parrotcode.org/).

Hope this helps,
Jonathan 

Re: calling conventions, tracebacks, and register allocator

[Dan Sugalski]

At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
I've already said no changes to the calling conventions, quite a 
while ago. I don't see inconvenience in the register allocation code 
as a reason to change it. Got a better reason?
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Win XP problems

[Christian Lott]

Ron Blaschke wrote:
No.  Look for a batch file called vcvars32.bat below the Microsoft Visual
C++ 2003 directory, and run it.  It'll setup your environment.
"dir /s vcvars32.bat"
 

OK. Path set.
Now what?

It just fires up a command prompt with the vcvars32.bat executed.
Ron
 

Re: The Saga of Building Parrot : ICU

[Matt Diephouse]

On Sun, 07 Nov 2004 22:29:46 -0700, Jack J. Woehr <[EMAIL PROTECTED]> wrote:
> Now on to actually *trying out* Parrot ... as a former ANSForth Technical 
> Committee
> member, think I'll try the Forth first :-)

Hurm. The Forth in CVS has been somewhat abandoned (though
functional). I've been working on a re-write if you want to check that
out:

  http://matt.diephouse.com/software/parrot-forth-0.1.tar.gz

It's not as functional as the Forth in CVS... yet.

You can also look at Parakeet, which is a Forth-like language. There
was a recent discussion about Forth and Parakeet too:

  http://xrl.us/du8w (Link to groups.google.com)

Enjoy (Parrot). :-)

-- 
matt

include perl 6 files in config

[Pokorra, Gerd]

 
 
Hello,
 
 in the parrot distribution I would like to have the first line from
 the file parrot-0.1.1/languages/perl6/perl6 from
 
#! perl
 
 changed to
 
#!/usr/bin/perl
use lib '/parrot_source_dir/parrot-0.1.1/languages/perl6';
 
 
 So that /usr/bin/perl reflect the perl 5 executable and
 /parrot_source_dir/parrot-0.1.1/languages/perl6 is the
 place of the perl6 directory. So that I can execute the perl6
 program from every place.
 
 There for I created the two files in the parrot distribution:
 
   config/gen/perl6.pl
#! perl -w
  
package Configure::Step;
  
use strict;
use vars qw($description @args);
use Cwd qw(cwd);
use Parrot::Configure::Step ':gen';
  
$description="Generating perl6 file...";
@args=qw();
  
sub runstep {
  Configure::Data->set(cwd => cwd());
  genfile('config/gen/perl6.in', 'languages/perl6/perl6');
  chmod 0755, 'languages/perl6/perl6';
}
  
1;
 
 
  and the file config/gen/perl6.pl
#!${perl}
use lib '${cwd}${slash}languages${slash}perl6';
#
# perl6 driver:  parse assemble compile and run .p6 files
#
...  the original contents follows
 
 
In the file lib/Parrot/Configure/RunSteps.pm I add after the line 63:
gen/perl6.pl
 
 
So that the generation will be executed.
 
Would you add this to the distribution.
 
 
  Best wishes,
 
Gerd Pokorra
 
 
  E-Mail: [EMAIL PROTECTED]
 
  

Re: Win XP problems

[Ron Blaschke]

On Mon, 08 Nov 2004 09:45:06 -0600, Christian Lott wrote:
> "Do you hvae msvc (cl.exe) in the path?"
> No. I thought I did but looks like I don't...
> It's at c:\Program Files\Microsoft Visual C++ 2003\bin\cl.exe
> How would I set the path without overwriting my previous settings?
> set PATH=%PATH%;c:\Program Files\Microsoft Visual C++ 2003\bin\

No.  Look for a batch file called vcvars32.bat below the Microsoft Visual
C++ 2003 directory, and run it.  It'll setup your environment.
"dir /s vcvars32.bat"

>>The most important thing you need to do is use the .NET command line, 
>>rather than the regular cmd.exe shell.  The .NET shell sets up all the
>>environment variables needed to do a compile of Parrot.
> What's that?

It just fires up a command prompt with the vcvars32.bat executed.

Ron

[perl #32365] [TODO] improve parrot-config.imc

[via RT]

# New Ticket Created by  Leopold Toetsch 
# Please include the string:  [perl #32365]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32365 >


parrot-config.imc is able to extract config options from Parrot's
config and print it to stdout. This is e.g. useful for building
Parrot-based programs:

$ cc -Iinclude -c -Wall parrot_mem.c
$ c++  -o parrot_mem -Wall parrot_mem.o -Lblib/lib \
-lparrot `parrot parrot-config.imc libs linkflags` \
-licuuc -licudata

$ ./parrot_mem
sizeof Interp252
...

But not all information is there or like the icu-libs a bit scattered.
So the goal is to either have the necessary items in config[1] or provide
some shortcuts in parrot-config.imc to combine all compile and link
settings so that we can e.g.

   `./parrot parrot-config.imc --compile_cmd` -c foo.c
   `./parrot parrot-config.imc --link_cmd`foo.o -o foo

or some such.

Thanks,
leo

[1] would also simplify Test.pm for source tests.

Re: Win XP problems

[Christian Lott]

"Do you hvae msvc (cl.exe) in the path?"
No. I thought I did but looks like I don't...
It's at c:\Program Files\Microsoft Visual C++ 2003\bin\cl.exe
How would I set the path without overwriting my previous settings?
set PATH=%PATH%;c:\Program Files\Microsoft Visual C++ 2003\bin\

"Possily he means http://www.jwcs.net/developers/perl/pow/ but that 
seems to have precompiled for windows parrot binaries with no source. 
The website mentions Jonathan Worthington as the maintainer. "

Yes. That's the one.

The most important thing you need to do is use the .NET command line, 
rather than the regular cmd.exe shell.  The .NET shell sets up all the
environment variables needed to do a compile of Parrot.

 

What's that?
You mean the MSVC prompt?

Steve Peters
[EMAIL PROTECTED]
 

Re: [perl #32363] problem with buffer flushing in MacOSX

[Leopold Toetsch]

Stephane Payrard <[EMAIL PROTECTED]> wrote:

> Chris wants to flush a string without a newline.
> It does not work of MacOSX. Example of program :

>   getstdout P1
>   pioctl I0, P1, 3, 0
>   print   "Give me an integer number : ¥n"
>   getstdinP0
>   readline S1,P0

I don't know how reasonable it is to turn off buffering first and then
call readline (which turns line buffering on).

>   print I0
>   print "\n"
>   # pioctl I0, P1, 3, 1   # => segmentation fault on my linux box btw

No problem here. Did he/you omit the C opcode?

BTW Patches welcome to get rid of these magic pioctl arguments.

Grep for:

/* &gen_from_enum(.*\.pasm)  */

(or gen_from_def if necessary) and config/gen/parrot_includes.pl

Thanks,
leo

[perl #32363] problem with buffer flushing in MacOSX

[via RT]

# New Ticket Created by  Stephane Payrard 
# Please include the string:  [perl #32363]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32363 >


Submitted on behalf of  Christian Aperghis-Tramoni
<[EMAIL PROTECTED]>

Chris wants to flush a string without a newline.
It does not work of MacOSX. Example of program :

  getstdout P1
  pioctl I0, P1, 3, 0
  print   "Give me an integer number : Ân"
  getstdinP0
  readline S1,P0
  print I0
  print "\n"
  # pioctl I0, P1, 3, 1   # => segmentation fault on my linux box btw


--
 stef

Re: Win XP problems

[steve]

On Mon, Nov 08, 2004 at 12:21:51AM -0600, Christian Lott wrote:
> I have Active State Perl. I have MSVC. I have the POW version of Parrot.
> 
> In the new POW version of Parrot there is no Configure.pl so I can't 
> compile. Since all I get are "Can't find MSVC" errors I can't follow 
> Leo's advice on CPAN.
> 
> Nmake has done nothing for me either on the CVS tar.zip I attempted to make.
> 
> As you can see, I'm not a Unix guy. I'd love to experiment with Parrot 
> though since I love assembly language.
> 
> I'm pretty competent reporting errors but I've never been able to get 
> this to work (about 4 months ago).
> 
> If someone could walk me through this it'd be great. I've searched for 
> quite some time and am very tired of trying a bunch of things that I 
> can't get to work.
> 
> Help,
> 
> Christian Lott
> 

The most important thing you need to do is use the .NET command line, 
rather than the regular cmd.exe shell.  The .NET shell sets up all the
environment variables needed to do a compile of Parrot.

Steve Peters
[EMAIL PROTECTED]

Q: eval

[Leopold Toetsch]

I'd like to cleanup eval.pmc and dynamic code compiling a bit. But 
before that I'd like to know:

Which granularity do we allow for eval()ed code?
Can that be an expression or statement too or is it always at least an 
(anonymous) subroutine?
Does the compiled code see Parrot registers of the caller or is it more 
like a function call?
What about register preserving?

And finally what shall we do with such branches:
# #! perl -w
# my $i= 5;
# LAB:
#$i++;
#eval("goto LAB if ($i==6)");
#print "$i\n";
#
# 7
#
.sub _test
I1 = 5
$S0 = ".sub _e\nif I1 == 6 goto LAB\nend\n.end\n"
compreg P2, "PIR"
compile P0, P2, $S0
LAB:
inc I1
invoke
print I1
print "\n"
end
.end
Force them to be continuations?
leo

Re: Win XP problems

[Peter Sinnott]

On Mon, Nov 08, 2004 at 12:56:50PM +0100, Leopold Toetsch wrote:
> Christian Lott <[EMAIL PROTECTED]> wrote:
> > I have Active State Perl. I have MSVC. I have the POW version of Parrot.
> 
> What is POW? Parrot on Windows? Who does maintain it?
>

Possily he means http://www.jwcs.net/developers/perl/pow/
but that seems to have precompiled for windows parrot binaries
with no source.

The website mentions Jonathan Worthington as the maintainer.

-- 
Our challenge is to competently leverage other's business meta-services 
such that we may continue to continually supply economically sound sources 
to exceed customer expectations

Re: Win XP problems

[Leopold Toetsch]

Christian Lott <[EMAIL PROTECTED]> wrote:
> I have Active State Perl. I have MSVC. I have the POW version of Parrot.

What is POW? Parrot on Windows? Who does maintain it?

> In the new POW version of Parrot there is no Configure.pl so I can't
> compile. Since all I get are "Can't find MSVC" errors I can't follow
> Leo's advice on CPAN.

Do you hvae msvc (cl.exe) in the path?

> Help,

> Christian Lott

leo

GC invocation

[Leopold Toetsch]

The current Mark&Sweep collector runs strictly on demand, as well as the 
copying collector for buffer memory. Both are triggered, when a lack of 
resources is detected and are run immediately, from a probably deeply 
nested C function.

This causes several problems:
1) we have to do stack walking
2) we have to scan CPU registers
3) it caues e.g. string memory to move under the code
1) is time consuming and can lead to false positives (conservative GC is 
the keyword here - not a problem except a PMC is concerned that needs 
timely destruction). Boehm has e.g. a "blacklist" of false positives.
2) is horribly machine dependent and not easy, look e.g. in Boehm's GC 
sources: mach_dep.c - and it can produce false positives too.
3) needs that the programmer takes care not to cache any pointer into 
string memory over code, that could cause GC (collect). It's a bit error 
prone and causes slower code.

To work around that, I'd like to discuss a new scheme of GC invocation.
* on a lack of resources the allocation code allocates more 
objects/memory and posts a GC_EVENT - or it posts the event before 
resources are consumed entirely.
* This GC_EVENT gets handled at the run-loop level (as all events) So 
there is no need to do stack walking or CPU register scanning.
* and as the run-loop is a safe point, where no code has pointers into 
e.g. buffer memory, 3) is also no problem

Ponie, which isn't running the Parrot runloop yet, would need some extra 
support, though.[1]

Comments welcome,
leo
[1] maybe instead of
  Perl_runops_standard()
we could have:
  Parrot_runcode(..)=> loop: enternative  # calls Perl_runops
 if I0 goto loop
and the perl run loop drops back to Parrot e.g. at block exits ...

Re: Register allocation/spilling and register volitility

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 8, 2004, at 1:34 AM, Leopold Toetsch wrote:

>> If frames aren't adjacent, normal argument copying can be done anyway.

> This would seem to require the same types of runtime checks that you
> are objecting to below,

Not runtime. The register allocator knows the amount of needed
non-volatiles and volatile registers. Depending on that a call can place
arguments directly into the incoming regs of the caller or not. Then if
at runtime copying is needed (because e.g. frames aren't adjacent), the
function arguments are copyied. This is fully transparent.

> I discussed that in item (1) under "Further notes".

Yep, saw that then ;)

>> It's not needed. I've a better scheme in mind, which addressess
>> efficieny as well as argument passing.

> And spilling?

Well, I'm proposing a variable-sized register frame. With very little
additions we could run with more then 32 registers per kind (there are a
few bitmasks currently that would need adaptions, but not much).

But basically, spilling should not be needed at all, if the register
allocator isn't as broken as it now is. Dan got some really evil
subroutines, so we have RL test cases. We'll see.

> JEff

leo

Re: Win XP problems

[Nicholas Clark]

On Mon, Nov 08, 2004 at 12:21:51AM -0600, Christian Lott wrote:
> I have Active State Perl. I have MSVC. I have the POW version of Parrot.

What's the POW version of Parrot? This some source for parrot which isn't
cvs.perl.org, or a release on CPAN?

Nicholas Clark

Re: Basic compilation example (a + b)?

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:
> What pasm is supposed to correspond to this snippet of Python code
> (assume this is inside a function, so these can be considered to be
> local variables):

>   a = 7
>   b = 12
>   c = a + b

Run it through pie-thon. It should produce some reasonable code. For
leaf-functions (w/o introspection i.e. calls to locals()), the lexical
handling would get dropped. And a better translator would use lexical
opcodes by index and not by name.

> JEff

leo

Re: No C op with PMC arguments?

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:
>>
>> No. The binary operations in Python are opcodes, as well as in Parrot.
>> And both provide the snytax to override the opcode doing a method call,
>> that's it.

> I guess we'll just have to disagree here. I don't see any evidence of
> this

UTSL please. The code is even inlined:

,--[ Python/ceval.c ]
|   case BINARY_ADD:
|   w = POP();
|   v = TOP();
|   if (PyInt_CheckExact(v) && PyInt_CheckExact(w)) {
|   /* INLINE: int + int */
|   register long a, b, i;
|   a = PyInt_AS_LONG(v);
|   b = PyInt_AS_LONG(w);
|   i = a + b;
|   if ((i^a) < 0 && (i^b) < 0)
|   goto slow_add;
|   x = PyInt_FromLong(i);
`

> Not actually MMD in Python--behavior only depends on the left operand,
> it seems.

It's hard to say what Python actually does. It's a mess of nested if's.

>>null dest
>>dest = l + r
>>
>> should produce a *new* dest PMC.

> Yes, it's a separate issue, but it's pointing out a general design
> problem with these ops--their baseline behavior isn't useful.

It *is* useful. If the destination exists, you can use it. The
destination PMC acts as a reference then, changing the value in place.
But in case of Python it's not of much use, except for the inplace
(augmented) operations.

> ..., but for
> PMCs this could compile like "a = b.plus(c)".

> but you don't need add_p_p_p, just method invocation.

Why should we do method invocation with all it's overhead, if for the
normal case a plain function call we'll do it?

> For complex numbers and such, I'd want to be able to define classes for
> them in bytecode. For that to work, ops would eventually have to
> resolve to method calls anyway.

This is all working now already. You can do that. Again: if a method is
there it's used (or almost MMD not yet, vtables are fine):

.sub main @MAIN
.local pmc MyInt
getclass $P0, "Integer"
subclass MyInt, $P0, "MyInt"
.local pmc i, j, k
$I0 = find_type "MyInt"
# current hack - MMD overriding still missing
$P0 = find_global "MyInt", "__add"
.include "mmd.pasm"
mmdvtregister .MMD_ADD, $I0, $I0, $P0
# end hack
i = new $I0
j = new $I0
k = new $I0
j = 2
k = 3
i = j + k
print i
print "\n"
.end
.namespace [ "MyInt" ]
.sub __add
.param pmc l
.param pmc r
.param pmc d
$I0 = l
$I1 = r
$I2 = $I0 + $I1
$I2 = 42   # test
d = $I2
.end

> JEff

leo

Win XP problems

[Christian Lott]

I have Active State Perl. I have MSVC. I have the POW version of Parrot.
In the new POW version of Parrot there is no Configure.pl so I can't 
compile. Since all I get are "Can't find MSVC" errors I can't follow 
Leo's advice on CPAN.

Nmake has done nothing for me either on the CVS tar.zip I attempted to make.
As you can see, I'm not a Unix guy. I'd love to experiment with Parrot 
though since I love assembly language.

I'm pretty competent reporting errors but I've never been able to get 
this to work (about 4 months ago).

If someone could walk me through this it'd be great. I've searched for 
quite some time and am very tired of trying a bunch of things that I 
can't get to work.

Help,
Christian Lott

Re: AIX PPC JIT warning

[Leopold Toetsch]

Adam Thomason <[EMAIL PROTECTED]> wrote:

> It appears that (3) may work after all.  ICU 3.0 will build static
> 32-bit libraries which seem to work with parrot.  As Jeff suspected,
> the missing Parrot_ppc_jit_restore_nonvolatile_registers caused
> trouble, but adding it to aix/asm.s was simple.  Patch below fixes
> that and another pedantic build issue with xlc.

> Now to figure out why the JIT code segfaults...

Broken ABI WRT r2 (whatever that does on AIX)?

Thanks, applied:

> Index: config/gen/platform/aix/asm.s

That part is already changed:

> Index: src/sub.c

leo

Re: PIR: Arguments are passed without passing them

[Leopold Toetsch]

Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
> Hello,

> I'm currently figuring out how "missing arguments" should be handled.

[ ... ]

> # check on arguments being NULL
> isnull a, L1

Don't assume you get NULL or anything for missing arguments. Use the
argument counts:

  argcP ... number of P args passed in (I3)
  argcI ... number of I args passed in (I1)
  ...

leo

Re: Register allocation/spilling and register volitility

[Jeff Clites]

On Nov 8, 2004, at 1:34 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
OTOH it doesn't really matter, if the context structure is in the
frame too. We'd just need to skip that gap. REG_INT(64) or I64 is as
valid as I0 or I4, as long as it's assured, that it's exactly
addressing the incoming argument area of the called function.

A problem with this is that you can't be sure that you can actually
have the "next" frame of registers adjacent to the current frame--they
might already be taken. Imagine A calls B, then B creates a
continuation and stores it in a global, then returns.
Please read the proposal summary by Miroslav Silovic, keyword 
"watermark".
If frames aren't adjacent, normal argument copying can be done anyway.
This would seem to require the same types of runtime checks that you 
are objecting to below, unless user code is expected to explicitly 
check whether it's supposed to be assigning to I3 v I(3 + 32x?). And 
that still seems to require copying, in my case of a function a() which 
calls a function b() with the exact same arguments.

Keep the old-scheme registers inside the interpreter structure, *as
well as* the new indirect registers. Call the registers in the
interpreter I0 to I31, and the indirect registers I32 to whatever.
That would need two different addressing modes depending on the 
register
number. That'll lead to considerable code bloat: we'd have all possible
permutations for direct/indirect registers. Doing it at runtime only
would be a serious slowdown.
I discussed that in item (1) under "Further notes".
It's not needed. I've a better scheme in mind, which addressess
efficieny as well as argument passing.
And spilling?
JEff

Re: [perl #32356] AutoReply: [PATCH] update to embed.pod

[Leopold Toetsch]

Stéphane Payrard <[EMAIL PROTECTED]> wrote:
>>
>> There is now a call to set the core and another to set the other
>> flags. I updated the code and the doc to reflect that.

Thanks, applied.
leo

Re: No C op with PMC arguments?

[Jeff Clites]

On Nov 8, 2004, at 12:50 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:

In Python, semantically you know that you'll end up doing a method 
call
(or, behaving as though you had), so it's very roundabout to do a
method call by using an op which you know will fall back to doing a
method call. Clearer just to do the method call.
No. The binary operations in Python are opcodes, as well as in Parrot.
And both provide the snytax to override the opcode doing a method call,
that's it.
I guess we'll just have to disagree here. I don't see any evidence of 
this from an API/behavior perspective in Python. I think the existence 
of a separate Python opcode is just a holdover from a time when these 
infix operators only existed for built-in types (just inferring this). 
I can't find any case where Python would act differently, if these were 
compiled directly to method calls. And for Ruby, it's *explicit* that 
these "operators" are just method calls. And languages like Java don't 
have these operators at all, for objects.

The only thing that's special is that there are certain built-in
classes, and some of them implement __pow__, but that's not really
anything special about __pow__.
Yes. And these certain *builtin* classes have MMD functions for binary
opcodes.
Not actually MMD in Python--behavior only depends on the left operand, 
it seems.

And even the ops we currently have are broken semantically. Consider 
"a
= b + c" in Python. This can't compile to add_p_p_p, because for that
op to work, you have to already have an existing object in the first P
register specified. But in Python, "a" is going to hold the result of
"b + c", which in general will be a new object and could be of any
type, and has nothing to do with what's already in "a".
That's a totally different thing and we have to address that. I have
already proposed that the sequence:
   null dest
   dest = l + r
should produce a *new* dest PMC. That's quite simple. We just have to
pass the address of the dest PMC pointer instead of the PMC to all such
operations. Warnocked.
Yes, it's a separate issue, but it's pointing out a general design 
problem with these ops--their baseline behavior isn't useful. The 
result of "l + r" will not depend on what's to the left of the "=" by 
HLL semantics, for any case I can think of. (Perl cares about context, 
but that's not really the same thing.)

... I think
we should create PMC-based ops only if one of the following criteria
are met: (a) there's no other reasonable way to provide some needed
functionality,
So, this is already a perfect reason to have these opcodes with PMCs.
  a = b + c
behaves differently, if b and c are plain (small) integers or
overflowing integers or complex numbers and so on. You can't provide
this functionality w/o PMCs.
I don't understand this example. Certainly you need PMCs, but if b and 
c are I or N types, of course you'd use add_i_i_i or add_n_n_n, but for 
PMCs this could compile like "a = b.plus(c)". Of course you have to 
know I v. N v. P at compile-time, and there's no reason that I/N v. P 
pasm must look identical, for similar-looking HLL code. You need PMCs, 
but you don't need add_p_p_p, just method invocation.

For complex numbers and such, I'd want to be able to define classes for 
them in bytecode. For that to work, ops would eventually have to 
resolve to method calls anyway. (You can't create a new PMC and 
vtable/MMDs in bytecode.) Why not skip the middle-man?

JEff

Re: Register allocation/spilling and register volitility

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:

>> OTOH it doesn't really matter, if the context structure is in the
>> frame too. We'd just need to skip that gap. REG_INT(64) or I64 is as
>> valid as I0 or I4, as long as it's assured, that it's exactly
>> addressing the incoming argument area of the called function.

> A problem with this is that you can't be sure that you can actually
> have the "next" frame of registers adjacent to the current frame--they
> might already be taken. Imagine A calls B, then B creates a
> continuation and stores it in a global, then returns.

Please read the proposal summary by Miroslav Silovic, keyword "watermark".
If frames aren't adjacent, normal argument copying can be done anyway.

> Keep the old-scheme registers inside the interpreter structure, *as
> well as* the new indirect registers. Call the registers in the
> interpreter I0 to I31, and the indirect registers I32 to whatever.

That would need two different addressing modes depending on the register
number. That'll lead to considerable code bloat: we'd have all possible
permutations for direct/indirect registers. Doing it at runtime only
would be a serious slowdown.

It's not needed. I've a better scheme in mind, which addressess
efficieny as well as argument passing.

leo

PIR: Arguments are passed without passing them

[Klaas-Jan Stol]

Hello,
(* I'm trying a lot of things out, to figure out each part of the Lua 
language. This is Yet Another Question , this time concerning "missing" 
arguments *)

I'm currently figuring out how "missing arguments" should be handled. 
Suppose there is a function foo, that takes 4 parameters. In Lua it is 
allowed not to pass all arguments (or even none), but then the argument 
is just /null/ or in Lua terms /nil/. However, it should not be a NULL 
PMC, but it should be something like PerlUndef (but later on it should 
be replaced by LuaNil PMC). For that to work, there must be some extra 
code that checks on NULL PMCs. I figured out how it could be done. It 
can be seen in the following code snippet.

.sub _main
   .local pmc p
   .local pmc q
   .local pmc r
   .local pmc s
   p = new .PerlInt
   q = new .PerlInt
   r = new .PerlInt
   s = new .PerlInt
   p = 1
   q = 2
   r = 3
   s = 4

   _f()
   _f(p)
   _f(p, q)
   _f(p, q, r)
   _f(p, q, r, s)
   _f(p, q, r)
   _f(p, q)
   _f(p)
   _f()

   end
.end
.sub _f non_prototyped
   # fixed parameters
   .param pmc a
   .param pmc b
   .param pmc c
   .param pmc d
  
   # check on arguments being NULL
   isnull a, L1
   isnull b, L2
   isnull c, L3
   isnull d, L4
   branch L5
L1:
   a = new .PerlInt # later on this should be LuaNil, but this is for 
testing
   a = 0
L2:
   b = new .PerlInt
   b = 0
L3:
   c = new .PerlInt
   c = 0
L4:
   d = new .PerlInt
   d = 0
L5:
   # body
   print "a = "
   print a
   print "; b = "
   print b
   print "; c = "
   print c
   print "; d = "
   print d
   print "\n"
.end

When I run this program, I get the following output:
a = 0; b = 0; c = 0; d = 0   <= ok!
a = 1; b = 0; c = 0; d = 0   <= ok!
a = 1; b = 2; c = 0; d = 0   <= ok!
a = 1; b = 2; c = 3; d = 0   <= ok!
a = 1; b = 2; c = 3; d = 4   <= ok!
a = 1; b = 2; c = 3; d = 4   <= huh?
a = 1; b = 2; c = 3; d = 4   <= huh?
a = 1; b = 2; c = 3; d = 4   <= huh?
a = 1; b = 2; c = 3; d = 4   <= huh?
The first 5 lines are ok, I expected those. I'm wondered by the last 4 
lines.
The arguments are still being passed to the function, while it is clear 
I didn't call the function
with those arguments (see above: _f(), _f(p), etc.)

I translated the thing to PASM, and that explained a lot: the arguments 
from previous calls are
still in P5, P6 etc.

This can easily be solved by nulling these registers, but that seems a 
bit strange to me.
But on the other hand, it may be that if I want this functionality (as 
described) I should take care of it myself (thus nulling the PMC 
argument register before making a new call).

Anyway, my question is: is this normal behaviour of PIR/IMCC? Should I 
be aware of this fact and
generating extra code to null out argument registers before making a 
call to a function?

Regards
Klaas-Jan

Re: AIX PPC JIT warning

[Adam Thomason]

On Fri, 29 Oct 2004 15:03:40 -0700, Adam Thomason <[EMAIL PROTECTED]> wrote:
> 
> Worry not, it's already broken.  I've been unable to test the AIX/PPC
> JIT since ICU went in.  The configuration for ICU (at least as of 2.6)
> supports only a 64-bit build, while aix/asm.s is 32-bit only (the
> linker claims the .o is corrupt if assembled with OBJECT_MODE=64).
> 
> To get it working again, one of three things needs to happen:
> 
> 1. ICU becomes optional again (please!).
> 2. PPC64 JIT code is written which can be morphed into POWER code.
> Transforming PPC32->POWER was mostly straightforward, so hopefully
> 64-bit will be as well.
> 3. ICU's configure starts to support 32-bit compiles.  This might
> happen with 3.0/CVS already, but I haven't checked.
> 
> 1 is necessary anyway, but it doesn't seem like a high priority.  2 is
> best in the long run, but requires somebody who knows more about PPC64
> ASM than I do to get started.  I don't know if 3 has any chance of
> happening upstream, but I doubt there's anybody working on Parrot who
> wants to deal with it.
> 
> If somebody can help with one or more of these, I can try to get it
> going on AIX 4.3.3 once again.
> 
> Adam
> 

It appears that (3) may work after all.  ICU 3.0 will build static
32-bit libraries which seem to work with parrot.  As Jeff suspected,
the missing Parrot_ppc_jit_restore_nonvolatile_registers caused
trouble, but adding it to aix/asm.s was simple.  Patch below fixes
that and another pedantic build issue with xlc.

Now to figure out why the JIT code segfaults...

Index: config/gen/platform/aix/asm.s
===
RCS file: /cvs/public/parrot/config/gen/platform/aix/asm.s,v
retrieving revision 1.2
diff -u -r1.2 asm.s
--- config/gen/platform/aix/asm.s   21 Feb 2004 10:58:53 -  1.2
+++ config/gen/platform/aix/asm.s   3 Nov 2004 23:57:33 -
@@ -10,6 +10,7 @@
 .globl .aix_get_toc
 .globl .ppc_sync
 .globl .ppc_flush_line
+.globl .Parrot_ppc_jit_restore_nonvolatile_registers

 # Flushes the cache line whose address is passed in
 .ppc_flush_line:
@@ -38,3 +39,25 @@
 st 3,68(SP)
 cal SP,80(SP)
 bcr BO_ALWAYS,CR0_LT
+
+.Parrot_ppc_jit_restore_nonvolatile_registers:
+.function 
.Parrot_ppc_jit_restore_nonvolatile_registers,.Parrot_ppc_jit_restore_nonvolatile_registers,2,0
+lfd 14,-84(SP)
+lfd 15,-92(SP)
+lfd 16,-100(SP)
+lfd 17,-108(SP)
+lfd 18,-116(SP)
+lfd 19,-124(SP)
+lfd 20,-132(SP)
+lfd 21,-140(SP)
+lfd 22,-148(SP)
+lfd 23,-156(SP)
+lfd 24,-164(SP)
+lfd 25,-172(SP)
+lfd 26,-180(SP)
+lfd 27,-188(SP)
+lfd 28,-196(SP)
+lfd 29,-204(SP)
+lfd 30,-212(SP)
+lfd 31,-220(SP)
+bcr BO_ALWAYS,CR0_LT
Index: src/sub.c
===
RCS file: /cvs/public/parrot/src/sub.c,v
retrieving revision 1.76
diff -u -r1.76 sub.c
--- src/sub.c   3 Nov 2004 14:29:58 -   1.76
+++ src/sub.c   3 Nov 2004 23:57:33 -
@@ -338,8 +338,10 @@
  */
 #if PMC_DATA_IN_EXT
 #  define PREV_RETC(p) (PMC*)((p)->pmc_ext)
+#  define PREV_RETC_LVALUE(p) ((p)->pmc_ext)
 #else
 #  define PREV_RETC(p) PMC_data(p)
+#  define PREV_RETC_LVALUE(p) PMC_data(p)
 #endif

 /*
@@ -374,7 +376,7 @@
 Caches *mc = interpreter->caches;

 if (mc->retc_cache)
-PREV_RETC(mc->retc_cache) = mc->retc_cache;
+PREV_RETC_LVALUE(mc->retc_cache) = (PMC_EXT*) mc->retc_cache;
 mc->retc_cache = pmc;
 /* XXX expensive w. ARENA_DOD_FLAGS */
 PObj_custom_mark_CLEAR(pmc);

Re: No C op with PMC arguments?

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:

> In Python, semantically you know that you'll end up doing a method call
> (or, behaving as though you had), so it's very roundabout to do a
> method call by using an op which you know will fall back to doing a
> method call. Clearer just to do the method call.

No. The binary operations in Python are opcodes, as well as in Parrot.
And both provide the snytax to override the opcode doing a method call,
that's it.

> The only thing that's special is that there are certain built-in
> classes, and some of them implement __pow__, but that's not really
> anything special about __pow__.

Yes. And these certain *builtin* classes have MMD functions for binary
opcodes.

> And even the ops we currently have are broken semantically. Consider "a
> = b + c" in Python. This can't compile to add_p_p_p, because for that
> op to work, you have to already have an existing object in the first P
> register specified. But in Python, "a" is going to hold the result of
> "b + c", which in general will be a new object and could be of any
> type, and has nothing to do with what's already in "a".

That's a totally different thing and we have to address that. I have
already proposed that the sequence:

   null dest
   dest = l + r

should produce a *new* dest PMC. That's quite simple. We just have to
pass the address of the dest PMC pointer instead of the PMC to all such
operations. Warnocked.

> ... I think
> we should create PMC-based ops only if one of the following criteria
> are met: (a) there's no other reasonable way to provide some needed
> functionality,

So, this is already a perfect reason to have these opcodes with PMCs.

  a = b + c

behaves differently, if b and c are plain (small) integers or
overflowing integers or complex numbers and so on. You can't provide
this functionality w/o PMCs.

> JEff

leo

Register allocation/spilling and register volitility

[Jeff Clites]

From other threads:
Now we are placing arguments or return values in registers according 
to PDD03 and the other end has immediately access to the placed 
values, because the register file is in the interpreter.

With the indirect addressing of the register frame, this argument 
passing is probably the most costly part of function calls and 
returns, because we have to copy the values.
and
Anyway, if you can pop both register frames -and- context structures, 
you won't run GC too often, and everything will nicely fit into the 
cache.
I thought about that too, but I'd rather have registers adjacent, so 
that the caller can place function arguments directly into the callers 
in arguments.

OTOH it doesn't really matter, if the context structure is in the 
frame too. We'd just need to skip that gap. REG_INT(64) or I64 is as 
valid as I0 or I4, as long as it's assured, that it's exactly 
addressing the incoming argument area of the called function.
A problem with this is that you can't be sure that you can actually 
have the "next" frame of registers adjacent to the current frame--they 
might already be taken. Imagine A calls B, then B creates a 
continuation and stores it in a global, then returns. If A makes 
another function call, it can't just use the adjacent register 
frame--it's still "taken". (I'm referring here to the "sliding register 
window" idea of course.) But this is reminding me of another idea I've 
had.

I've been thinking for a while about another idea to decrease some of 
the copying which we are now doing for function calls, as well as the 
allocation of register sets during subroutine calls, and which would as 
a side-effect allow us to reduce the need for register spilling.

First, a code snippet. Consider the following C code:
int a(int x) { return b(x); }
int b(int x) { return c(x + 1); }
int c(int x) { return x + 7; }
As compiled on the PPC, this code is very compact--each function is 
implemented by just one or two instructions, and only one register is 
used. There are two key factors here: (1) no register preservation is 
needed, and (2) the call from a() to b() is just a branch, since the 
call to a() has already loaded the registers with the correct values 
for the call to b().

By my thinking, register usage falls into three basic categories:
1) Registers used for parameter passing and returns values for function 
calls.

2) Registers used to hold values which need to be preserved across 
function calls.

3) Registers used to hold values which do not need to be preserved 
across function calls.

Really, (1) and (3) are similar--in either case, you have registers 
whose values are allowed to change across function calls. (For register 
which hold return values that's obvious, and for those used to pass 
parameters, it seems fair that these be expected to change across a 
function call.) So we really have two cases--volatile and non-volatile 
register usage.

In the PPC ABI, half the registers are treated as volatile, and the 
other half as non-volatile. For the PPC, this corresponds to 
caller-preserved v. callee-preserved. Because of continuations[1], 
parrot can't have callee-preserved registers, but it could still have 
volatile v. non-volatile registers. Here's what I'm thinking:

Keep the old-scheme registers inside the interpreter structure, *as 
well as* the new indirect registers. Call the registers in the 
interpreter I0 to I31, and the indirect registers I32 to whatever.[2] 
I'll call these the "direct" and "indirect" registers. By their very 
nature, the direct registers are volatile, and the indirect registers 
are non-volatile. What does this buy us? The following:

1) Parameter passing and return occur via the established calling 
conventions, in the volatile registers. No extra copying is needed upon 
function call or return--the volatile registers are physically the same 
for the caller and the callee.

2) "Temporary" calculations can use the volatile registers. Values 
which need preserving can use the non-volatile registers directly.

3) In functions which need no non-volatile registers, there's no need 
to allocate the indirect registers at all.

4) Cases like my example code above can compile just as compactly as 
the PPC case. With the volatile Parrot registers mapped to volatile CPU 
registers (in the PPC case at least), this would be highly efficient: 
you'd end up with asm similar to what you have in the C case above, and 
you'd not have a need to save the CPU registers back to Parrot 
registers (other than those used in the calling conventions) for Parrot 
function calls out of JIT code.

5) Because this opens things up to more than 32 registers, code could 
use as many registers as needed. You'd never have register spilling 
per-se in order to accommodate local variables, though you'd still want 
a smart register allocator which minimized the number of registers 
needed (for memory locality as well as minimizing allocation). But a 
very simple one-non-vo

Re: Streams and Filters (Ticket #31921)

[Ron Blaschke]

Sunday, November 7, 2004, 11:25:52 AM, Jens Rieks wrote:
> On Sunday 07 November 2004 09:48, Leopold Toetsch wrote:
>> * where exactly is the mismatch coming from?
> Unix uses "\n" to indicate end-of-line, windows uses "\r\n". The problem is,
> that the "perlhist.txt" file is checked in as a text file. I'll recommit it
> as a binary file in the hope that it fixes the problem.

> The root of the problem is the different line ending, I have no idea how
> parrot can deal with it, or if it should deal with it at all.

Here are my thoughts on that topic:  In my mind, "plain old text
files" are a model for text, just as PNG or JPEG are for images.

The model for the text file is a list of lines (strings).  The list is
created by a delimiter (though some programs treat it more like a
terminator).  Thus, for a correct parse one needs to know
  - the encoding
  - the character set
  - the delimiter string
all of which usually default to the current platform, but may be
different.

For example, there are Windows programs that write UTF16 Unicode (see
C:\WINDOWS\wusetup.log on WinXP).  In Europe usually 8bit encoding
with Codepage 1250 is used, except for the "Command Prompt" which uses
Codepage 850 (which leads to fun for example with german umlauts).

For me it boils down to the question whether parrot should support
plain old text files.

Ron