Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
> I must admit I am a little confused as to what the problem is. Given
> that any continuation which was originally created as a return
> continuation will restore its registers, all code which uses P/S
> registers will work as expected. Furthermore,
Justin DeVuyst <[EMAIL PROTECTED]> wrote:
> This patch will allow all the *.imc and *.pasm benchmarks to be
> tested by running make testbench.
Thanks, applied and sorry for the delay.
> There are currently two benchmarks ( hash-utf8.pasm and b6t.imc )
> that fail. The hash-utf8 one looks like
Sam Ruby wrote:
Michael Walter wrote:
Uh, C89 is an ANSI/ISO C.
I'm not enough of a language lawyer to know when various features came
into to the language, but
gcc -std=c89 test.c
does *NOT* warn about declaration ordering issues. At least not with
gcc version 3.3.4 (Debian 1:3.3.4-6sarge1)
[EMAIL PROTECTED] wrote:
I think we have basically 3 choices: support continuations such that
they work correctly in all HLL situations and accept likely poor
performance, or support only escape continuations, or devise a
strategy whereby Parrot itself doesn't provide continuations, but
allows
Timm Murray writes:
> I've always thought of Perl5 having two basic types: Scalar and List, with
> Hash and Array being subtypes of List. The reason is that arrays and hashes
> can be easily converted into each other, because of Perl5's list-flatening
> nature:
>
> @array = %hash;
> %hash = @a
Leopold Toetsch writes:
> > I think we have basically 3 choices: support continuations such that
> > they work correctly in all HLL situations and accept likely poor
> > performance, or support only escape continuations, or devise a strategy
> > whereby Parrot itself doesn't provide continuations,
I looked through google groups and couldn't find leo's solution
("putting lexicals in registers", and I can't figure out what that
means; couldn't you have a loop counter that isn't a lexical?).
I think we all agree that this is a major problem, and that to ignore it
would be a fatal mistake in Pa
Very embarrassing delurk just to say...
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
[hyuuuge snip]
> Perl6 syntax like "my int $i;" would need PMCs. Extracting an integer
> from an array that stores natural ints would need a PMC.
Someone please listen to this man! In my opinion, one of the b
And because of a message that came up very recently, I infer that leo's
solution involves a variable-sized register frame.
This sounds like a much better solution than the one I've just proposed.
No saving/restoring, the register frame size is known at compile time
(so the double-indirection can
On 3 Dec 2004, at 09:46, Luke Palmer wrote:
I looked through google groups and couldn't find leo's solution
("putting lexicals in registers", and I can't figure out what that
means; couldn't you have a loop counter that isn't a lexical?).
I believe its the first in the thread 'Lexicals, continuatio
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> 2) The assembler and PIR compiler need to be taught appropriate
> transforms
Any objections if I handled unary opcodes with constant arguments inside
IMCC? We have still opcodes like:
sin_n_nc# sin Nx, 3.14
The created code would be
set Nx,
Luke Palmer wrote:
Frankly I think, I've presented a way to make continuations work
correctly. I did *not* hear any technical or otherwise reasonable
argument that it wouldn't work or that it's untenable, nothing, nada.
Well, since I (and I'm sure many others) have been skipping over a lot
of messa
Klaas-Jan Stol wrote:
Sam Ruby wrote:
Michael Walter wrote:
Uh, C89 is an ANSI/ISO C.
I'm not enough of a language lawyer to know when various features came
into to the language, but
gcc -std=c89 test.c
does *NOT* warn about declaration ordering issues. At least not with
gcc version 3.3.4 (De
Leo~
On Fri, 3 Dec 2004 09:26:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Ok. I'll try to summarize, where I see the problem. No diagrams, just
> code :)
>
> [snip]
Thanks for the clear explanation. I did not realize that S registers
could switch pointers, that does make things a li
Leo~
On Fri, 3 Dec 2004 09:26:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Ok. I'll try to summarize, where I see the problem. No diagrams, just
> code :)
>
> [snip]
Thanks for the clear explanation. I did not realize that S registers
could switch pointers, that does make things a lit
Test case attached.
- Sam Ruby
Index: t/pmc/perlhash.t
===
RCS file: /cvs/public/parrot/t/pmc/perlhash.t,v
retrieving revision 1.48
diff -u -r1.48 perlhash.t
--- t/pmc/perlhash.t1 Oct 2004 21:16:52 - 1.48
+++ t/pmc/perlha
This patch fixes some warnings in global_setup.c and embed.c. All it
does is add some necessary includes to pick up function declarations and
constify a variable to avoid warnings about casting from const to
non-const, so it should be pretty safe to apply.
-garrett
Index: src/embed.c
=
17 matches
Mail list logo
