On Tue, Sep 11, 2001 at 10:23:51AM -0700, Daniel Sully wrote:
[Parrot coredumps on Solaris]
It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is
fine. The coredump doesn't show much, only that it keeled over at
interpreter.c line 16, which is the while() loop.
That was
On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
test3.pbc is still segfaulting on me though.
Yes, it is here too; I've sent some debugging info to Dan
and he's having a look at it. I'm trying to take a look at
it too. I suspect that CHUNK_BASE isn't doing what it should.
Simon
On Wed 12 Sep 2001 13:23, Nicholas Clark [EMAIL PROTECTED] wrote:
Can we usefully smoke parrots yet?
Or is this something that someone (Schwern?) is working on?
[in that as all the world is not a vax^Wx86 it would be useful to smoke on
obscure architectures that SIGBUS on unaligned integer
On Tue, Sep 11, 2001 at 04:19:12PM +0300, Jarkko Hietaniemi wrote:
P.S. Maybe the long term discussion should take place in
perl6-build, to draw fire from the short term?
Thanks for thinking about this; it'd probably be a good idea to
move to perl6-build.
Simon
At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote:
On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
test3.pbc is still segfaulting on me though.
Yes, it is here too; I've sent some debugging info to Dan
and he's having a look at it. I'm trying to take a look at
it too. I suspect
On Wed, Sep 12, 2001 at 09:24:06AM -0400, Dan Sugalski wrote:
At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote:
On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
test3.pbc is still segfaulting on me though.
Yes, it is here too; I've sent some debugging info to Dan
and he's
At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
On Wed, Sep 12, 2001 at 09:24:06AM -0400, Dan Sugalski wrote:
At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote:
On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
test3.pbc is still segfaulting on me though.
Yes, it is
On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote:
At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
On Wed, Sep 12, 2001 at 09:24:06AM -0400, Dan Sugalski wrote:
CHUNK_BASE was OK, it was Allocate_Aligned that was broken. That and the
problems with the assembler generating
I just checked PDD 6 into CVS. (parrot/docs/parrot_assembly.pod) Some
changes since last time, so check it out to see what's up.
Dan
--it's like this---
Dan Sugalski even
Now works on Solaris and i386, but segfaults at the GRAB_IV call in
read_constants_table on my Alpha. Problems with the integer-pointer
conversions in memory.c? (line 29 is giving me a warning).
The line 29 is extremely wrong. It assigns IV to void* without casting.
The alignment calculation
I just ran purify against the current Parrot CVS as of today at 10 AM PDT.
Here are the results:
jwilmes@jwilmes-sun:/apps/users/jwilmes/devel/parrot$ ./test_prog test.pbc
Purify instrumented test_prog (pid 2187 at Wed Sep 12 10:05:34 2001)
* Purify 5.2 Solaris 2 (32-bit), Copyright
At 09:57 AM 9/12/2001 -0700, Hong Zhang wrote:
Now works on Solaris and i386, but segfaults at the GRAB_IV call in
read_constants_table on my Alpha. Problems with the integer-pointer
conversions in memory.c? (line 29 is giving me a warning).
The line 29 is extremely wrong. It assigns IV to
On Wed, Sep 12, 2001 at 02:54:49PM +0100, Philip Kendall wrote:
On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote:
At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
Now works on Solaris and i386, but segfaults at the GRAB_IV call in
read_constants_table on my Alpha. Problems
For those of you who're curious as to why performance is so bad, Parrot's
made Slashdot, and the CVS server's undoubtedly being slashdotted.
Dan
--it's like this---
Dan Sugalski
All --
This Makefile patch addes euclid.pasm to the make test target. Note
also that it redirects output to t/*.out, which other folks might not
agree with (I like it, given the amount of output generated for some
tests).
Regards,
-- Gregor
All --
The following .cvsignore file goes in the root parrot source code
directory to ignore the build products.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N.
All --
The attached t/.cvsignore file will cause cvs to ignore the products
of 'make test'.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy
All --
Should we do an MD5 on the opcode table and store that in the assembler,
assembler output, disassembler, and interpreter, so that the interpreter
won't even try to execute byte code assembed by an assembler with a
different opcode table? It seems to me that while things are developing
it
At 03:45 PM 9/12/2001 -0400, Gregor N. Purdy wrote:
Should we do an MD5 on the opcode table and store that in the assembler,
assembler output, disassembler, and interpreter, so that the interpreter
won't even try to execute byte code assembed by an assembler with a
different opcode table? It
The assembler patches:
* handle blank lines containing a label
* handle constants in decimal,octal, or hex.
Opcode table patch (and basic_opcodes.ops):
* adds and, or, not, xor, shl, and shr.
Builds ok, but coredumps in the interpreter. Any hints on what I
did
On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote:
[Coredumps on Alpha]
Quick research reveals the obvious problem: even when IVs are 64 bit,
assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
Changing this over to 'q' means I get further, but it's still
All --
Attached is a diff for assemble.pl that does a somewhat messy job of
solving the problem posed in the TODO file. It does it by parsing
the root of each opcode when parsing the opcode table and creating a
hash with the opcode root and the formal argument types (qualifiers)
so that, e.g.
At 10:17 PM 9/12/2001 +0100, Philip Kendall wrote:
On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote:
[Coredumps on Alpha]
Quick research reveals the obvious problem: even when IVs are 64 bit,
assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
Changing
All --
BTW, Here are some things to consider:
* The recognition of register types means that you can't use labels
like 'I4'. It would be nice if registers and labels were in
different namespaces.
Could label definitions be like this: FOO:, and label uses
be like this: :FOO?
At 05:36 PM 9/12/2001 -0400, Gregor N. Purdy wrote:
All --
BTW, Here are some things to consider:
* The recognition of register types means that you can't use labels
like 'I4'. It would be nice if registers and labels were in
different namespaces.
I don't think this is necessary.
In perl5, we've had occasional header file name conflicts over the
years. One common example is someone putting a file named config.h
in /usr/local/include. Other conflicts with string.h and memory.h
are also conceivable.
I'd suggest
cd parrot
mkdir include
mkdir
--- Andy Dougherty [EMAIL PROTECTED]
wrote:
In perl5, we've had occasional header file name conflicts
over the
years. One common example is someone putting a file
named config.h
in /usr/local/include. Other conflicts with string.h
and memory.h
are also conceivable.
I'd suggest
I hate to ask such a stupid question, but what is a power of two boundry and
why do we want it to be aligned on one? I was assuming a power of two
boundry to be some memory address N such that N = 2 ** i, but this
apparently is not the case. Sorry for asking such a rudimentary question,
but
At 03:59 PM 9/12/2001 -0700, Benjamin Stuhl wrote:
--- Andy Dougherty [EMAIL PROTECTED]
wrote:
In perl5, we've had occasional header file name conflicts
over the
years. One common example is someone putting a file
named config.h
in /usr/local/include. Other conflicts with string.h
At 06:11 PM 9/12/2001 -0500, Gibbs Tanton - tgibbs wrote:
I hate to ask such a stupid question, but what is a power of two boundry and
why do we want it to be aligned on one? I was assuming a power of two
boundry to be some memory address N such that N = 2 ** i, but this
apparently is not the
I think we should use int32_t instead of IV for all code related
data. The IV is 64-bit on 64-bit machine, which is significant
waste. The IV is also platform specific, and has caused some
nasty problems so far.
Hong
This seems to be working:
* fixes for label-only lines in assembler
* recognition of 0x, 0b, etc in constants
* and, not, or, shl, shr, xor
Enjoy!
Brian
Patch follows
Index: assemble.pl
===
RCS
At 05:06 PM 9/12/2001 -0700, Hong Zhang wrote:
I think we should use int32_t instead of IV for all code related
data.
Absolutely. Using an IV was a quick answer to get things working--a first
draft if you will. It needs rewriting so all the ops are I32 and the
floating point constants are
I think we should use int32_t instead of IV for all code related
data. The IV is 64-bit on 64-bit machine, which is significant waste.
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a waste) being bandied around, without
much hard numbers
I've been having tons of problems with labels in the current
assembler...so I wrote my own. It should provide all of the features
that the current assembler has. I'ved tested and ran all of the current
t/*.pasm files.
Here it is...feedback is always welcome.
Brian
#! /usr/bin/perl -w
#
#
I have done all the trancendental math functions...but I'm having a problem
with print_n...I checked out a clean copy of parrot and ran the following
program:
set_n_nc N1, 1
print_n N1
end
and nothing prints out...
Can anyone else get this to print out anything...is it just me?
Also,
This diff adds jsr_ic and ret to the interpreter. I don't know if my
way of returning is legal, and I know there's probably issues with 64
bit machines, but it works...and that's the important part :)
Right now it only has a depth of 32 and no bounds checking, but its
enough to get started.
Ah, apparently I selected long double for NV which doesn't work
correctly...double works fine however.
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED]'
Sent: 9/12/2001 11:32 PM
Subject: print_n doesn't work?
I have done all the trancendental math functions...but
38 matches
Mail list logo
