On Tue, Sep 11, 2001 at 12:06:52AM -0700, Damien Neil wrote:
> The following patch moves all parsing of opcode_table into a
> Parrot::Opcode module. It also removes all parsing of interp_guts.h.
> This patch incorporates my earlier patches to prefix all C opcode
> functions with "Perl_op_".
CVS
On Wed, Sep 12, 2001 at 08:00:23PM -0500, Brian Wheeler wrote:
> 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!
I will! Thanks, applied.
Simon
On Wed, Sep 12, 2001 at 03:40:52PM -0400, Gregor N. Purdy wrote:
> The attached t/.cvsignore file will cause cvs to ignore the products
> of 'make test'.
Thanks, (both) applied.
On Thu, Sep 13, 2001 at 01:55:08AM -0500, Gibbs Tanton - tgibbs wrote:
> Here are the transcendental math functions.
You star! I was *just* about to ask people for a patch on this.
Applied, thanks.
> 2.) I'm using the standard C math functions. I don't know if we want
> to always do this,
Forgot to mention that this patch works with doubles (8 bytes) because that
is what the disassembler was set up with. However, both print_n and
Configure.pl seem to prefer long doubles (12 bytes). I have no clue which
one ya'll want to use, however, the patch below includes my previous patch,
bu
I've never submitted a patch before, but here goes...
Here are the transcendental math functions.
A couple of notes:
1.) I had to change the real type of n to a 'd' for it to output
the correct type in the pack in the assembler. It was already
a 'd' in the disassembler. I also change
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 I'
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.
Br
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, test3.pas
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').
> > Ch
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. $op
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
>
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 wrong
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 w
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 --
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. Purd
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
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 Alph
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 assign
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 (C)
> 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 calculatio
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 sus
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
I had to put the box hosting cvs.perl.org right now to single user
mode and reboot a few times today, first to try to fix some odd
problems with named coredumping in some standard libc functions and
later to boot on a kernel with support for a tape changer device.
Anyway, it should be up and sta
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 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 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
27 matches
Mail list logo
