David M. Lloyd wrote:
> Take it from me (the one with several abortive attempts at getting an
> extra compare stuck in Perl 5's dispatch loop): You don't want to stick
> another compare in there. It *kills* performance.
Kills? I thought the event flag test dropped performance by a few
percent.
> On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
> > Actually the ops=>C conversion was conceived to do exactly what's being
> > done now--to abstract out the body of the opcodes so that they could be
> > turned into a switch, or turned into generated machine code, or TIL'd. If
> >
On Sat, 22 Sep 2001, Ken Fox wrote:
> I've been thinking about the possibility of building a higher-level
> VM. The current VM is very close to a traditional CPU. What if we did
> something non-traditional that made implementing higher-level
> lexically scoped languages easier?
> I'm proposing:
On 22 Sep 2001, Ask Bjoern Hansen wrote:
> [EMAIL PROTECTED] (Dan Sugalski) writes:
>
> > I've got a mac suitable for setting up as a test platform for parrot
> > now, courtesy of Grant. Does anyone have any connections with Apple?
> > I'd like to see about getting an OS X server license for it
Here's what I use ...
#!/usr/bin/perl -w
# parrot - compile and run parrot assembly language
$srcfile = shift or die "usage: $0 PASMFILE\n";
($pbcfile = $srcfile) =~ s{\.pasm$}{.pbc}i;
system("perl assemble.pl $srcfile > $pbcfile && ./test_prog $pbcfile");
--
On Sunday 23 September 2001 01:12, Michael G Schwern wrote:
[...]
> Beowulf, iPAQ on Alpha, x86 and even ARM.
[...]
:)
bash-2.05$ uname -a
Linux ipaq 2.4.3-rmk2-np1 #2 Mon May 14 12:21:48 PDT 2001 armv4l unknown
bash-2.05$ ./assemble.pl t/test.pasm > t/test.pbc
bash-2.05$ ./test_prog t/test.pb
I wrote some tests today...
1) captured error output, so can test errors, this might be bad, not sure.
2) basic tests for register stack frames, including some errors
3) I think we can stop skipping one of the string tests
4) I added some more substr tests, but substr was broken, so
5) changed su
I've been thinking about the possibility of building a higher-level
VM. The current VM is very close to a traditional CPU. What if we
did something non-traditional that made implementing higher-level
lexically scoped languages easier?
What if the VM (and assembler) had lexical scoping built-in at
Some tests for stack operations, pushing and popping, except
for pmcs. Suggest: t/op/stacks.t
Alex Gough
--
Hatred is the coward's revenge for being intimidated.
#
#! perl -w
# Tests for stack operations, currently push_*, push_*_c and pop_*
# where * != p.
# Assembler code is parti
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
> Actually the ops=>C conversion was conceived to do exactly what's being
> done now--to abstract out the body of the opcodes so that they could be
> turned into a switch, or turned into generated machine code, or TIL'd. If
> you're
[EMAIL PROTECTED] (Dan Sugalski) writes:
> I've got a mac suitable for setting up as a test platform for parrot
> now, courtesy of Grant. Does anyone have any connections with Apple?
> I'd like to see about getting an OS X server license for it so we
> can do automated smoke testing and suchlike
[EMAIL PROTECTED] (Leon Brocard) writes:
[...]
> Attached is a trivial patch which adds a newline.
I've put that in CVS. I also renamed the 'test' executable we make to
test_siz (just because using "test" on a unix system is bad karma).
- ask
--
ask bjoern hansen, http://ask.netcetera.dk
I don't remember if this has already been experimented with; I've
lost track of what the previous sets of benchmarks were for. I was
curious to see how much faster a single-function switch based interpreter
would go. I took process_opfunc.pl and created process_opfunc_switch.pl
which do
On Sat, Sep 22, 2001 at 07:12:05PM -0400, Michael G Schwern wrote:
> Compaq has a program called "Testdrive" where they offer free accounts
> on a VERY wide range of machines & OS's. Tru64, Caldera, Debian,
> Redhat, Kondara, OpenVMS, Mandrake, SuSE, Turbo, NetBSD, FreeBSD,
> Beowulf, iPAQ on Alp
On Saturday 22 September 2001 07:33 pm, Simon Cozens wrote:
> On Sat, Sep 22, 2001 at 04:41:28PM -0700, Benjamin Stuhl wrote:
> > at load time. Yes, it's slow and hackish, but strings are
> > the only *portable* format for floating-point numbers
>
> I thought (although I might have conveniently fo
On Sat, 22 Sep 2001, Benjamin Stuhl wrote:
> --- Simon Cozens <[EMAIL PROTECTED]> wrote:
> > On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko
> > Hietaniemi wrote:
> > > unaligned access
> >
> > Bother. It is as I feared.
> >
> > Dan, we need to do something about this. The choices are:
> > pu
On Sat, Sep 22, 2001 at 04:41:28PM -0700, Benjamin Stuhl wrote:
> at load time. Yes, it's slow and hackish, but strings are
> the only *portable* format for floating-point numbers
I thought (although I might have conveniently forgotten the other
side of the argument:) that we weren't that concern
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko
> Hietaniemi wrote:
> > unaligned access
>
> Bother. It is as I feared.
>
> Dan, we need to do something about this. The choices are:
> put floats into the
> constant section, or ensure instructions a
On Sun, 23 Sep 2001, Simon Cozens wrote:
> On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko Hietaniemi wrote:
> > unaligned access
>
> Bother. It is as I feared.
>
> Dan, we need to do something about this. The choices are: put floats into the
> constant section, or ensure instructions are ass
On Saturday 22 September 2001 07:21 pm, Simon Cozens wrote:
> On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko Hietaniemi wrote:
> > unaligned access
>
> Bother. It is as I feared.
>
> Dan, we need to do something about this. The choices are: put floats into
> the constant section, or ensure instr
On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko Hietaniemi wrote:
> unaligned access
Bother. It is as I feared.
Dan, we need to do something about this. The choices are: put floats into the
constant section, or ensure instructions are assigned on an appropriate
boundary. I can see pros and con
[Sorry if this is a duplicate. I sent the original from work.
Is there a spam filter removing messages from non-subscribers?]
I've been thinking about the possibility of building a higher-level
VM. The current VM is very close to a traditional CPU. What if we
did something non-traditional that m
> On this machine, NVs are doubles; their pack_type is 'd', which is
> as it should be. So, a number (2.0) is inserted into the bytecode
> stream with pack('d', 2.0)
./perl -Ilib -MDevel::Peek -le 'Dump(pack("d",2))'
SV = PV(0x1d9ed4) at 0x1e4568
REFCNT = 1
FLAGS = (PADTMP,POK,pPOK)
PV = 0x
> On Sun, Sep 23, 2001 at 12:27:53AM +0200, Mattia Barbon wrote:
> > [parrpt]$ perl Configure.pl --defaults --define cc=gcc --define
> > ccflags="-O3 -Iinclude" --define iv=long --define nv=double
> > [parrot]$ make
> > [parrot]$ for i in t/op/number*.pbc ; do ./test_prog $i; done
>
> Whoa - did
> cvsuser 01/09/22 10:20:59
>
> Modified:.Makefile.in
> Added: Test More.pm Simple.pm Utils.pm
> Log:
> I'm sick of having to install Test::More everywhere. Temporary measure
> until we remove this silly dependency.
I promise I'll do it after 0.02 is out.
Matt
I've found the bug on Linux Sparc; This is either a bug in Parrot, or a bug in
Perl, and I can't tell which.
On this machine, NVs are doubles; their pack_type is 'd', which is as it should
be. So, a number (2.0) is inserted into the bytecode stream with pack('d', 2.0)
However, when I try derefer
On Sun, Sep 23, 2001 at 12:27:53AM +0200, Mattia Barbon wrote:
> [parrpt]$ perl Configure.pl --defaults --define cc=gcc --define
> ccflags="-O3 -Iinclude" --define iv=long --define nv=double
> [parrot]$ make
> [parrot]$ for i in t/op/number*.pbc ; do ./test_prog $i; done
Whoa - did you re-assemb
the t/op/trans failures are because the test
returns no output
( runnig by hand
[parrpt]$ perl Configure.pl --defaults --define cc=gcc --define
ccflags="-O3 -Iinclude" --define iv=long --define nv=double
[parrot]$ make
[parrot]$ for i in t/op/number*.pbc ; do ./test_prog $i; done
Segmentation fau
GRRR... always use reply yo all...
--- Forwarded message follows ---
From: Mattia Barbon <[EMAIL PROTECTED]>
To: Simon Cozens <[EMAIL PROTECTED]>
Subject:Re: Tru64 Numeric bug exposed!
Copies to: [EMAIL PROTECTED], [EMAIL
On Saturday 22 September 2001 04:05 pm, Leon Brocard wrote:
> Attached patch makes sure you don't try and use register numbers over
> 31. That is, this patch allows registers I0-I31 and anything else gets
> a: Error (foo.pasm:0): Register 32 out of range (should be 0-31) in
> 'set_i_ic'
>
Except
On Sat, Sep 22, 2001 at 09:05:53PM +0100, Leon Brocard wrote:
> Attached patch makes sure you don't try and use register numbers over
> 31. That is, this patch allows registers I0-I31 and anything else gets
> a: Error (foo.pasm:0): Register 32 out of range (should be 0-31) in 'set_i_ic'
Applied,
Attached patch makes sure you don't try and use register numbers over
31. That is, this patch allows registers I0-I31 and anything else gets
a: Error (foo.pasm:0): Register 32 out of range (should be 0-31) in 'set_i_ic'
Oh, there's also a comment at end of line patch that has snuck in 'cos
it's s
On Sat, 22 Sep 2001, raptor wrote:
> hi,
>
> is it possible the ops to handle variable number of arguments, what I have
> in mind :
>
> print I1,",",N2,"\n"
This could probably be done as a macro when the assembler has macro
support in the future.
For now, the Jako Compiler converts:
va
At 07:09 PM 9/22/2001 +0300, raptor wrote:
>hi,
>
>is it possible the ops to handle variable number of arguments
No.
Which isn't to say that if you do:
new P0, list
push P0, "A "
push P0, "multipart "
push P0, "string"
push P0, "\n"
print P0
you won't get "A multipart string"
hi,
is it possible the ops to handle variable number of arguments, what I have
in mind :
print I1,",",N2,"\n"
cheers
=
iVAN
[EMAIL PROTECTED]
=
So there I was, reading my Dragon book again and thinking about
optimising Parrot bytecode. I took disassemble.pl, hacked it to
actually output source code that might compile, and gave it some
knowledge about operators, basic blocks, and flow graphs. And hooked
it up to Graphviz[1]. The code is re
what about adding "run" !
#!/usr/bin/perl -w
my ($pasm) = $ARGV[0] =~ /(.*?)\./;
system("./assemble.pl $ARGV[0] > $pasm.pbc ; ./test_prog $pasm.pbc");
cheers
=
iVAN
[EMAIL PROTECTED]
=
All --
> The missing code is going to look something like this:
> Next time I'm in front of my development machine, I'll give this a try.
> If this approach works, I'll work harder to produce a version of the
> solution that we can be proud of.
OK. I got it working. I'm attaching the compile.pl
At 07:40 PM 9/22/2001 +0300, Jarkko Hietaniemi wrote:
>On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
> > On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
> > > And now I know why! The branch-fixup section of the assembler's busted:
> >
> > No, that wasn't it. This is i
I've got a mac suitable for setting up as a test platform for parrot now,
courtesy of Grant. Does anyone have any connections with Apple? I'd like to
see about getting an OS X server license for it so we can do automated
smoke testing and suchlike things, but my budget, alas, doesn't have the
On Sat, Sep 22, 2001 at 05:45:12PM +0100, Simon Cozens wrote:
> Parrot's tests now run successfully on Tru64 and Linux.
That is, Linux x86. Linux Alpha just compiled successfully too.
--
sub UNIVERSAL::AUTOLOAD{ $UNIVERSAL::AUTOLOAD =~ s/::/ /; print
"$UNIVERSAL::AUTOLOAD "}; hacker perl anothe
On Fri, Sep 21, 2001 at 02:51:02PM -0400, Andy Dougherty wrote:
> I fear some sort of alignment or sizeof() issue is at work, and I'd hate
> to see whatever problems exist so far get widely propagated into other
> pieces of the source.
I've just cleaned up all the alignment and sizeof() issues fr
On Sat, Sep 22, 2001 at 04:33:31PM +0200, Mattia Barbon wrote:
> Before I spam everyone with this,
> is someone interested in it
I'm *very* interested in it.
> and if so,
> should I continue sending it to perl6-internals,
> or is is preferable a different ML?
For now, let's have them here. We c
On Sat, Sep 22, 2001 at 05:31:50PM +0100, Simon Cozens wrote:
> Unfortunately, I do not have the slightest idea why that is failing...
That's failing because the test is way bogus. Mattia, consider yourself
slapped - 4.61168601842739e+18 is only 4611686018427389952.00 on broken
platforms like
On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
> or is there a saner way to do it?
There is, and I've done it. (removed an assumption in process_opfunc.pl)
Jarkko, please resync; I think you'll find only one test now fails.
Unfortunately, I do not have the slightest idea why that i
On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
> On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
> > And now I know why! The branch-fixup section of the assembler's busted:
>
> No, that wasn't it. This is it:
>
> opcode_t *ne_nc_ic(opcode_t cur_opcode[], struct Parro
On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
> And now I know why! The branch-fixup section of the assembler's busted:
No, that wasn't it. This is it:
opcode_t *ne_nc_ic(opcode_t cur_opcode[], struct Parrot_Interp *interpreter) {
IV return_offset = 5;
if (NUM_REG(cur_opcode[
On Sat, Sep 22, 2001 at 04:37:00PM +0100, Simon Cozens wrote:
> Fixed. Parrot is now as broken as it was on Tru64 before I
> started messing with it
And now I know why! The branch-fixup section of the assembler's busted:
0030: branch_ic 0040
003c: print_sc [string 0001]
00
On Sat, Sep 22, 2001 at 03:56:09PM +0100, Simon Cozens wrote:
> I'm looking into it now.
Fixed. Parrot is now as broken as it was on Tru64 before I
started messing with it, but now it will also Do The Right
Thing when you change the internal types.
--
Asynchronous inputs are at the root of our
--- Forwarded message follows ---
Automated smoke report for patch Sep 22 13:00:00 2001 UTC
v0.01 on dec_osf using gcc version 2.95.2
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: -
I've just been fiddling around with the assembler and disassembler,
so that they use Gregor's PackFile modules. While this now means
that assembly and disassembly will Just Work seamlessly when we
change types and pack formats, it does look like I've broken something
on Tru64, or at least, expose
I'd be sending 3 smoke reports ( Win2k/MSVC, x86/Linux,
Alphs/Tru64/GCC ) per snapshot, and maybe I will
start on cygwin and Win2k/MinGW, too.
Before I spam everyone with this,
is someone interested in it, and if so,
should I continue sending it to perl6-internals,
or is is preferable a different
t/op/number.t is basically testing that
the rounding behaviour is the same across all
platforms. This is ***wrong***.
Regards
Mattia
--- Forwarded message follows ---
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject:Parrot Smoke S
This looks really nice...
Regards
Mattia
--- Forwarded message follows ---
Automated smoke report for patch Sep 22 07:00:00 2001 UTC
v0.01 on linux using cc version 2.95.2 2313 (Debian GNU/Linux)
O = OK
F = Failure(s), extended report at the bottom
? = still running
I get a warning during the Configure process:
...
Alright, now I'm gonna check some stuff by compiling and running
a small C program. This could take a bit...
test.c:13:1: warning: no newline at end of file
...
Attached is a trivial patch which adds a newline.
Leon
--
Leon Brocard...
55 matches
Mail list logo
