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 Wed, Sep 12, 2001 at 03:38:28PM -0400, Gregor N. Purdy wrote:
> This Makefile patch addes euclid.pasm to the make test target.
Thanks, applied.
Simon
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
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
#
# pa
> 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 numbe
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 N6
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 file:
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
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 t
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 wi
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 I'
--- 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
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
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 neces
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 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
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 s
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
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
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
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 samur
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
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.
> > >
> >
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
>
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
46 matches
Mail list logo
