In message <20010920190703.S28291@blackrider>
Michael G. Schwern <[EMAIL PROTECTED]> wrote:
> I'm getting 2.67 MIPS with -O3.
>
> Hmmm, why would a K6/200 come out so much faster than a G3/266? If
> anything it should be the other way around.
No idea I'm afraid. I've just clocked 42.86
On Thu, 20 Sep 2001, Brent Dax wrote:
>Mattia Barbon:
># Automated smoke report for patch Sep 20 00:00:02 2001
># v0.01 on MSWin32 using cl version
>...
># MSWin32 --defaults --define iv=int --define nv=float
># MSWin32 --debugging --defaults --define iv=int --define n
not ok 15 - gt_nc_ic
# Failed test (Parrot/Test.pm at line 74)
# got: undef
# expected: 'ok 1
ok 2
ok 3
'
So Test::Harenss keeps whining about test 2 answrd ( yes, the PC
with the brokn keyboard again ) after test 9, and such.
Could output be changed to anyting else?
Thanks
Mat
On Fri, Sep 21, 2001 at 02:50:45AM +0200, Mattia Barbon wrote:
> Parrot::Smoke 0.01 has just been released.
> It works on Win2k and Linux, but it should work
> in most Unices.
This is very cool! Thank you very much.
--
Putting heated bricks close to the news.admin.net-abuse.* groups.
--
On Thu, Sep 20, 2001 at 09:44:41PM -0700, Brent Dax wrote:
> Okay, this fixes the issues with changing your IV or NV size. It also
> provides an early warning if your C compiler settings aren't okay. I've
> also made the style of the code a little more consistent. I'm applying
> this, but I fig
Leon Brocard sent the following bits through the ether:
> Attached are trivial comment fixes for two files.
Oh go on, I know we're in a feature freeze but this is a doc
patch. Can someone apply these please?
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware..
On Fri, Sep 21, 2001 at 10:18:31AM +0100, Leon Brocard wrote:
> Leon Brocard sent the following bits through the ether:
>
> > Attached are trivial comment fixes for two files.
>
> Oh go on, I know we're in a feature freeze but this is a doc
> patch. Can someone apply these please?
Doc patches a
Simon Cozens:
# On Thu, Sep 20, 2001 at 09:44:41PM -0700, Brent Dax wrote:
# > Okay, this fixes the issues with changing your IV or NV
# size. It also
# > provides an early warning if your C compiler settings
# aren't okay. I've
# > also made the style of the code a little more consistent.
# I'm
why is :
make test_prog
instead of just
make
=
iVAN
[EMAIL PROTECTED]
=
It is gcc 2.95.2, not 2.8.1
*SMACK* to anyone kept the perl scripts
compatible with perl 5.004_04
Regards
Mattia
P.S.: Suggstions about how to make report lins shorter
*VERY* welcome
-- Forwarded message --
Automated smoke report for patch Sep 21 07:00:01 2001 UTC
On Fri 21 Sep 2001 11:45, Mattia Barbon <[EMAIL PROTECTED]> wrote:
> It is gcc 2.95.2, not 2.8.1
> *SMACK* to anyone kept the perl scripts
> compatible with perl 5.004_04
>
> Regards
> Mattia
>
> P.S.: Suggstions about how to make report lins shorter
> *VERY* welcome
Start with stripping
> 'C:Perinperl.exe' is not recognized as an internal or external command,
> operable program or batch file.
Apply this for the C:Perinperl.exe problem
Sorry for the inconvenience.
Mattia
Index: Parrot/Test.pm
===
RCS file: /ho
Dan --
> Just a reminder--function names shouldn't exceed 31 characters. The C
> standard doesn't guarantee anything past that...
Using this simplistic program I found two names greater than 31 chars.
I don't know if there are names not fitting the little regexp used here,
but of those that do,
All --
I want to commit some bug fixes and new features for Jako. Given the
freeze, though, I want to make sure that if I do it, nobody is
depending upon jakoc as anything other than an illustration for now.
It works great here (much better than the current CVS version), and
will probably work gr
All --
Has anyone else out there tinkered with Jako examples? I'd like to
see examples or example ideas/sketches. I'd especially like to see
examples showing something you think jakoc should understand, but
doesn't.
Things I know I need to work on:
* Get the math ops, etc. working as built-in
Using the current CVS source with perl5.6.1, the assembler runs with the
following warning:
Use of uninitialized value in numeric eq (==) at assemble.pl line 53.
53 if (($] >= 5.006) && ($PConfig{ivsize} == $PConfig{longsize}) ) {
54 %pack_type = ('i'=>'l!','n'=>'d');
55 }
I
Leon Brocard added the first examples to the brand new Parrot
site. :-) (the first page is just http://dev.perl.org/perl6/code -
sometime in this weekend I'll probably get it moved around so
dev.perl.org just references parrotcode for Parrot information).
http://www.parrotcode.org/examples/
-
I've been following the stack vs register machine thread. If you haven't
seen this:
http://www-2.cs.cmu.edu/~koopman/stack_computers/
it does a reasonable job at presenting the pros/cons of many stack-based
architectures.
Anyway, thought it might be useful.
-dave
On Fri, 21 Sep 2001, Jason Gloudon wrote:
>
> Using the current CVS source with perl5.6.1, the assembler runs with the
> following warning:
>
> Use of uninitialized value in numeric eq (==) at assemble.pl line 53.
>
> 53 if (($] >= 5.006) && ($PConfig{ivsize} == $PConfig{longsize}) ) {
>
Attached is a patch to actually make dec_n_nc do what it should.
(Also included is a minor doc patch which I've previously sent but
which hasn't yet been applied ;-)
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware...http://www.nanoware
On Fri 21 Sep 2001 12:04, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
> On Fri 21 Sep 2001 11:45, Mattia Barbon <[EMAIL PROTECTED]> wrote:
> > It is gcc 2.95.2, not 2.8.1
> > *SMACK* to anyone kept the perl scripts
> > compatible with perl 5.004_04
> >
> > Regards
> > Mattia
> >
> > P.S.: Suggst
At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
>Stefan Dragnev:
># - $c{cc_denug} = ' ';
># + $c{cc_debug} = ' ';
>
>So *that*'s why -g kept appearing...thanks, applied.
Don't forget that debugging isn't always -g. (It's /DEBUG for me on VMS)
Da
At 09:37 AM 9/21/2001 -0400, Gregor N. Purdy wrote:
>The names are unique in the first 31 chars. Are we OK, or do I need
>to mangle the names? I could mangle them by doing one of the following:
Try choosing something smaller. (If for no other reason than I don't want
to have to type that long a
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 09:37 AM 9/21/2001 -0400, Gregor N. Purdy wrote:
>> The names are unique in the first 31 chars. Are we OK, or do I need
>> to mangle the names? I could mangle them by doing one of the following:
DS> Try choosing something smal
At 13:16 on 09/21/2001 EDT, Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> At 09:37 AM 9/21/2001 -0400, Gregor N. Purdy wrote:
> >> The names are unique in the first 31 chars. Are we OK, or do I need
> >> to mangle the names? I could
At 01:21 PM 9/21/2001 -0400, Gregor N. Purdy wrote:
>I've continued to play with the DO_OP simplification patch I posted
>before.
Looks good, at least as far as I can tell from the diff. Go ahead and apply
it, and I'll probably tweak from there.
Dan
On Fri, Sep 21, 2001 at 01:21:28PM -0400, Gregor N. Purdy wrote:
> I've continued to play with the DO_OP simplification patch I posted
> before. I've removed the op info stuff from the op func struct per
> suggestions from Dan.
Very nice, but can I remind you and everyone else that we're trying
t
Here's something for someone looking to do something interesting while the
code freeze is on.
Write yourself a program that takes a .pasm file and, rather than spitting
out bytecode, spits out the bodies of the opcode functions with the
appropriate replacements done on the parameters. The outp
At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>[I'm behind on my mail :-)]
>
>On Wed, 12 Sep 2001 13:19:40 -0400, Dan Sugalski wrote:
>
> >We're trying to align to a power-of-two boundary, and mask is set to
> >chop off the low bits, not the high ones. It should be something like:
> >
> >11
On Fri, Sep 21, 2001 at 11:05:29AM +0200, Mattia Barbon wrote:
> not ok 15 - gt_nc_ic
> # Failed test (Parrot/Test.pm at line 74)
> # got: undef
> # expected: 'ok 1
> ok 2
> ok 3
> '
>
> So Test::Harenss keeps whining about test 2 answrd ( yes, the PC
> with the brokn keyboard ag
Simon --
> > I've continued to play with the DO_OP simplification patch I posted
> > before. I've removed the op info stuff from the op func struct per
> > suggestions from Dan.
>
> Very nice,
Thanks!
> but can I remind you and everyone else that we're trying
> to get it working before we get
Dan --
> >I've continued to play with the DO_OP simplification patch I posted
> >before.
>
> Looks good, at least as far as I can tell from the diff.
Thanks!
> Go ahead and apply it, and I'll probably tweak from there.
I'd love to do that, but Simon is (understandably) hesitant to
have non-bu
At 09:07 PM 9/20/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>
> DS> There probably won't be any. The current thinking is that since
> DS> the ops themselves will be a lot smaller, we'll have an explicit
> DS> event checking op that the compiler
On Fri, 21 Sep 2001, Simon Cozens wrote:
> Very nice, but can I remind you and everyone else that we're trying
> to get it working before we get it pretty?
Apropos, here's what I get on Solaris 8 (my default perl there has
iv='long long', so that's what we get here too):
/opt/perl-trial/bin/per
Question. It seems to me that the current do-loop:
while(code > x && code < y && *code) { DO_OP }
Is fail-fast and succeed-slow. I know it has a brother:
"while(*code)", but this could lead to seg-faults, especially if we allow
dynamically modified parsers / compilers.
The first method has an
On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> Doing this by hand with -O3, you can see a speedup of around a factor of 45
> over an unoptimised runops loop, so it's definitely worth doing in some
> cases...
Cool! Parrot JIT!
But that tells us *just* how time-consuming our ru
On Fri, 21 Sep 2001, Simon Cozens wrote:
> Very nice, but can I remind you and everyone else that we're trying
> to get it working before we get it pretty?
Apropos, here's what I get on Debian Sparc/Linux (my default perl there
has iv='long long', so that's what we get here too). Note that near
At 02:48 PM 9/21/2001 -0400, Michael Maraist wrote:
>Question. It seems to me that the current do-loop:
> while(code > x && code < y && *code) { DO_OP }
>
>Is fail-fast and succeed-slow. I know it has a brother:
> "while(*code)", but this could lead to seg-faults, especially if we allow
>dynami
At 02:43 PM 9/21/2001 -0400, Gregor N. Purdy wrote:
>Dan --
>
> > Go ahead and apply it, and I'll probably tweak from there.
>
>I'd love to do that, but Simon is (understandably) hesitant to
>have non-bugfix commits right now.
I saw that. Simon's the Code Guy, so what he says goes here. It can wa
At 07:41 PM 9/21/2001 +0100, Simon Cozens wrote:
>On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> > Doing this by hand with -O3, you can see a speedup of around a factor
> of 45
> > over an unoptimised runops loop, so it's definitely worth doing in some
> > cases...
>
>Cool! Parro
This is never set, although it is (indirectly) tested for. Here's
a patch.
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.14
diff -u -r1.14 Configure.pl
--- Configure.pl2001/09/21
Could you have another go with the configure patch I just sent?
*Might* help, and even if it doesn't, it puts us on a level
playing-field.
Tru64's fine, apart from this crap:
t/op/number.dubious
Test returned status 7 (wstat 1792, 0x700)
DIED. FAILED tests 1, 7, 9, 11, 13, 15, 17
Simon Cozens:
# This is never set, although it is (indirectly) tested for. Here's
# a patch.
#
# (@c{qw(ivsize opsize nvsize)})=split('/', `./test$c{exe}`);
# +$c{longsize} = $c{opsize};
Actually, that middle one *should* be longsize, not opsize. That was
from before I realized what longsize wa
I've just checked this in because the disassembler has come adrift
from the assembler. I don't know if this is the right fix, because
it feels like a hack, but it seems to work well enough for me to
debug some failing tests.
Index: disassemble.pl
==
Simon Cozens writes:
> I've just checked this in because the disassembler has come adrift
> from the assembler. I don't know if this is the right fix, because
> it feels like a hack, but it seems to work well enough for me to
> debug some failing tests.
Maybe one of the tests should be to disasse
Dan Sugalski:
# At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
# >Stefan Dragnev:
# ># - $c{cc_denug} = ' ';
# ># + $c{cc_debug} = ' ';
# >
# >So *that*'s why -g kept appearing...thanks, applied.
#
# Don't forget that debugging isn't always -g. (It's /DEBUG for
# me on VMS)
That sort o
On Fri, 21 Sep 2001, Simon Cozens wrote:
> Could you have another go with the configure patch I just sent?
> *Might* help, and even if it doesn't, it puts us on a level
> playing-field.
Sorry, no, difference.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayet
At 12:45 PM 9/21/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
># At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
># >Stefan Dragnev:
># ># - $c{cc_denug} = ' ';
># ># + $c{cc_debug} = ' ';
># >
># >So *that*'s why -g kept appearing...thanks, applied.
>#
># Don't forget that debugging isn'
Brent Dax wrote:
>
> Dan Sugalski:
> # At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
> # >Stefan Dragnev:
> # ># - $c{cc_denug} = ' ';
> # ># + $c{cc_debug} = ' ';
> # >
> # >So *that*'s why -g kept appearing...thanks, applied.
> #
> # Don't forget that debugging isn't always -g. (It'
Brad Hughes:
# Brent Dax wrote:
# >
# > Dan Sugalski:
# > # At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
# > # >Stefan Dragnev:
# > # ># - $c{cc_denug} = ' ';
# > # ># + $c{cc_debug} = ' ';
# > # >
# > # >So *that*'s why -g kept appearing...thanks, applied.
# > #
# > # Don't forget t
Dan --
> Write yourself a program that takes a .pasm file and, rather than spitting
> out bytecode, spits out the bodies of the opcode functions with the
> appropriate replacements done on the parameters. The output should be
> suitable for stuffing into the guts of test_main.c in the place of
On Fri, Sep 21, 2001 at 03:52:52PM -0400, Gregor N. Purdy wrote:
> OK. I'm tinkering with this a bit, but I've tripped over what appears to
> be a bug somewhere in the PackFile::* classes.
You too, eh? I think it would be a VERY good idea to have the configure
process spit out a module containin
Simon Cozens:
# +if (($] >= 5.006) && ($PConfig{ivsize} == $PConfig{longsize}) ) {
The version check is no longer necessary, since Configure.pl now detects
longsize itself.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
Mattia Barbon:
# > 'C:Perinperl.exe' is not recognized as an internal or
# external command,
# > operable program or batch file.
# Apply this for the C:Perinperl.exe problem
#
# - system "$^X -e \"$redir_string;system qq{$command};\"";
# + system "$^X -e \"$redir_string;system q{$command};\
> On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> > Doing this by hand with -O3, you can see a speedup of around a factor of 45
> > over an unoptimised runops loop, so it's definitely worth doing in some
> > cases...
>
> Cool! Parrot JIT!
>
> But that tells us *just* how time-cons
At 04:32 PM 9/21/2001 -0400, Michael Maraist wrote:
>Either way, branching can be reduced by a clustering a sequence of
>regularly used-ops together into macro-ops.
Congrats, you've uncovered another hidden reason for the preprocessed
opcode functions. :)
The intention is that we'll be able to
Dan --
> Here's something for someone looking to do something interesting while the
> code freeze is on.
>
> Write yourself a program that takes a .pasm file and, rather than spitting
> out bytecode, spits out the bodies of the opcode functions with the
> appropriate replacements done on the
Gregor N. Purdy:
# Dan --
#
# > Here's something for someone looking to do something
# interesting while the
# > code freeze is on.
# >
# > Write yourself a program that takes a .pasm file and,
# rather than spitting
# > out bytecode, spits out the bodies of the opcode functions with the
# > appro
All --
> My first cut is pretty sloppy, but it does generate this C file, which
> compiles, but I don't have the time to figure out how to get it all the
> stuff it needs to link to. If someones gets it running, I'd like to see
> how many Mops they get vs. regular.
BTW, I realized as I left the
Brent --
> # My first cut is pretty sloppy, but it does generate this C file, which
> # compiles, but I don't have the time to figure out how to get
> # it all the
> # stuff it needs to link to. If someones gets it running, I'd
>
> Parrot::Config may come in handy, especially @PConfig{qw(cc ccf
All --
> Chances are good that you were at least having trouble do to the string
> constants not being loaded into the interpreter (I pointed this problem
> out a few minutes ago in a related message). Perhaps getting those
> string-constant-loading statements in there as directed earlier would
61 matches
Mail list logo
