Re: Continuations, basic blocks, loops and register allocation

[Leopold Toetsch]

Matt Fowles <[EMAIL PROTECTED]> wrote:

[ continuations should restore registers ]

> I am sorry, but I don't understand what you are trying to say here.
> Would you mind rewording it for me?

Imagine a simple loop:

i = 0
  lp:
foo()
inc i
if i < 10 goto lp

Looking at the loop counter a programmer or optimizer could easily
decide that using an I-Reg for it instead of a P-Reg is fine. Now comes
your proposed implementation for continuations: they copy the register
frame on creation and restore it on invocation. Besides of the big cost
of the memcpy's this simple loop above suddenly stops working, depending
on the implementation of foo() - which might be outside your control.

BTW in an early stage we had exactly this behavior of continuations.
This was abandoned. The subject was IIRC something like "Should
continuations close over registers". The answer was clearly "no".

leo

Re: IEEE 754 double floats

[Adam Warner]

Hi Brent 'Dax' Royal-Gordon,

>> option. Yet the Leibniz summation for PI 
>> 
>> still appears to be performing its calculations using single floats and
>> continues to print 3.141591.
> 
> Parrot usually uses double as its floating-point type.  The problem is
> probably with the precision of 'print N0'; try using the 'sprintf'
> opcode and printing the resulting string instead.

Many thanks for the tip!

.sub _main
set N1, 1
set N2, 100
set N3, 0
set N4, 0
set I1, 0
REDO:   div N4, 1.0, N1
if  I1, SUB
add N3, N4, N3
set I1, 1
branch  END
SUB:sub N3, N3, N4
set I1, 0
END:add N1, 2
le  N1, N2, REDO
DONE:   mul N3, N3, 4.0

new P0, .PerlArray
set P0, 1
set P0[0], N3
sprintf S0, "PI is (very) approximately: %.20f\n", P0
print   S0
end
.end

On a windows binary I downloaded the precision is indeed double (~16
decimal places). With my current Linux binary it's extreme (here's 60
decimal places):

PI is (very) approximately: 
3.1415906535896946927266526472521945834159851074218750

This may be the long double version that I compiled :-)

Thanks again,
Adam

Re: Perl 6 Summary for 2004-11-08 through 2004-11-15

[Bernhard Schmalhofer]

Matt Fowles wrote:
   string pinning
Bernhard Schmalhofer wanted to pass the same C-string into to different
external functions so that the first could do things to it that the
second required. However, the solution that he found kept eating his
string after the first invocation. Dan and Leo came to the conclusion
that the 'd' parameter for NCI was the correct thing to use in this
situation.
Actually it is the 'b' signature specifier, for a raw buffer.
   eval changes
Leo updated the implementation of eval to make it even cooler or
possibly just clean it up and fix some bugs I forget.

Thanks for putting that into the summary, because I missed it on the 
list. Now I know why the 'eval' macro in Parrot m4 is failing.

CU, Bernhard
--
**
Dipl.-Physiker Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: [EMAIL PROTECTED]
Website: www.biomax.com
**

Re: [perl #32434] [PATCH] Data/Dumper tidbits

[Leopold Toetsch]

Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:

> this patch adds support for the String PMC to Data/Dumper/Default.imc. It is
> treated just like the PerlString PMC.

Thanks, applied.
leo

Re: [perl #32421] Bug: segfault in imcc parsing bad if statement

[Leopold Toetsch]

Gopal V <[EMAIL PROTECTED]> wrote:

>> Segfault in the lexer. Bad.
>>
>> 349 sprintf(label, "%s%d", yytext,
>> frames->label);
>> (gdb) p frames
>> $1 = (struct macro_frame_t *) 0x0

> I didn't know how or why or what a frame is in this
> context which is why this isn't a patch :)

No problem. The syntax {ID}$ is used internally during the expansion of
local labels inside macros, which happen to be accumulated in frame
structures.

Fixed.

Thanks for reporting,
leo

Re: [perl #32450] [PATCH] core dump of japh16

[Leopold Toetsch]

Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:

> since a couple of days the example japh16 is dumping core on my Linux
> machine.
> It looks like there was a free on a NULL, when cleaning up packfile
> segments. The attached patch checks wether there is a fixup table in the
> seqment.

> I'm not sure about the validity of this patch. Perhaps there has to be a
> fixup table.

It's fine.

> Unfortunately I have no idea what a fixup table does.

The fixup table is a list of global Sub PMCs. These are coming from he
packfile with relative start offsets to the beginning of their packfile.
During fixup, these offsets are converted to absolute bytecode
addresses.

> CU, Bernhard

Thanks, applied.
leo

Re: Threads, events, Win32, etc.

[Gabe Schaffer]

On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> > * COND_WAIT takes a mutex because that's how pthreads works, but Win32
> > condition variables (called "events") are kernel objects that do not
> > require any other object to be associated with them. I think this
> > could be cleaned up with further abstraction.
> 
> Not quite. COND_WAIT takes an opaque type defined by the platform, that
> happens to be a mutex for the pthreads based implementation.

It should, but it doesn't. Here's the definition:
#  define COND_WAIT(c,m) pthread_cond_wait(&c, &m)
It explicitly takes a condition and a mutex, while it should just be
passed a Parrot_cond (or something like that):

typedef struct {
#ifdef pthreads
pthread_mutex_t m;
pthread_cond_t c;
#elseif Win32
HANDLE h;
#endif
} Parrot_cond;

> > The big issue, though, is with the IO thread. On NT the IO is already
> > async and there are no signals (Ctrl+C is handled with a callback), so
> > each interpreter thread should just be able to handle all of this in
> > the check_events functions.
> 
> Not all. We need to do check_events() for e.g. message passing too.


> >  Win9x doesn't have async IO on files, so it still might
> > require separate threads to do IOs.
> 
> I'm not sure, if we even should support Win9{8,5}.

I'd be happy with simply implementing Win9x as a non-threaded
platform. Of course, hopefully nobody will even ask...

> > Anyway, it seems to me that all this event/IO stuff needs
> > significantly more abstraction in order to prevent it from becoming a
> > hacked-up mess of #ifdefs.
> 
> Yep. The system-specific stuff should be split into platform files. A
> common Parrot API then talks to platform code.
> 
> > ...However, I couldn't find any docs on this,
> > so I just guessed how it all works based on the source.
> 
> The current state of the implemented pthread model is summarized in
> docs/dev/events.pod.

Thanks, I didn't see that. My problem isn't with what the
implementation does, though -- it's that I don't understand the
rationale. I can understand why there would need to be a global event
thread (timers, GC, DoD), but why would passing a message from one
thread to another need to be serialized through a global event queue?

And as for IO, I see the obvious advantages of performing synchronous
IO functions in a separate thread to make them asynchronous, but that
sounds like the job of a worker thread pool. There are many ways to
implement this, but serializing them all through one queue sounds like
a bottleneck to me.

> Au contraire. Your analysis is precise. Do you like to take a shot at a
> Win32 threads/event model? So we could figure out the necessary
> splitting of API/implementation.

OK. I think I need to have a better understanding on what events
actually are, though. Who sends them? What do they mean? Which signals
do we actually care about? What are notifications? How will AIO
actually be handled? You know, that sort of thing... Maybe there
should be a PDD for it?

GNS

RT Ticket Summary

[Will Coleda]

Robert has provided me access to the RT command line tool, which I scripted
around to generate this small report. I'd appreciate feedback on whether
or not something like this would be useful (and suggestions for other things
to report on are welcome.)

If we can settle on a desired set of criteria to report on, Robert says he can
make a more efficient (and accurate) version of the report, as he has direct
access to the RT API. (I'm doing a lot of grepping through plain text
renderings of ticket summaries, which is, of course, evil.)

Parrot Ticket Summary
  There are currently 277 new/open tickets.
  The oldest ticket was created on: 12Dec2001 [#192]
  The average (mean) age of tickets is: 63 weeks

Platforms
  All:   1 cygwin:   3freebsd:   3
Linux:   3MacOS X:   2mswin32:   5
  os2:   1  other:   2Unspecified: 252
  vms:   1  Win32:   7

Languages
BASIC:   1tcl:   4Unspecified: 272

Re: IEEE 754 double floats

[Adam Warner]

> This may be the long double version that I compiled :-)

Note: I've rebuilt parrot-latest.tar.gz (I believe it was
2004-11-16_00) at default settings on Debian unstable 2.6.8.1 i686
GNU/Linux. I'm still printing floats that appear to be 128-bit precision!

Regards,
Adam

SDL: Locate shared libraries

[Adam Warner]

Hello again,

x86 Debian sid with the SDL libraries installed:

libsdl-image1.2  1.2.3-5 image loading library for Simple DirectMedia Layer 
1.2
libsdl-ttf2.0-0  2.0.6-5 ttf library for Simple DirectMedia Layer with 
FreeType
libsdl1.2debian 1.2.7-10 Simple DirectMedia Layer
libsdl1.2debian-all 1.2.7-10 Simple DirectMedia Layer (with all available 
options)

The libraries are located in /usr/lib/:

/usr/lib/libSDL-1.2.so.0.7.0
/usr/lib/libSDL-1.2.so.0
/usr/lib/libSDL_image-1.2.so.0.1.2
/usr/lib/libSDL_image-1.2.so.0
/usr/lib/libSDL_ttf-2.0.so.0
/usr/lib/libSDL_ttf-2.0.so.0.6.0

$ ./parrot examples/sdl/lcd/clock.imc
Couldn't load 'libSDL': libSDL: cannot open shared object file: No such file or 
directory
Couldn't load 'libSDL_image': libSDL_image: cannot open shared object file: No 
such file or directory
Couldn't load 'libSDL_ttf': libSDL_ttf: cannot open shared object file: No such 
file or directory
Couldn't load 'libSDL': libSDL: cannot open shared object file: No such file or 
directory
Segmentation fault

In runtime/parrot/library/SDL.imc I replaced the respective loadlibs with:

   loadlib libsdl, 'libSDL-1.2.so.0'
   loadlib image_lib, 'libSDL_image-1.2.so.0'
   loadlib ttf_lib, 'libSDL_ttf-2.0.so.0'

And it worked! (w/warning: SDL::fetch_layout warning: layout 'Pixels' not 
found!)

At this stage of development is parrot supposed to automatically locate
the shared libraries?

Thanks,
Adam

[PROPOSAL] for a new calling scheme

[Leopold Toetsch]

Below inline/attached is a proposal for new calling conventions - for 
the archive as Dan doesn't like changes now, but I haven't to backup it, 
when its out ;)
A proposal for new calling conventions - for the archive as Dan
doesn't like changes now, but I haven't to backup it, when its out ;)

Central keywords:

* ~64 KB sized register chunks
* variable sized frames carved out of chunks
* sliding register window
* distinct non-volatile and volatile register usage


Rational

The current calling scheme has to major drawbacks: too few allocatable
registers and suboptimal performance.

Register allocation issues

The current scheme has no notion of non-volatile and volatile
registers. Declaring just the upper half (or any other part) of
registers as non-volatile doesn't take any actual register usage of
functions into account. It's too unflexible to accomodate RL programs.

This caues either register spilling or wrong code, as the registers
R5-R15 may be used as return results. This can happen w/o the
knowledge of the caller. It makes a 16 (x4)-register machine out of
Parrot, which is inadequate for complex code.

Actually the current situation is worse. As the caller has to preserve
P0, P1, and P2 in the upper half of registers, there are in fact only
13 allocatable P registers around a method call.


Performance issues

I've already shown that Parrot's cache usage is subobtimal. The
fibonacchi benchmark (or other call-bound code) spends more then half
of equivalent CPU cycles in level 2 cache misses. This makes Parrot
incompetitively slow and thus unattractive for potential users.

Additionally the fib benchmark shows that almost 20% of cycles is
burned due to function argument and return value copying.

Having fixed sized register frames has additionally two major
drawbacks during DOD/GC. First: all P and S registers have to be
cleared prior to usage, so that no garbage can be marked live. Second
all 32 registers per kind have to be scanned during the mark phase of
DOD for all existing register frames for the whole call chain. This is
a big degradation during DOD and of course causing more cache
pollution.


The indirect register addressing has prooven to be a big improvement
with overall benchmark performance but it's not utilizing the
potential of that scheme because of the fixed sized register frame,
which causes unneeded cache pollution for small function and method
calls like attribute setter/getters or for the fib benchmark.

This proposed scheme addresses two major impacts on speed of the
existing scheme (cache pollution and argument copying) and the problem
of return values clobbering caller's register, if a function is called
in void context.

So here we go.


Prelims:

* the register allocator patch is done and it allocates registers from
  zero up
* the register allocator has counts of needed non- and volatiles per
  sub call and function
* non-volatile registers are assigned to register numbers 0..n-1.
  For optimal register utilization, the register allocator should
  renumber registers and we might insert register moves around
  function calls, so that non-volatiles are arranged first.
* the register structure is like in interpreter.h with the define
  of SLIDING_BP, that is an array of structs instead of a struct of
  arrays

Changes to calling conventions:

* only I0,I1 are used for denoting used registers. This reduces opcount
  count a bit and it's better for cache usage.
  (we are not suffering from too much cycles the code executes, the
   cache usage is the problem - these few additional shifts for
   extracting register usage aren't going to kill performance)
* outgoing registers are placed in the incoming area of the called
  sub, which overlaps the volatile register area of the caller
* return values are used/fetched from that area


Changes to opcodes:

* opcodes do reflect the actual register consumption
  (all the implicit register usage needs special treatment inside
  imcc, which complicates the code in an unneeded way and slows down
  compilation)

* call opcodes get an extra argument how far to bump the register
  frame pointer

  invokecc PSub, Ibp_incr
  callmethcc PObj, Smeth, Ibp_incr

* the return opcode is distinct now. This makes the code more readable
  and clearly denotes the difference to a call:

  returncc

* all old register stack opcode except saveall/restoreall are unneeded
  and tossed. (And even these 2 opcodes are just needed for stack
  calling conventions, which will be slower then this scheme. I don't
  see much reasons to support it.)


Register usage of current sub

(Rx is one of the four register kinds)

  n   ... non-volatile register count (max of any kind)
  I0  ... argcP
  I1  ... argcIS_N := argcI + argcS << 8 + argcN << 24
  R2-R10 . incoming args / return values
  P0  ... optional overflow array
  P1  ... optional keyword/named args hash?
  P2  ... object / 1st arg

(or maybe alternatively P2 object, R3..R10 args, I1 argcI, I2 argc_SN)

The cur

Re: IEEE 754 double floats

[Leopold Toetsch]

Adam Warner <[EMAIL PROTECTED]> wrote:

> On a windows binary I downloaded the precision is indeed double (~16
> decimal places). With my current Linux binary it's extreme (here's 60
> decimal places):

> PI is (very) approximately:
  3.1415906535896946927266526472521945834159851074218750
 ^
  3.141592653589793238462643383279502884197169399375105820974944

You might probably want to run more iterations ;) And you'll never get
60 digits out of long doubles.

> Thanks again,
> Adam

leo

Re: Threads, events, Win32, etc.

[Leopold Toetsch]

Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
>> > * COND_WAIT takes a mutex because that's how pthreads works, but Win32
>> > condition variables (called "events") are kernel objects that do not
>> > require any other object to be associated with them. I think this
>> > could be cleaned up with further abstraction.
>>
>> Not quite. COND_WAIT takes an opaque type defined by the platform, that
>> happens to be a mutex for the pthreads based implementation.

> It should, but it doesn't. Here's the definition:
> #  define COND_WAIT(c,m) pthread_cond_wait(&c, &m)

You are already in the POSIX specific part.

1) During configure parrot includes platform code from files located in
  config/gen/platform/*/

2) if a platform doesn't have an implementation the ../generic/
directory is used.

3) $ find config -name threads.h
config/gen/platform/generic/threads.h

So there is no win32/threads.h (yet ;)

If the implementation needs some additional libraries, the hints/* are
consulted e.g.

config/init/hints/linux.pl:$libs .= ' -lpthread';

>> I'm not sure, if we even should support Win9{8,5}.

> I'd be happy with simply implementing Win9x as a non-threaded
> platform. Of course, hopefully nobody will even ask...

We'll see. But as Parrot's IO system is gonna be asynchronous in core, I
doubt that we'll support it.

>> The current state of the implemented pthread model is summarized in
>> docs/dev/events.pod.

> Thanks, I didn't see that. My problem isn't with what the
> implementation does, though -- it's that I don't understand the
> rationale. I can understand why there would need to be a global event
> thread (timers, GC, DoD), but why would passing a message from one
> thread to another need to be serialized through a global event queue?

The main reason for the global event queue isn't message passing. The
reason is POSIX signals. Basically you aren't allowed to do anything
serious in a signal handler, especially you aren't allowed to broadcast
a condition or something.
So I came up with that experimental code of one thread doing signals.

> And as for IO, I see the obvious advantages of performing synchronous
> IO functions in a separate thread to make them asynchronous, but that
> sounds like the job of a worker thread pool. There are many ways to
> implement this, but serializing them all through one queue sounds like
> a bottleneck to me.

Yes. The AIO library is doing that anyway i.e. utilizing a thread pool
for IO operations.

>> Au contraire. Your analysis is precise. Do you like to take a shot at a
>> Win32 threads/event model? So we could figure out the necessary
>> splitting of API/implementation.

> OK. I think I need to have a better understanding on what events
> actually are, though. Who sends them? What do they mean? Which signals
> do we actually care about? What are notifications? How will AIO
> actually be handled? You know, that sort of thing... Maybe there
> should be a PDD for it?

Dan did post a series of documents to the list some time ago. Sorry I'be
no exact subject, but with relevant keywords like "events" you should
find it.

> GNS

leo

Re: SDL: Locate shared libraries

[Leopold Toetsch]

Adam Warner wrote:
Hello again,
x86 Debian sid with the SDL libraries installed:

In runtime/parrot/library/SDL.imc I replaced the respective loadlibs with:
   loadlib libsdl, 'libSDL-1.2.so.0'
That's not a general solution, as it makes explicit system-dependent 
assumptions on filenames.

I've added explicit symlinks - it looks like a debian problem (missing 
link to .so):

$ locate libSDL_image
/usr/lib/libSDL_image-1.2.so.0
/usr/lib/libSDL_image-1.2.so.0.1.2
/usr/lib/libSDL_image.so
$ ls -l $(locate libSDL_image.so)
...  /usr/lib/libSDL_image.so -> libSDL_image-1.2.so.0
(for all these libs)
And it worked! (w/warning: SDL::fetch_layout warning: layout 'Pixels' not found!)
Yep.
At this stage of development is parrot supposed to automatically locate
the shared libraries?
If they are named properly and are located in either 
runtime/parrot/dynext/ or in a location that the loader searches - yes.

Thanks,
Adam
leo

Re: IEEE 754 double floats

[Adam Warner]

Hi Leopold Toetsch,

>> PI is (very) approximately:
>   3.1415906535896946927266526472521945834159851074218750
>  ^
>   3.141592653589793238462643383279502884197169399375105820974944
> 
> You might probably want to run more iterations ;) And you'll never get
> 60 digits out of long doubles.

I appreciate that Leopold. I thought the zeros indicated where the stored
value cuts off. But with 52 significant figures at ~3.3 bits per figure
that's about 172 bits, which indicates they would have to be 256 bit
floats when including the exponent (my mistake in calling them 128 bit)!

In other words sprintf is printing trailing garbage:

.sub _main
set N1, 2.0
set N2, 3.0
div N1, N1, N2
new P0, .PerlArray
set P0, 1
set P0[0], N1
sprintf S0, "%.60f\n", P0
print   S0
end
.end

On the CVS version I compiled this prints:
0.2965923251249478198587894439697265625000

On this win32 release (running on a different machine):
http://www.jwcs.net/developers/perl/pow/download/pow-0.1.1-release.zip
parrot prints:
0.3000

Regards,
Adam

Re: IEEE 754 double floats

[Leopold Toetsch]

Adam Warner <[EMAIL PROTECTED]> wrote:

> In other words sprintf is printing trailing garbage:

Well, the underlaying architecture is defining the precision of floats.
And due to the binary nature of the representation of floats they are
mostly just and inprecise approximation of a given float value and of
course only until a certain limit of digits.

All printed digits beyond that limit are just not defined,
implementation dependent, whatever - or garbage.

> Regards,
> Adam

leo

Re: [PROPOSAL] for a new calling scheme

[Dan Sugalski]

At 11:43 AM +0100 11/16/04, Leopold Toetsch wrote:
Below inline/attached is a proposal for new calling conventions - 
for the archive as Dan doesn't like changes now, but I haven't to 
backup it, when its out ;)
Alright, that does it. I am *tired* of this. I'm tired of the 
sniping, I'm tired of the constant attempts to change decisions that 
have been made, I'm tired of the pecking away at things you don't 
don't like and won't deal with, and I'm tired of all the backhand 
snide comments.

What part of "This stuff isn't going to change" hasn't been clear?
This. Is. Not. Changing. Period.
I don't give a damn if you don't like it. Cope.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Continuations, basic blocks, loops and register allocation

[Matt Fowles]

Leo~

On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
> 
> [ continuations should restore registers ]
> 
> > I am sorry, but I don't understand what you are trying to say here.
> > Would you mind rewording it for me?
> 
> Imagine a simple loop:
> 
> i = 0
>   lp:
> foo()
> inc i
> if i < 10 goto lp
> 
> Looking at the loop counter a programmer or optimizer could easily
> decide that using an I-Reg for it instead of a P-Reg is fine. Now comes
> your proposed implementation for continuations: they copy the register
> frame on creation and restore it on invocation. Besides of the big cost
> of the memcpy's this simple loop above suddenly stops working, depending
> on the implementation of foo() - which might be outside your control.
> 
> BTW in an early stage we had exactly this behavior of continuations.
> This was abandoned. The subject was IIRC something like "Should
> continuations close over registers". The answer was clearly "no".

There is one thing I am not sure about here.  The loop will work
correctly for each seperate invocation of the appropriate
continuation.  The first time you call foo i is 0.  The second time i
is 1.  If foo ever invokes the full continuations that it captured at
one of these points, then i will go back to whatever it was when that
continuation was captured.  All of this seems like reasonable behavior
to me.  In the general case our optimizer will not be able to downgrad
i from a P to an I register anyway, as foo could mess with $CALLER::i
or whatever.  Thus, I am not sure that I by your argument.

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

Re: [PROPOSAL] for a new calling scheme

[=?iso-8859-1?Q?St=E9phane?= Payrard]

On Tue, Nov 16, 2004 at 08:52:10AM -0500, Dan Sugalski wrote:
> At 11:43 AM +0100 11/16/04, Leopold Toetsch wrote:
> >Below inline/attached is a proposal for new calling conventions - 
> >for the archive as Dan doesn't like changes now, but I haven't to 
> >backup it, when its out ;)
> 
> Alright, that does it. I am *tired* of this. I'm tired of the 
> sniping, I'm tired of the constant attempts to change decisions that 
> have been made, I'm tired of the pecking away at things you don't 
> don't like and won't deal with, and I'm tired of all the backhand 
> snide comments.
> 
> What part of "This stuff isn't going to change" hasn't been clear?
> 
> This. Is. Not. Changing. Period.
> 
> I don't give a damn if you don't like it. Cope.

Probably, the timing of the proposition is wrong. But having
Leo thinking out loud and putting out propositions is a good
way for less trained people to learn about the current behavior
of parrot, its strengths and deficiencies.

Also,  as we expect code written and generated for
parrot to grow faster in the months to come , it may good to
prepare people for possible future changes in calling
conventions. Personnally I am all for writing and generating PIR
so as to insulate code from the said changes.

Putting your architect hat, Dan, can you spell a policy in this matter?

--
 stef

Re: [PROPOSAL] for a new calling scheme

[Dan Sugalski]

At 4:48 PM +0100 11/16/04, Stéphane Payrard wrote:
Putting your architect hat, Dan, can you spell a policy in this matter?
Sure.
The calling conventions are fixed. They are not going to change again.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: [PROPOSAL] for a new calling scheme

[=?iso-8859-1?Q?St=E9phane?= Payrard]

On Tue, Nov 16, 2004 at 10:48:18AM -0500, Dan Sugalski wrote:
> At 4:48 PM +0100 11/16/04, Stéphane Payrard wrote:
> >Putting your architect hat, Dan, can you spell a policy in this matter?
> 
> Sure.
> 
> The calling conventions are fixed. They are not going to change
> again.

You are not answering my question about the preferred assembler for code
generators and hand-programmes (PIR or PASM).
It was addmittedly asked in the context of calling conventions,
but may be it deserves to be answered independantly of this.

--
 stef


> --
>   Dan

Re: [PROPOSAL] for a new calling scheme

[Leopold Toetsch]

Dan Sugalski wrote:
What part of "This stuff isn't going to change" hasn't been clear?
Your sentence below answering Matt's question about dismissing my 
arguments lightly?

There is quite a difference between "not change. Period" and "not change 
now".

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.
-
leo

Re: Continuations, basic blocks, loops and register allocation

[Leopold Toetsch]

Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~

> On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:

>> i = 0
>>   lp:
>> foo()
>> inc i
>> if i < 10 goto lp

> There is one thing I am not sure about here.  The loop will work
> correctly for each seperate invocation of the appropriate
> continuation.

No. Imagine, foo() is not a simple function anymore. Someone e.g. Jens
Rieks[1], discovers that the algoritm is simpler implemented with
continuations. So inside foo() the return continuation of foo() is
copyied, stored elsewhere, passed along to another function, and that
one now suddenly returns via this continuation to your loop.  If this
invocation of the continuation would restore registers suddenly the loop
will become an infinite one, as C is always restored to zero.

[1] Have a look at runtime/parrot/library/Streams/Sub.imc

leo

Re: [PROPOSAL] for a new calling scheme

[Dan Sugalski]

At 4:49 PM +0100 11/16/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
What part of "This stuff isn't going to change" hasn't been clear?
Your sentence below answering Matt's question about dismissing my 
arguments lightly?

There is quite a difference between "not change. Period" and "not change now".
Then I should amend things.
The calling conventions are fixed. They are not going to be revisited. Period.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: [PROPOSAL] for a new calling scheme

[Leopold Toetsch]

Stéphane Payrard <[EMAIL PROTECTED]> wrote:

> Probably, the timing of the proposition is wrong.

I'd appreciate a discussion about the mentioned issues, which are
serious in my opinion. These issues have to be addressed, sooner or
later.

I didn't propose to make changes now, just the opposite.

leo

Re: IEEE 754 double floats

[Bill Coffman]

Another way is to count the bits, as in the following:

.sub _main
N1 = 1
N2 = 0.5
I0 = 0
REPEAT:
I0 = I0 + 1
N2 = N2 / 2
N3 = N1 + N2
ne N1, N3, REPEAT

print I0
print " bits precision\n"
end
.end



On Wed, 17 Nov 2004 01:13:21 +1300, Adam Warner <[EMAIL PROTECTED]> wrote:
> Hi Leopold Toetsch,
> 
> >> PI is (very) approximately:
> >   3.1415906535896946927266526472521945834159851074218750
> >  ^
> >   3.141592653589793238462643383279502884197169399375105820974944
> >
> > You might probably want to run more iterations ;) And you'll never get
> > 60 digits out of long doubles.
> 
> I appreciate that Leopold. I thought the zeros indicated where the stored
> value cuts off. But with 52 significant figures at ~3.3 bits per figure
> that's about 172 bits, which indicates they would have to be 256 bit
> floats when including the exponent (my mistake in calling them 128 bit)!
> 
> In other words sprintf is printing trailing garbage:
> 
> .sub _main
> set N1, 2.0
> set N2, 3.0
> div N1, N1, N2
> new P0, .PerlArray
> set P0, 1
> set P0[0], N1
> sprintf S0, "%.60f\n", P0
> print   S0
> end
> .end
> 
> On the CVS version I compiled this prints:
> 0.2965923251249478198587894439697265625000
> 
> On this win32 release (running on a different machine):
> http://www.jwcs.net/developers/perl/pow/download/pow-0.1.1-release.zip
> parrot prints:
> 0.3000
> 
> Regards,
> Adam
> 
>

Re: Continuations, basic blocks, loops and register allocation

[Matt Fowles]

Leo~

On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 
> 
> Matt Fowles <[EMAIL PROTECTED]> wrote:
> > Leo~
> 
> > On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> 
> > wrote:
> 
> >> i = 0
> >>   lp:
> >> foo()
> >> inc i
> >> if i < 10 goto lp
> 
> > There is one thing I am not sure about here.  The loop will work
> > correctly for each seperate invocation of the appropriate
> > continuation.
> 
> No. Imagine, foo() is not a simple function anymore. Someone e.g. Jens
> Rieks[1], discovers that the algoritm is simpler implemented with
> continuations. So inside foo() the return continuation of foo() is
> copyied, stored elsewhere, passed along to another function, and that
> one now suddenly returns via this continuation to your loop.  If this
> invocation of the continuation would restore registers suddenly the loop
> will become an infinite one, as C is always restored to zero.
> 
> [1] Have a look at runtime/parrot/library/Streams/Sub.imc
> 
> leo
> 

I disagree with that analysis.  Let us consider the actual effect of
such an implementation.

First iteration

i = 0;
foo(); #at this point a continuation created capturing i=0, promoted
by Jens and stuff happens
#eventually it is invoked, restoring i=0
i++; #i = 1
foo(); #at this point a NEW return continuation is created capturing
i=1; promoted by Jens...
#eventually it is invoked, restoring i=1
i++; #i = 2
...

Thus every single invocation of foo will have an i one greater than
the last.  If foo's algorithm had an error and did not use the new
return continuation to recreate its internal continuation each time,
then you would be correct.  But that would be a bug in the
implementation of foo.

As the following code

#set up for foo
foo()
#set other stuff for foo
foo()

would be an infinite loop alway returning immediately after the first
invocation of foo.

I looked at Sub.imc and think it would work because write always
creates a new Continuation for each invocation of write.

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

Re: AIX PPC JIT warning

[Leopold Toetsch]

Adam Thomason <[EMAIL PROTECTED]> wrote:

> I just cvs up'ed and upgraded to perl 5.8.5, and now parrot's make
> testj matches make test (some unimplemented PMC method errors in
> both... is this expected?).

I don't know, which errors you got ;) Anyway, as of now JIT/PPC on OS X
is passing all tests.

> ... I'm not sure what's responsible, but the
> segfaults have gone away.

Which perl version did you replace? Can you reproduce the failures with
the old perl? If yes, we should drop a note somewhere about this
incompatibility.

> Adam

Thanks,
leo

Re: [PROPOSAL] for a new calling scheme

[Dan Sugalski]

At 5:11 PM +0100 11/16/04, Leopold Toetsch wrote:
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
 Probably, the timing of the proposition is wrong.
I'd appreciate a discussion about the mentioned issues
An updated PDD 03 is in the repository. It's 
clear on what the caller populates, what the 
callee sees, and what happens to all the 
different registers.

This incoporates the discussion to date. It is final.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Continuations, basic blocks, loops and register allocation

[Dan Sugalski]

At 11:52 AM -0500 11/16/04, Matt Fowles wrote:
Leo~
On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:

 Matt Fowles <[EMAIL PROTECTED]> wrote:
 > Leo~
 > On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> 
wrote:
 >> i = 0
 >>   lp:
 >> foo()
 >> inc i
 >> if i < 10 goto lp
 > There is one thing I am not sure about here.  The loop will work
 > correctly for each seperate invocation of the appropriate
 > continuation.
 No. Imagine, foo() is not a simple function anymore. Someone e.g. Jens
 Rieks[1], discovers that the algoritm is simpler implemented with
 continuations. So inside foo() the return continuation of foo() is
 copyied, stored elsewhere, passed along to another function, and that
 one now suddenly returns via this continuation to your loop.  If this
 invocation of the continuation would restore registers suddenly the loop
 will become an infinite one, as C is always restored to zero.
 [1] Have a look at runtime/parrot/library/Streams/Sub.imc
 leo
I disagree with that analysis.
You would, however, in this case be incorrect.
The loop variable must have a backing store outside of the register 
set. The contents of registers must be assumed to be unreliable when 
a continuation is continued. If we declare that they are put back 
into the state they were when the continuation was taken, which is 
reasonable though not required, the values of non-reference type 
registers (ints and floats) will be reset. The rference type 
registers (strings and PMCs) will also be reset so the pointers to 
the string/pmc structs will be what they were when the continuation 
was taken, but as they are references the referred-to thing may have 
changed and the changed value will be seen.
--
Dan

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

Re: Continuations, basic blocks, loops and register allocation

[Leopold Toetsch]

Matt Fowles wrote:
I disagree with that analysis.  Let us consider the actual effect of
such an implementation.
First iteration
i = 0;
foo(); #at this point a continuation created capturing i=0, promoted
by Jens and stuff happens
#eventually it is invoked, restoring i=0
i++; #i = 1
foo(); #at this point a NEW return continuation is created capturing
That would work if there is a one to one representation of the invoation 
of foo() an it's continuation. But no one guarantees that.

By repeatedly invocing the continuation you alway get to the opcode 
after invoke, and registers would be restored to some earlier state.

...  If foo's algorithm had an error and did not use the new
return continuation to recreate its internal continuation each time,
then you would be correct.  But that would be a bug in the
implementation of foo.
Why? If foo's implementation is changed internally to double it's work 
per call, it could indicate that progress by returning twice through the 
same continuation.

E.g.
  unless done
 (done, result) = foo()
 s .= result
leo

Re: [PROPOSAL] for a new calling scheme

[Matt Fowles]

Dan~


On Tue, 16 Nov 2004 12:22:23 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> An updated PDD 03 is in the repository. It's
> clear on what the caller populates, what the
> callee sees, and what happens to all the
> different registers.

At line 72, "Note that fact if a return continuation object is created
explicitly, rather than by an invocation op," what is the remainder of
this sentence?

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

Re: [PROPOSAL] for a new calling scheme

[Dan Sugalski]

At 12:56 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 12:22:23 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 An updated PDD 03 is in the repository. It's
 clear on what the caller populates, what the
 callee sees, and what happens to all the
 different registers.
At line 72, "Note that fact if a return continuation object is created
explicitly, rather than by an invocation op," what is the remainder of
this sentence?
Now checked into CVS.
  --- pdd03_calling_conventions.pod	16 Nov 2004 17:15:08 -	1.23
  +++ pdd03_calling_conventions.pod	16 Nov 2004 17:50:01 -	1.24
  @@ -1,5 +1,5 @@
   # Copyright: 2001-2004 The Perl Foundation.  All Rights Reserved.
  -# $Id: pdd03_calling_conventions.pod,v 1.23 2004/11/16 17:15:08 dan Exp $
  +# $Id: pdd03_calling_conventions.pod,v 1.24 2004/11/16 17:50:01 dan Exp $
  
   =head1 NAME
  
  @@ -70,7 +70,10 @@
   16-31 will be set such that the contents of those registers are
   identical to the content of the registers when the return continuation
   was I. Note that if a return continuation object is created
  -explicitly, rather than by an invocation op,
  +explicitly, rather than by an invocation op, the preserved registers
  +will be in the state they were at the time the continuation was made,
  +rather than the state they were at the time the continuation was
  +passed into an invocation.

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

Re: Continuations, basic blocks, loops and register allocation

[Matt Fowles]

Dan~


On Tue, 16 Nov 2004 12:29:19 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:52 AM -0500 11/16/04, Matt Fowles wrote:
> 
> 
> >Leo~
> >
> >On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> 
> >wrote:
> >>
> >>
> >>  Matt Fowles <[EMAIL PROTECTED]> wrote:
> >>  > Leo~
> >>
> >>  > On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> 
> >> wrote:
> >>
> >>  >> i = 0
> >>  >>   lp:
> >>  >> foo()
> >>  >> inc i
> >>  >> if i < 10 goto lp
> >>
> >>  > There is one thing I am not sure about here.  The loop will work
> >>  > correctly for each seperate invocation of the appropriate
> >>  > continuation.
> >>
> >>  No. Imagine, foo() is not a simple function anymore. Someone e.g. Jens
> >>  Rieks[1], discovers that the algoritm is simpler implemented with
> >>  continuations. So inside foo() the return continuation of foo() is
> >>  copyied, stored elsewhere, passed along to another function, and that
> >>  one now suddenly returns via this continuation to your loop.  If this
> >>  invocation of the continuation would restore registers suddenly the loop
> >>  will become an infinite one, as C is always restored to zero.
> >>
> >>  [1] Have a look at runtime/parrot/library/Streams/Sub.imc
> >>
> >>  leo
> >>
> >
> >I disagree with that analysis.
> 
> You would, however, in this case be incorrect.
> 
> The loop variable must have a backing store outside of the register
> set. The contents of registers must be assumed to be unreliable when
> a continuation is continued. If we declare that they are put back
> into the state they were when the continuation was taken, which is
> reasonable though not required, the values of non-reference type
> registers (ints and floats) will be reset. The rference type
> registers (strings and PMCs) will also be reset so the pointers to
> the string/pmc structs will be what they were when the continuation
> was taken, but as they are references the referred-to thing may have
> changed and the changed value will be seen.

I am having trouble in that I agree with what you are saying, but I am
coming to a different conclusion.  I think that foo would create a new
continuation (from it return continuation) each time it is called, and
thus things below it on the call stack would be unaffected by its own
internal continuation tricks (assuming for the moment that registers
are put back into place by continuations).

Since both you and Leo are arguing against me here, it seems like that
I am wrong, but I would like to figure out exactly why I am wrong so
that I can correct my train of thought in the future.

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

Re: Another issue with pdd03

[Jeff Clites]

On Nov 15, 2004, at 12:38 AM, Leopold Toetsch wrote:
Bill Coffman <[EMAIL PROTECTED]> wrote:
[ pdd03 ]
The way I read it, paragraph one implies that when you print P5 after
calling foo(), you are expecting to get the return value.  You didn't
save and restore register P5, so you wanted foo() to do something to
it.
The nasty thing of a function call is:
  i = foo()   # fine P5 returned
vs.
  foo()   # P5 clobbered by foo
(but you can replace P5 with P15 too, or every register R5..R15)
This has never bothered me, probably because of the comparison to the 
register-based calling conventions that the PPC uses: A called function 
(which returns a value) has to store its result in some register, 
whether or not the caller wants it. A call like "i = foo()" is really 
two steps: call the function, then copy the result from r3 to the 
appropriate location (maybe a location on the stack, maybe another 
register). It may be possible to optimize so that "i" is already using 
the same register as the return value, but in general that can't be 
arranged for most cases; consider how this would compile:

	i = foo() //call foo, copy result from r3 to other register--must 
since bar() would clobber
	j = bar() //call bar, copy result from r3 to other register--could 
avoid copy, if j not
			//needed past baz
	baz(i + j) //add those two other registers into r3, and call baz

And due to the register-preservation semantics on the PPC, even a call 
to a void-return function could clobber r3, since it could call another 
function which returns a result and thus uses r3.

Not that parrot has to necessarily work this way, but it at least has 
precedent, so it's not totally strange behavior.

JEff

Re: Another issue with pdd03

[Jeff Clites]

On Nov 14, 2004, at 9:32 AM, Leopold Toetsch wrote:
Defining now that P5 has to be preserved in main, because it's a 
possible return result of foo() and therefore may be clobbered by 
foo() is meaning, that we have effectively just 16 registers per kind 
available for allocation around a function call.

If the latter is true according to current pdd03 then we are wasting 
half of our registers for a very doubtful advantage: being able to 
pass return values in R5..R15.
In effect this is quite similar to the PPC calling conventions: we have 
roughly half of the registers preserved across function calls. In terms 
of the volatile registers, it's fine to use them for local 
calculations, as long as either you're using them to hold values which 
don't need to persist across function calls, or you 
preserve-and-restore them yourself.

But that loops back to a previous proposal of mine: If they're not 
being preserved, and in fact need to be "synced" between caller and 
callee, then having these registers physically located in the 
interpreter structure, rather than in the bp-referenced frame, saves 
all the copying, and makes it more obvious what's going on.

JEff

Re: Continuations, basic blocks, loops and register allocation

[Jeff Clites]

On Nov 15, 2004, at 10:29 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
Picture this call stack:

	main --> A --> B --> C --> D --> E

The call from D to E uses the "RESUMEABLE" label, and E stores the
resulting continuation in a global, and everything up to main returns.
Then, main invokes the continuation, and we find ourselves back in D.
Now, C, B, and A will return "again", without any compile-time hint.
That's fine. The return is an expected operation. I don't think that's
the problem. The error in gc_13 is a call path like:
   choose() -> try (with_cc) -> fail() ->
|
 (choose again)  <- + <--+
 |
   choose() -> try (with_cc) -> fail() ->|
||
 (choose again)  <- +|
 |
   fail()  --+
The problem now is not per se the path in main from the two choose()
calls down to fail is executed more then once (as it's the case with
multiple returns). The problem is the loop in main. By denoting the 
loop
from the call to fail() to the first choose() with some kind of syntax,
the register allocator does the right thing.
But consider even this simple function:
sub B
{
a = 1
foo()
print a
b = 2
return b
}
If something called by foo() captures a continuation, and something 
invokes it after B() returns, then there's a hidden branch, in effect, 
from the return to the print, isn't there? The register allocator could 
decide to use the same register for a and b, but then the "second" 
return from foo() would print 2 instead of 1, which is wrong. And the 
author of B(), of course, may have no idea such a thing would happen, 
so wouldn't be able to supply any syntax to tell the compiler.

I'm just trying to come up with a simpler example, since it seems to me 
that there's a problem any time a function returns, and the last thing 
that executed in that frame wasn't a call to that function. (There's a 
lot going on in the gc_13 example, and I think some of it is 
distracting from the main point.)

But a RESUMABLE label seems like the information that's needed by the 
compiler. But on the other hand in an example like the above, the 
function B() may not be written to expect foo() to be resumed. So, what 
should happen at runtime, if the label is absent? We could declare 
undefined behavior, but that would mean that for defined behavior, 
you'd need the RESUMABLE label all the way up the stack, and Ruby and 
Scheme don't have that syntactic constraint. With Scheme, it's only 
clear from the syntax what's going on locally--but you can invoke a 
continuation far from any call/cc, if that continuation was stored away 
into a variable.

JEff

Re: Continuations, basic blocks, loops and register allocation

[Matt Fowles]

Leo~

On Tue, 16 Nov 2004 18:32:07 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
> 
> 
> > I disagree with that analysis.  Let us consider the actual effect of
> > such an implementation.
> >
> > First iteration
> >
> > i = 0;
> > foo(); #at this point a continuation created capturing i=0, promoted
> > by Jens and stuff happens
> > #eventually it is invoked, restoring i=0
> > i++; #i = 1
> > foo(); #at this point a NEW return continuation is created capturing
> 
> That would work if there is a one to one representation of the invoation
> of foo() an it's continuation. But no one guarantees that.

I suppose that what I am arguing is that anyone who does not maintain
such a one-to-one representation (at least from the perspective of
code calling foo()); full well deserves what they get.  They are
restoring the execution to an earlier state by invoking an old
continuation.  If the earlier state called them again the first time,
they should probably expect the earlier state to call them again the
second time.  Unless they have some specific knowledge that the
earlier state will change it behavior (because things in the heap have
changed), there should be no expectation for it to.

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

Re: [PROPOSAL] for a new calling scheme

[Matt Fowles]

Dan~

On Tue, 16 Nov 2004 13:00:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:56 PM -0500 11/16/04, Matt Fowles wrote:
> >At line 72, "Note that fact if a return continuation object is created
> >explicitly, rather than by an invocation op," what is the remainder of
> >this sentence?
> 
> Now checked into CVS.

Earlier in that same paragraph you state that "registers 16-31 will be
set...".  To which groups of registers are you referring, P or (I,S,P,
and N)?

I don't mean to be trouble some, I am just trying to make sure it is
clear and I understand it.

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

Re: [PROPOSAL] for a new calling scheme

[Dan Sugalski]

At 1:11 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 13:00:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 At 12:56 PM -0500 11/16/04, Matt Fowles wrote:
 >At line 72, "Note that fact if a return continuation object is created
 >explicitly, rather than by an invocation op," what is the remainder of
 >this sentence?
 Now checked into CVS.
Earlier in that same paragraph you state that "registers 16-31 will be
set...".  To which groups of registers are you referring, P or (I,S,P,
and N)?
All of them. Clarification on its way in.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: [PROPOSAL] for a new calling scheme

[Matt Fowles]

Dan~

On Tue, 16 Nov 2004 13:14:00 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:11 PM -0500 11/16/04, Matt Fowles wrote:
> 
> 
> >Dan~
> >
> >On Tue, 16 Nov 2004 13:00:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >>  At 12:56 PM -0500 11/16/04, Matt Fowles wrote:
> >>  >At line 72, "Note that fact if a return continuation object is created
> >>  >explicitly, rather than by an invocation op," what is the remainder of
> >>  >this sentence?
> >>
> >>  Now checked into CVS.
> >
> >Earlier in that same paragraph you state that "registers 16-31 will be
> >set...".  To which groups of registers are you referring, P or (I,S,P,
> >and N)?
> 
> All of them. Clarification on its way in.

Thanks, I think I have run out of nits

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

Re: Continuations, basic blocks, loops and register allocation

[Jeff Clites]

On Nov 16, 2004, at 10:03 AM, Matt Fowles wrote:
Since both you and Leo are arguing against me here, it seems like that
I am wrong, but I would like to figure out exactly why I am wrong so
that I can correct my train of thought in the future.
Here's a real example you can play with, if you have Ruby installed:
% cat continuation6.ruby
def strange
callcc {|continuation| $saved = continuation}
end
def outer
a = 0
strange()
a = a + 1
print "a = ", a, "\n"
end
# these two lines are "main"
outer()
$saved.call
% ruby continuation6.ruby
a = 1
a = 2
a = 3
a = 4
a = 5
a = 6
a = 7
a = 8
a = 9
a = 10
...infinite loop, by design
What happens when the program runs is that outer() is called (only 
once) which creates a continuation (inside of strange()), increments a, 
prints and returns. The next thing that happens is that the 
continuation is invoked. Control jumps to the location in strange() 
right after the callcc line, then that return and we are at the line in 
outer() where 'a' is incremented. So 'a' increments from the last value 
it had in that frame (since we are magically back again inside of the 
"same" single invocation of outer()), then 'a' is printed and outer() 
returns again (note: outer only called once, returned twice so far), 
and then we call the continuation again, and start the loop over.

We only ever create one continuation in this example, since we only 
ever call strange() once. The continuation preserves the frame (the 
mapping from logical variables to their values), but not the values of 
those variables at the time the continuation was created. In effect, I 
think the continuation is arranging to preserve the state of the 
variables as they were when code in the frame was last executed, rather 
than at the time the continuation was created.

The behavior you were describing is what I had thought would happen, 
but then I realized I wasn't sure, so I confirmed that it wasn't. The 
above is the behavior of Ruby, and I believe Scheme works the same way. 
What you described would be useful for backtracking (jumping back not 
only to a previous location in a computation, but also its previous 
state), but it's not what these languages seem to do.

JEff

Re: Continuations, basic blocks, loops and register allocation

[Dan Sugalski]

At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
The continuation preserves the frame (the mapping from logical 
variables to their values), but not the values of those variables at 
the time the continuation was created.
This is one of the fundamental properties of continuations, but it 
does throw people. And it's why register contents have to be thrown 
away when a continuation is invoked, since the registers have values, 
and continuations don't preserve values.
--
Dan

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

Fwd: Re: Parrot BASIC

[Joshua Gatcomb]

All,
Please read Clinton's reply - especially the part
about being blocked from the list for about a year.

Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region


--- "Clinton A. Pierce" <[EMAIL PROTECTED]> wrote:

> Date: Tue, 16 Nov 2004 11:34:05 -0500
> To: Joshua Gatcomb <[EMAIL PROTECTED]>
> From: "Clinton A. Pierce" <[EMAIL PROTECTED]>
> Subject: Re: Parrot BASIC
> CC: [EMAIL PROTECTED]
> 
> At 12:54 PM 11/15/2004 -0800, Joshua Gatcomb wrote:
> >Clinton,
> >William Coleda has updated Parrot BASIC enough to
> get
> >wumpus and screen working, albeit not entirely
> >cleanly.  In IRC, it was mentioned by Dan that we
> >should be automating some BASIC tests as part of
> the
> >test suite.  We were wondering what your thoughts
> on
> >it were and if you plan on continuing maintenance?
> >
> >And just to be clear for those reading at
> homejust
> >because I am asking doesn't mean I am volunteering.
> 
> I've been neglectful in taking care of this, sure. 
> A few things to note:
> 
> * I've been unable to post to p6i for over a year
> now.  My mail-relay for 
> my ISP (Comcast) and my hosted domain (geeksalad)
> has been on a blacklist 
> for sending to perl.org for quite a while.  I can't
> move my domain till Feb 
> at the inside, and don't have another mail option
> handy.  Not being able to 
> write to p6i dampens enthusiasm for the project a
> bit.  (You'll note the 
> cc'd copy probably won't reach P6I.  Feel free to
> forward it to them.)
> 
> * Originally it was an interesting hack for the
> infant Parrot (before PIR, 
> in the spirit of TinyBASIC), then a little more
> serious hack (look, a 
> QuickBASIC that plays chess in color!), but since
> there's a plethora of 
> other languages it has lost its hack value.  Is
> there a need beyond the 
> initial hacks?  If so, then I'm still interested
> because...
> 
> * It should probably be re-written by someone who
> understands parsers and 
> writing real language compilers.  I'm willing to
> learn (I'd love to 
> learn!), but I'm going to need to pester the hell
> out of someone every now 
> and then for help.  This is step 0 in making it
> supportable.
> 
> * Step 1, of course, is to write tests.  Since it
> was a hack, and the test 
> framework was iffy at the time of the first hack, I
> never really got around 
> to it.  About the time that I did (6/2003) I lost
> the ability to post to P6I.
> 
> So I'd be willing to work, when I have tuits (I get
> them now and 
> again).  If there's a need and someone willing to
> coach...
> 
> 
> 




__ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 

Re: Continuations, basic blocks, loops and register allocation

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:

> sub B
> {
>   a = 1
>   foo()
>   print a
>   b = 2
>   return b
> }

> If something called by foo() captures a continuation, and something
> invokes it after B() returns, then there's a hidden branch, in effect,
> from the return to the print, isn't there?

Yes. That's right and would cause problems. Again this is creating a
loop as you say from the return to the print statement.

OTOH looking at the scheme example, you can create such continuation
loops just for nested closures. All other usage would be like a "goto"
statement into the middle of some totally unrelated subroutine, which is
only solvable by going "the all gets refetched" road.

> But a RESUMABLE label seems like the information that's needed by the
> compiler. But on the other hand in an example like the above, the
> function B() may not be written to expect foo() to be resumed.

Yes. Again, the HLL language, that is creating the code has a clear
indication, what's going on. PIR code currently hasn't.

> ... With Scheme, it's only
> clear from the syntax what's going on locally--but you can invoke a
> continuation far from any call/cc, if that continuation was stored away
> into a variable.

So all closures inside that call/cc have to be emitted in such a way that
they can cope with it. It's IMHO nothing we can solve, except for
providing some syntax construct that clearly indicates the possible loop
for the CFG.

> JEff

leo

Re: Another issue with pdd03

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:

[ PPC ABI ]

> Not that parrot has to necessarily work this way, but it at least has
> precedent, so it's not totally strange behavior.

Sure it's neither strnge nor unsimilar. Except that the PPC ABI defines
more preserved registers (r13..r31) assuming pressure is on P registers
only, and albeit I don't know how and where the hardware is preserving
them, it does obviosly not cause level 2 cache misses. Refetching from
stack is of course cheaper in hardware too.

> JEff

leo

Re: Another issue with pdd03

[Leopold Toetsch]

Jeff Clites <[EMAIL PROTECTED]> wrote:

> But that loops back to a previous proposal of mine: If they're not
> being preserved, and in fact need to be "synced" between caller and
> callee, then having these registers physically located in the
> interpreter structure, rather than in the bp-referenced frame, saves
> all the copying, and makes it more obvious what's going on.

Well I answered that already. Having two distinct addressing schemes for
volatile and non-volatile registers has a serious overhead for
non-prederefed run cores. OTOH in the light of a recent discussion this
approach could be an alternative.

> JEff

leo

Re: Continuations, basic blocks, loops and register allocation

[Matt Fowles]

Dan~

On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
> >The continuation preserves the frame (the mapping from logical
> >variables to their values), but not the values of those variables at
> >the time the continuation was created.
> 
> This is one of the fundamental properties of continuations, but it
> does throw people. And it's why register contents have to be thrown
> away when a continuation is invoked, since the registers have values,
> and continuations don't preserve values.

I think right here we have the crux of my failure to understand.  I
was/am under the impression that the continuation will restore the
register frame to exactly as it was when the continuation was taken. 
Thus those registers which are values (I,N) will continue to have the
value they had when the continuation was taken, while those registers
which are pointers/references (S, P) will still point to the same
place, but that data may have changed.  Is this correct?

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

Re: cvs commit: parrot/docs/pdds pdd03_calling_conventions.pod

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:
>   +I if there are overflow parameters. Otherwise garbage

>   +=item I0
>   +
>   +=item I1-I4

I3 isn't always visible?

>   ... Fetching the return continuation
>   +may be expensive, and should only be done if truly necessary.

Err, e.g. for returning from the sub?

This would imply a distinct return opcode instead of C.

  ret_cc
  returncc
  ...

leo

Re: Continuations, basic blocks, loops and register allocation

[Dan Sugalski]

At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
 >The continuation preserves the frame (the mapping from logical
 >variables to their values), but not the values of those variables at
 >the time the continuation was created.
 This is one of the fundamental properties of continuations, but it
 does throw people. And it's why register contents have to be thrown
 away when a continuation is invoked, since the registers have values,
 and continuations don't preserve values.
I think right here we have the crux of my failure to understand.  I
was/am under the impression that the continuation will restore the
register frame to exactly as it was when the continuation was taken.
Thus those registers which are values (I,N) will continue to have the
value they had when the continuation was taken, while those registers
which are pointers/references (S, P) will still point to the same
place, but that data may have changed.  Is this correct?
No. The registers are just about the only thing that *isn't* restored.
Continuations put the environment back. This includes things like the 
lexical pad stack, the namespace stack, the stack itself, any 
security credentials... basically everything that describes the 
environment. *Data*, on the other hand, is *not* restored. Data stays 
as it is.

Registers are a special case of data, and they're just declared crud 
by fiat, since otherwise things get nasty and unpredictable.
--
Dan

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

Re: cvs commit: parrot/docs/pdds pdd03_calling_conventions.pod

[Dan Sugalski]

At 9:16 PM +0100 11/16/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
   +I if there are overflow parameters. Otherwise garbage

   +=item I0
   +
   +=item I1-I4
I3 isn't always visible?
Effectively it is, yes.
 >   ... Fetching the return continuation
   +may be expensive, and should only be done if truly necessary.
Err, e.g. for returning from the sub?
This would imply a distinct return opcode instead of C.
That went in, or was supposed to go in, as part of moving the return 
continuation into the interpreter struct. I presume this hasn't 
happened?
--
Dan

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

Re: Continuations, basic blocks, loops and register allocation

[Matt Fowles]

Dan~


On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
> 
> 
> >Dan~
> >
> >On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >>  At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
> >>  >The continuation preserves the frame (the mapping from logical
> >>  >variables to their values), but not the values of those variables at
> >>  >the time the continuation was created.
> >>
> >>  This is one of the fundamental properties of continuations, but it
> >>  does throw people. And it's why register contents have to be thrown
> >>  away when a continuation is invoked, since the registers have values,
> >>  and continuations don't preserve values.
> >
> >I think right here we have the crux of my failure to understand.  I
> >was/am under the impression that the continuation will restore the
> >register frame to exactly as it was when the continuation was taken.
> >Thus those registers which are values (I,N) will continue to have the
> >value they had when the continuation was taken, while those registers
> >which are pointers/references (S, P) will still point to the same
> >place, but that data may have changed.  Is this correct?
> 
> No. The registers are just about the only thing that *isn't* restored.
> 
> Continuations put the environment back. This includes things like the
> lexical pad stack, the namespace stack, the stack itself, any
> security credentials... basically everything that describes the
> environment. *Data*, on the other hand, is *not* restored. Data stays
> as it is.
> 
> Registers are a special case of data, and they're just declared crud
> by fiat, since otherwise things get nasty and unpredictable.

Then I am not sure what you mean by "The return continuation PMC type,
used to create return continuations used for call/return style
programming, guarantees that registers 16-31 will be set such that the
contents of those registers are identical to the content of the
registers when the return continuation was I."

I read that as saying that registers will be restored by
continuations.  If that is not what it is intended to mean, could you
clarify for me.

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

Re: Continuations, basic blocks, loops and register allocation

[Dan Sugalski]

At 3:39 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
 >Dan~
 >
 >On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 >>  At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
 >>  >The continuation preserves the frame (the mapping from logical
 >>  >variables to their values), but not the values of those variables at
 >>  >the time the continuation was created.
 >>
 >>  This is one of the fundamental properties of continuations, but it
 >>  does throw people. And it's why register contents have to be thrown
 >>  away when a continuation is invoked, since the registers have values,
 >>  and continuations don't preserve values.
 >
 >I think right here we have the crux of my failure to understand.  I
 >was/am under the impression that the continuation will restore the
 >register frame to exactly as it was when the continuation was taken.
 >Thus those registers which are values (I,N) will continue to have the
 >value they had when the continuation was taken, while those registers
 >which are pointers/references (S, P) will still point to the same
 >place, but that data may have changed.  Is this correct?
 No. The registers are just about the only thing that *isn't* restored.
 Continuations put the environment back. This includes things like the
 lexical pad stack, the namespace stack, the stack itself, any
 security credentials... basically everything that describes the
 environment. *Data*, on the other hand, is *not* restored. Data stays
 as it is.
 Registers are a special case of data, and they're just declared crud
 by fiat, since otherwise things get nasty and unpredictable.
Then I am not sure what you mean by "The return continuation PMC type,
used to create return continuations used for call/return style
programming, guarantees that registers 16-31 will be set such that the
contents of those registers are identical to the content of the
registers when the return continuation was I."
I read that as saying that registers will be restored by
continuations.  If that is not what it is intended to mean, could you
clarify for me.
Return continuations are special, basically. There are a number of 
specialized continuation forms, and this is one of 'em. Which makes 
things a bit more confusing but, well, there you go.
--
Dan

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

Re: Fwd: Re: Parrot BASIC

[Klaas-Jan Stol]

Joshua Gatcomb wrote:
All,
Please read Clinton's reply - especially the part
about being blocked from the list for about a year.
Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
--- "Clinton A. Pierce" <[EMAIL PROTECTED]> wrote:
 

Date: Tue, 16 Nov 2004 11:34:05 -0500
To: Joshua Gatcomb <[EMAIL PROTECTED]>
From: "Clinton A. Pierce" <[EMAIL PROTECTED]>
Subject: Re: Parrot BASIC
CC: [EMAIL PROTECTED]
At 12:54 PM 11/15/2004 -0800, Joshua Gatcomb wrote:
   

Clinton,
William Coleda has updated Parrot BASIC enough to
 

get
   

wumpus and screen working, albeit not entirely
cleanly.  In IRC, it was mentioned by Dan that we
should be automating some BASIC tests as part of
 

the
   

test suite.  We were wondering what your thoughts
 

on
   

it were and if you plan on continuing maintenance?
And just to be clear for those reading at
 

homejust
   

because I am asking doesn't mean I am volunteering.
 

I've been neglectful in taking care of this, sure. 
A few things to note:

* I've been unable to post to p6i for over a year
now.  My mail-relay for 
my ISP (Comcast) and my hosted domain (geeksalad)
has been on a blacklist 
for sending to perl.org for quite a while.  I can't
move my domain till Feb 
at the inside, and don't have another mail option
handy.  Not being able to 
write to p6i dampens enthusiasm for the project a
bit.  (You'll note the 
cc'd copy probably won't reach P6I.  Feel free to
forward it to them.)

* Originally it was an interesting hack for the
infant Parrot (before PIR, 
in the spirit of TinyBASIC), then a little more
serious hack (look, a 
QuickBASIC that plays chess in color!), but since
there's a plethora of 
other languages it has lost its hack value.  Is
there a need beyond the 
initial hacks?  If so, then I'm still interested
because...

* It should probably be re-written by someone who
understands parsers and 
writing real language compilers.  I'm willing to
learn (I'd love to 
learn!), but I'm going to need to pester the hell
out of someone every now 
and then for help.  This is step 0 in making it
supportable.

* Step 1, of course, is to write tests.  Since it
was a hack, and the test 
framework was iffy at the time of the first hack, I
never really got around 
to it.  About the time that I did (6/2003) I lost
the ability to post to P6I.

So I'd be willing to work, when I have tuits (I get
them now and 
again).  If there's a need and someone willing to
coach...


   


		
__ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 


 

Clinton,
What kind of knowledge are you looking for?
How would you want to rewrite the Parrot BASIC compiler? in C or in PIR?
Depending on the level of knowledge you need, I could help you (I know a 
bit about parsers, I think :-)

(I've been trying a lot to implement a Lua compiler (version 5), but I'm 
seriously stuck on generating code for assignments (it's not as simple 
as it seems, but then again, I may be thinking in the wrong direction; 
for that I need either an implementation example (doesn't do Perl do 
multiple assignments? (i.e. a, b, c = c, b, a) , but that's another story).)

Anyway, could you describe what you would need? Maybe I can help.
regards,
klaas-jan
 

Re: Another issue with pdd03

[Leopold Toetsch]

Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Jeff Clites <[EMAIL PROTECTED]> wrote:

>> But that loops back to a previous proposal of mine: If they're not
>> being preserved, and in fact need to be "synced" between caller and
>> callee, then having these registers physically located in the
>> interpreter structure, rather than in the bp-referenced frame, saves
>> all the copying, and makes it more obvious what's going on.

> Well I answered that already. Having two distinct addressing schemes for
> volatile and non-volatile registers has a serious overhead for
> non-prederefed run cores.

Err, for all but unrolled run-cores (i.e only JIT could cope with it).
For prederefed cores all OUT arguments would need duplication, IN
arguments, which have usually a constant addressing too would use the
addressing of the constants for the volatiles.
CGoto and plain function core would grow towards insanity.

> ... OTOH in the light of a recent discussion this
> approach could be an alternative.

So not really, sorry.

>> JEff

leo

Re: Continuations, basic blocks, loops and register allocation

[Matt Fowles]

Dan~


On Tue, 16 Nov 2004 15:54:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:39 PM -0500 11/16/04, Matt Fowles wrote:
> 
> 
> >Dan~
> >
> >
> >On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >>  At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
> >>
> >>
> >>  >Dan~
> >>  >
> >>  >On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> 
> >> wrote:
> >>  >>  At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
> >>  >>  >The continuation preserves the frame (the mapping from logical
> >>  >>  >variables to their values), but not the values of those variables at
> >>  >>  >the time the continuation was created.
> >>  >>
> >>  >>  This is one of the fundamental properties of continuations, but it
> >>  >>  does throw people. And it's why register contents have to be thrown
> >>  >>  away when a continuation is invoked, since the registers have values,
> >>  >>  and continuations don't preserve values.
> >>  >
> >>  >I think right here we have the crux of my failure to understand.  I
> >>  >was/am under the impression that the continuation will restore the
> >>  >register frame to exactly as it was when the continuation was taken.
> >>  >Thus those registers which are values (I,N) will continue to have the
> >>  >value they had when the continuation was taken, while those registers
> >>  >which are pointers/references (S, P) will still point to the same
> >>  >place, but that data may have changed.  Is this correct?
> >>
> >>  No. The registers are just about the only thing that *isn't* restored.
> >>
> >>  Continuations put the environment back. This includes things like the
> >>  lexical pad stack, the namespace stack, the stack itself, any
> >>  security credentials... basically everything that describes the
> >>  environment. *Data*, on the other hand, is *not* restored. Data stays
> >>  as it is.
> >>
> >>  Registers are a special case of data, and they're just declared crud
> >>  by fiat, since otherwise things get nasty and unpredictable.
> >
> >Then I am not sure what you mean by "The return continuation PMC type,
> >used to create return continuations used for call/return style
> >programming, guarantees that registers 16-31 will be set such that the
> >contents of those registers are identical to the content of the
> >registers when the return continuation was I."
> >
> >I read that as saying that registers will be restored by
> >continuations.  If that is not what it is intended to mean, could you
> >clarify for me.
> 
> Return continuations are special, basically. There are a number of
> specialized continuation forms, and this is one of 'em. Which makes
> things a bit more confusing but, well, there you go.

It seems to me that it would simpilify much of the code, and reduce
the number of special cases if we extended that to all continuations
instead of just return ones.  This would allow the register allocator
to re-use registers as it chose without having to refetch everything
from backing store (which is rather problematic for non-PMC
registers).

This does mean that if an N register wants to have its value change
across continuations it needs to have a backing store somewhere, but
even without this change things need to be fetched from backing store
as the register allocator might clobber them.  So this does not seem
like a burden in that case, and it does seem like a win for the
allocator.

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

Re: Continuations, basic blocks, loops and register allocation

[Dan Sugalski]

At 4:10 PM -0500 11/16/04, Matt Fowles wrote:
Dan~
On Tue, 16 Nov 2004 15:54:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 At 3:39 PM -0500 11/16/04, Matt Fowles wrote:
 >Dan~
 >
 >
 >On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 >>  At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
 >>
 >>
 >>  >Dan~
 >>  >
 >>  >On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
 >>  >>  At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
 >>  >>  >The continuation preserves the frame (the mapping from logical
 >>  >>  >variables to their values), but not the values of those 
variables at
 >>  >>  >the time the continuation was created.
 >>  >>
 >>  >>  This is one of the fundamental properties of continuations, but it
 >>  >>  does throw people. And it's why register contents have to be thrown
 >>  >>  away when a continuation is invoked, since the registers 
have values,
 >>  >>  and continuations don't preserve values.
 >>  >
 >>  >I think right here we have the crux of my failure to understand.  I
 >>  >was/am under the impression that the continuation will restore the
 >>  >register frame to exactly as it was when the continuation was taken.
 >>  >Thus those registers which are values (I,N) will continue to have the
 >>  >value they had when the continuation was taken, while those registers
 >>  >which are pointers/references (S, P) will still point to the same
 >>  >place, but that data may have changed.  Is this correct?
 >>
 >>  No. The registers are just about the only thing that *isn't* restored.
 >>
 >>  Continuations put the environment back. This includes things like the
 >>  lexical pad stack, the namespace stack, the stack itself, any
 >>  security credentials... basically everything that describes the
 >>  environment. *Data*, on the other hand, is *not* restored. Data stays
 >>  as it is.
 >>
 >>  Registers are a special case of data, and they're just declared crud
 >>  by fiat, since otherwise things get nasty and unpredictable.
 >
 >Then I am not sure what you mean by "The return continuation PMC type,
 >used to create return continuations used for call/return style
 >programming, guarantees that registers 16-31 will be set such that the
 >contents of those registers are identical to the content of the
 >registers when the return continuation was I."
 >
 >I read that as saying that registers will be restored by
 >continuations.  If that is not what it is intended to mean, could you
 >clarify for me.

 Return continuations are special, basically. There are a number of
 specialized continuation forms, and this is one of 'em. Which makes
 things a bit more confusing but, well, there you go.
It seems to me that it would simpilify much of the code, and reduce
the number of special cases if we extended that to all continuations
instead of just return ones.
We could, but it would be wrong. Hell, it's arguably wrong for return 
continuations to do so, and it wouldn't be unreasonable to argue that 
I and N register contents are guaranteed crud and required refetching.

I'm not particularly concerned with pressure on the register 
allocator, honestly -- it's a pleasant add-on, and one we will 
continue to do, but it's not strictly necessary. We deal with that 
after we get things correct.
--
Dan

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

parakeet broken?

[Jeff Horwitz]

i was starting to play with parakeet, but unfortunately it keeps dying on
me.  this is from a cvs checkout from today:

0> 4 4 +
Null PMC access in get_pmc_keyed_int()

and this:

0> func hello "hi!" println end
0> hello
Null PMC access in push_pmc()

any clues?

thanks,
-jeff

Re: Continuations, basic blocks, loops and register allocation

[Matt Fowles]

Dan~


On Tue, 16 Nov 2004 16:24:06 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We could, but it would be wrong. Hell, it's arguably wrong for return
> continuations to do so, and it wouldn't be unreasonable to argue that
> I and N register contents are guaranteed crud and required refetching.
> 
> I'm not particularly concerned with pressure on the register
> allocator, honestly -- it's a pleasant add-on, and one we will
> continue to do, but it's not strictly necessary. We deal with that
> after we get things correct.

I can accept this, but I would like to make sure that I understand all
of the represcussions of it.  Thus you can consider all of the
following questions (even though they will be phrased as statements).

1)  After a full continuation is taken all of the registers must be
considered invalid.
2)  After a return continuation is taken, the registers can be trusted.
3)  If someone takes a full continuation, all return continuations
down the callstack must be promoted.
4)  After a function call, some magic needs to happen so that the code
knows whether it came back to itself via a return continuation and can
trust its registers, or it came back via a full continuation and
cannot trust them.

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

[perl #32466] [PATCH] Parrot m4 0.0.10 and "eval" changes

[via RT]

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


Hi,

this patch brings Parrot m4 to terms with recent "eval" changes. The compile
function of the 'eval' compiler now returns an Eval PMC. The m4 macro "eval"
is a simple interpreter of integer arithmetic expressions.

The 'eval' compiler returns a bytecode segment without a constant table. The
'destroy' of the Eval PMC needs to handle that.

The compiler for 'japh16' now emits a 'invoke P1' instead of an 'end'. 

There are new tests: 
  languages/m4/t/builtins/015___file__.t
  languages/m4/t/builtins/016___line__.t
  languages/m4/t/builtins/017_printerr.t

CU, Bernhard

-- 
/* [EMAIL PROTECTED] */

NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergïnstigen Komplett-Preis!

Parrot_m4-0.0.10.patch
Description: Binary data

Re: Fwd: Re: Parrot BASIC

[Michael Walter]

On Tue, 16 Nov 2004 21:59:39 +0100, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
> (I've been trying a lot to implement a Lua compiler (version 5), but I'm
> seriously stuck on generating code for assignments (it's not as simple
> as it seems, but then again, I may be thinking in the wrong direction;
> for that I need either an implementation example (doesn't do Perl do
> multiple assignments? (i.e. a, b, c = c, b, a) , but that's another story).)
I've no idea, but Python does.
  a, b, c = c, b, a
<=>
  (a, b, c) = (c, b, a)

What's the matter exactly (maybe we should continue that off-list)?

Cheers,
Michael

cvs access?

[Michel Pelletier]

Hi all, I have created a perl.org account in order to access the parakeet 
directory in cvs.  My perl.org user name is "michel" (how'd I score that 
one?).  Is this the right list to ask someone to give me the property 
credentials?

TIA,

-Michel