Re: Math functions? (Particularly transcendental ones)

2001-09-13 Thread Tim Conrow
>Okay, I'm whipping together the "fancy math" section of the interpreter >assembley language. I've got: > ... >Can anyone think of things I've forgotten? It's been a while since I've >done numeric work. HP calculators sometimes define lnp1(x) = ln(1 + x) expm1(x) = exp(x) - 1 to deal accu

Re: What's up with %MY?

2001-09-13 Thread David L. Nicol
Uri Guttman can see a day where: > python and ruby, etc. are > defaulting to using the parrot back end as it will be faster, and > compatible with perl etc. imagine the work reduction if all/most of the > interpreted languages can share one common back end. What about the compiled ones? Did we c

Re: What's up with %MY?

2001-09-13 Thread Dan Sugalski
At 05:42 PM 9/12/2001 -0500, David L. Nicol wrote: >Uri Guttman can see a day where: > > python and ruby, etc. are > > defaulting to using the parrot back end as it will be faster, and > > compatible with perl etc. imagine the work reduction if all/most of the > > interpreted languages can share o

Re: Patch: Common opcode_table parsing

2001-09-13 Thread Simon Cozens
On Thu, Sep 13, 2001 at 12:29:18AM -0700, Damien Neil wrote: > CVS changes over the past couple of days mean this patch will no > longer cleanly apply. I'd be happy to update it to patch cleanly > against the current CVS code, but I'd like to know first if the > approach it takes is on the right

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Benjamin Stuhl
--- Dave Mitchell <[EMAIL PROTECTED]> wrote: > Andy Dougherty <[EMAIL PROTECTED]> wrote: > > On Wed, 12 Sep 2001, Dan Sugalski wrote: > > > > > > > changing parrot.h to do #include > "parrot/config.h" and > > > > > then changing > > > > > Makefile to add -I./include to CCFLAGS. > > > > > One t

patch: print op cleanups, new ops, assembler support of \(whatever)

2001-09-13 Thread Brian Wheeler
This patch gives the assembler support of '\a','\n','\r','\t', and '\\' in string constants. In addition, it changes (for all registers) "I reg %li is ..." to just the value of the register. Printing constants is also supported, but alas, you have to specify the type (print_sc, print_ic, print_n

Re: on the long term Configure system

2001-09-13 Thread David L. Nicol
Jarkko Hietaniemi wrote: > The bootstrapping may take several rounds as Parrot learns ... > - execute (collect output) (note that execution may not be native) I don't think these two (cross-compile and build-own-tools) are strictly compatible goals. If you are going to build your own tools and

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Dan Sugalski
At 08:59 AM 9/13/2001 -0400, Andy Dougherty wrote: >On Wed, 12 Sep 2001, Dan Sugalski wrote: > > > > > changing parrot.h to do #include "parrot/config.h" and > > > > then changing > > > > Makefile to add -I./include to CCFLAGS. > > > One thing to keep in mind is that the directory may not be suff

Re: jsr_ic & ret support

2001-09-13 Thread Simon Cozens
On Thu, Sep 13, 2001 at 12:01:47AM -0500, Brian Wheeler wrote: > 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 :) I'm deferring to Dan on t

Re: Using int32_t instead of IV for code

2001-09-13 Thread Dan Sugalski
At 10:06 AM 9/13/2001 +0100, Philip Kendall wrote: >On Wed, Sep 12, 2001 at 10:03:55PM -0400, Dan Sugalski wrote: > > 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 answ

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Simon Cozens
On Wed, Sep 12, 2001 at 07:12:44PM -0400, Dan Sugalski wrote: > 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 f

What about arrays?

2001-09-13 Thread Gregor N. Purdy
All -- How far away are we from being able to deal with arrays? I'd like to write some tests that involve arrays... >From a few quick searches, it seems to me that we need to implement arrays via PMCs. I think that means we need a way to use some op(s) to perform memory allocations, etc., unless

Re: String API

2001-09-13 Thread Simon Cozens
On Tue, Sep 11, 2001 at 09:08:18AM +0100, Simon Cozens wrote: > > The use of an encoding enum seems a little weird, but once > > you explain why it will probably make sense. Right now the > > only thing it seems good for is the transcoding system -- > > everything else is slower and vtables are mo

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Jarkko Hietaniemi
> > > Not, mind, that I'm proposing prepending parrot_ to all the filenames, > > > though that's an option certainly. > > > >That would be fun on 8.3 filesystems :-). > > I'm seriously considering not going out of our way to support what could be > reasonably considered antique systems. That'd i

Re: Patch to fix C++ style comments

2001-09-13 Thread Dan Sugalski
At 09:35 AM 9/13/2001 +0100, Tom Hughes wrote: >The parrot code is currently full of C++ style comments which cause >many C compilers to barf. The attached patch changes these to C style >comments to fix this problem. Thanks. GCC and Dec C were both happy with 'em, so laziness prevailed for a wh

Re: Patch: Common opcode_table parsing

2001-09-13 Thread Damien Neil
On Thu, Sep 13, 2001 at 08:25:46AM +0100, Simon Cozens wrote: > On Thu, Sep 13, 2001 at 12:29:18AM -0700, Damien Neil wrote: > > CVS changes over the past couple of days mean this patch will no > > longer cleanly apply. I'd be happy to update it to patch cleanly > > against the current CVS code,

Re: Using int32_t instead of IV for code

2001-09-13 Thread Dan Sugalski
At 06:27 AM 9/13/2001 +0300, Jarkko Hietaniemi wrote: > > 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

Re: Patch: Common opcode_table parsing

2001-09-13 Thread Simon Cozens
On Thu, Sep 13, 2001 at 12:47:06AM -0700, Damien Neil wrote: > I *really* think we need to munge the names, though. "end" is just > far too common a symbol for us to be able to pollute it. Let's > learn the lesson from Perl 5: All symbols exported by the Parrot > code need a prefix. Aiiee. Yes,

Re: String API

2001-09-13 Thread Tom Hughes
In message <[EMAIL PROTECTED]> Benjamin Stuhl <[EMAIL PROTECTED]> wrote: > Thus wrote the illustrious Simon Cozens: > [severely trimmed] > > STRING* string_make(void *buffer, IV buflen, IV > > encoding, IV flags, IV type) > > STRING* string_copy(STRING* s) > > void string_de

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Andy Dougherty
On Wed, 12 Sep 2001, Dan Sugalski wrote: > > > changing parrot.h to do #include "parrot/config.h" and > > > then changing > > > Makefile to add -I./include to CCFLAGS. > One thing to keep in mind is that the directory may not be sufficient on > some platforms. VMS, specifically, ignores the d

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Andy Dougherty
On Thu, 13 Sep 2001, Dave Mitchell wrote: > Andy Dougherty <[EMAIL PROTECTED]> wrote: > > > > > changing parrot.h to do #include "parrot/config.h" and > > > > > then changing > > > > > Makefile to add -I./include to CCFLAGS. > > > Perhaps I'm missing something here, but I always thought that

Re: pasm.pl: a different parrot assembler

2001-09-13 Thread Brian Wheeler
On Thu, 2001-09-13 at 02:23, Simon Cozens wrote: > On Wed, Sep 12, 2001 at 11:23:27PM -0500, Brian Wheeler wrote: > > 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 te

Attention! Re: pasm.pl: a different parrot assembler

2001-09-13 Thread Simon Cozens
On Thu, Sep 13, 2001 at 08:47:51AM -0500, Brian Wheeler wrote: > You, sir, are a very picky man. :) That's why I'm wearing this pumpcrown thing. > Here it is...I tested it on this euclid.pasm: Excellent. Thank you *very* much. Head's up, everyone, this is going in *in place of* the current ass

Re: PDD 6 (parrot assembly) now in CVS

2001-09-13 Thread Buggs
On Thursday 13 September 2001 18:26, Dan Sugalski wrote: > At 10:21 AM 9/13/2001 -0600, Nathan Torkington wrote: > >Dan Sugalski writes: > > > >Lines 249 to 261 seem to duplicate 204 to 216. > > > > > > D'oh! Thanks, fixed. > > > >Oh man, good luck building a unit testing system for the docs :-) >

Re: [PATCH]Transcendental Math Functions

2001-09-13 Thread Dan Sugalski
At 01:55 AM 9/13/2001 -0500, Gibbs Tanton - tgibbs wrote: >Here are the transcendental math functions. Yay! Thank you *very* much. Dan --"it's like this"--- Dan Sugalski even s

Re: jsr_ic & ret support

2001-09-13 Thread Dan Sugalski
At 12:01 AM 9/13/2001 -0500, Brian Wheeler wrote: >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

Re: print_n doesn't work?

2001-09-13 Thread Dan Sugalski
At 11:32 PM 9/12/2001 -0500, Gibbs Tanton - tgibbs wrote: >I have done all the trancendental math functions...but I'm having a problem >with print_n I see you've already found the double/long double problem. Embedded FP constants are a portability issue regardless, unfortunately, and I'm beginn

Re: Patch: Common opcode_table parsing

2001-09-13 Thread Damien Neil
On Thu, Sep 13, 2001 at 08:44:44AM +0100, Simon Cozens wrote: > Aiiee. Yes, I appreciate what you're saying, but the other lessons > from Perl 5 is that if you want to do that, you end up with either > lots of unweildy code, or a nasty macro renaming. Which is it > gonna be? I don't really like t

Re: Patch: Common opcode_table parsing

2001-09-13 Thread Dan Sugalski
At 08:44 AM 9/13/2001 +0100, Simon Cozens wrote: >On Thu, Sep 13, 2001 at 12:47:06AM -0700, Damien Neil wrote: > > I *really* think we need to munge the names, though. "end" is just > > far too common a symbol for us to be able to pollute it. Let's > > learn the lesson from Perl 5: All symbols e

Re: Patch to fix += on rvalue

2001-09-13 Thread Dan Sugalski
At 09:30 AM 9/13/2001 +0100, Simon Cozens wrote: >On Thu, Sep 13, 2001 at 09:29:44AM +0100, Tom Hughes wrote: > > The inc_n_nc op does this: > > (NV)NUM_REG(P1) += P2 > > > > Unfortunately the (NV) cast means that the LHS is not an lvalue and > > cannot therefore be assigned to in ANSI C. It see

Re: Using int32_t instead of IV for code

2001-09-13 Thread Dan Sugalski
At 05:08 PM 9/13/2001 -0400, Buddha Buck wrote: >At 04:55 PM 09-13-2001 -0400, Andy Dougherty wrote: >>In perl.perl6.internals, you wrote: >> >> >The attached patch makes all bytecode have a type of int32_t rather than >> >IV; it also contains the other stuff I needed to get the tests running >> >

Re: Using int32_t instead of IV for code

2001-09-13 Thread Jarkko Hietaniemi
On Thu, Sep 13, 2001 at 05:50:06PM +0100, Simon Cozens wrote: > On Thu, Sep 13, 2001 at 09:43:06AM -0700, Damien Neil wrote: > > The language lawyer in me insists that I point out that this is > > inherently nonportable. > > That as may be, Perl 5 runs on nearly 80 platforms and uses this > tric

RE: [PATCH]Assembler.pl

2001-09-13 Thread Gibbs Tanton - tgibbs
Because of some of the changes to the assembler...my patch no longer applies cleanly. Therefore, I'm resubmitting it. When we changed assemblers, the new assembler did not correctly support the transcendental math functions...this patch fixes that. Index: assemble.pl ==

Patch: Common opcode_table parsing, take 2

2001-09-13 Thread Damien Neil
Here's an updated version of my original patch, to account for recent changes in CVS. As before, this includes opcode-munging to let Parrot run on FreeBSD. - Damien diff -u --new-file -r parrot.orig/Parrot/Opcode.pm parrot/Parrot/Opcode.pm --- parrot.orig/Parrot/Opcod

RE: Things we need to do.

2001-09-13 Thread Brent Dax
Brent Dax: # Sent: Thursday, September 13, 2001 14:17 # To: Simon Cozens; [EMAIL PROTECTED] # Subject: RE: Things we need to do. # # # Simon Cozens: # # 2) Extend the Configure.pl system to autogenerate the # #Makefile as well. Use Makefile.in as a template, and # #fill in thin

More Configure.pl Modifications

2001-09-13 Thread Brent Dax
Okay, this makes Configure generate a Parrot::Config module in the current directory. This is analogous to Config.pm, except this exports a %PConfig hash (to avoid collisions). I'm using Data::Dumper to create the hash, so it'll make sure you have it and just not generate the file (and tell the

Re: Using int32_t instead of IV for code

2001-09-13 Thread Dan Sugalski
At 11:44 PM 9/13/2001 +0100, Nicholas Clark wrote: >If bytecode is 32 bit, and we want an opaque C type to be a thing capable >of representing 32 bits, as ANSI allows structure padding I believe that >there's no guarantee that sizeof an array of two of them is 8 chars >(by which I am assuming 64bi

Re: PDD 6 (parrot assembly) now in CVS

2001-09-13 Thread Buggs
On Thursday 13 September 2001 18:26, Dan Sugalski wrote: > At 10:21 AM 9/13/2001 -0600, Nathan Torkington wrote: > >Dan Sugalski writes: > > > >Lines 249 to 261 seem to duplicate 204 to 216. > > > > > > D'oh! Thanks, fixed. > > > >Oh man, good luck building a unit testing system for the docs :-) >

Re: Patch to fix arithmetic on void * pointers

2001-09-13 Thread Dan Sugalski
At 10:04 AM 9/13/2001 +0100, Tom Hughes wrote: >This patch fixes a couple of cases where arithmetic on void * pointers >is being done, which isn't valid although gcc seems to allow it. I need to get this building on Dec C again, I see. Damn. >Of course the memory.c code is broken anyway because

Re: patch: assembly listings from assembler

2001-09-13 Thread Damien Neil
On Thu, Sep 13, 2001 at 06:41:00PM -0400, Dan Sugalski wrote: > At 01:42 PM 9/13/2001 -0700, Benjamin Stuhl wrote: > >Could we please get in the habit of adding a -c or a -u to > >our CVS diffs, just as we would with normal patches? > > Yes, please! > > All diffs posted to the list should be eit

A quick note on The Big Picture

2001-09-13 Thread Dan Sugalski
We've all been pretty good about things so far, but I do want to remind folks to take a look at the bigger picture when they're deciding on features (or mis-features... :) of Parrot. First, and most importantly, the following should be considered "cast in stone" things. (In the long run, *not*

Re: Patch to link with the maths library

2001-09-13 Thread Simon Cozens
On Thu, Sep 13, 2001 at 09:22:44AM +0100, Tom Hughes wrote: > Now that parrot has the advanced math ops in it needs to link with > the maths library or you get lots of missing symbols. Patch as follows: Thanks, but can we tie this into Configure.pl somehow? Configure.pl will know if we have to l

Re: [patch] First cut at TODO "allow add I4, I4, 3 instead of add_i_ic ..."

2001-09-13 Thread Simon Cozens
On Wed, Sep 12, 2001 at 05:18:38PM -0400, Gregor N. Purdy wrote: > 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

[PATCH]coding standards

2001-09-13 Thread Gibbs Tanton - tgibbs
This patch implements some of the coding standards in an earlier PDD. Functions such as Allocate_Aligned were changed to lowercase, and all functions in memory.{h,c} had mem_ prepended to them. The only thing I didn't really try to fix were the #define's being lowercase (such as sys_memcopy). I

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Dan Sugalski
At 06:31 PM 9/13/2001 +0300, Jarkko Hietaniemi wrote: > > > > Not, mind, that I'm proposing prepending parrot_ to all the filenames, > > > > though that's an option certainly. > > > > > >That would be fun on 8.3 filesystems :-). > > > > I'm seriously considering not going out of our way to support

Re: another purify run

2001-09-13 Thread Dan Sugalski
At 02:39 AM 9/13/2001 -0700, Josh Wilmes wrote: >Yeah at this point I figure the allocation stuff isn't that useful. >However the "uninitialized memory read", "invalid pointer read", and >"free memory write" errors might be of interest. Those were the ones I was worried about. They show we're do

Re: Using int32_t instead of IV for code

2001-09-13 Thread Paul Johnson
On Thu, Sep 13, 2001 at 05:08:33PM -0400, Buddha Buck wrote: > At 04:55 PM 09-13-2001 -0400, Andy Dougherty wrote: > >In perl.perl6.internals, you wrote: > > > > >The attached patch makes all bytecode have a type of int32_t rather than > > >IV; it also contains the other stuff I needed to get the

Re: Using int32_t instead of IV for code

2001-09-13 Thread Dan Sugalski
At 09:43 AM 9/13/2001 -0700, Damien Neil wrote: >On Thu, Sep 13, 2001 at 10:06:51AM +0100, Philip Kendall wrote: > > If we are going to keep on doing fancy stuff with pointer arithmetic (eg > > the Alloc_Aligned/CHUNK_BASE stuff), I think we're also going to need an > > integer type which is guara

Re: [patch] First cut at TODO "allow add I4, I4, 3 instead ofadd_i_ic ..."

2001-09-13 Thread Gregor N. Purdy
Dan -- > > * 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. Odds are almost nobody'll be writing > parrot assembler once we have a working

patch: bitops with constants

2001-09-13 Thread Brian Wheeler
This patch allows you to do thingies like: and I1,I2,0x 'and', 'or', and 'xor' have been adapted to use this. Also, shl and shr can take an integer register as the amount to shift. Brian ? pasm.pl ? patch ? test2.pbc ? test3.pbc ? euclid0.pbc ? euclid1.pbc ? euclid.pbc ?

Re: CVS update mailing list

2001-09-13 Thread Uri Guttman
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> For those of you who might want to be kept up to date with changes DS> to the CVS repository, there is a mailing list that posts all the DS> changes to the repository. Send mail to DS> [EMAIL PROTECTED] to start the process. does

patch - strnative.c grows incorrectly

2001-09-13 Thread Gibbs Tanton - tgibbs
I think the substr in strnative.c is incorrectly growing the destination string. The following is a patch to fix it. It also uses the previous patch for function names...so it needs to be applied after that patch. Index: strnative.c ==

PDD in CVS

2001-09-13 Thread Gibbs Tanton - tgibbs
Will the coding standard get assigned a PDD number and be put into CVS? Just wondering, Tanton

patch: assembly listings from assembler

2001-09-13 Thread Brian Wheeler
This patch does a couple of things: * uses Getopt::Long for options. -c is now --checksyntax. I wasn't sure how to keep compatible (patches welcome!) * options include: --help --version --verbose --output=file

Re: Using int32_t instead of IV for code

2001-09-13 Thread Philip Kendall
On Wed, Sep 12, 2001 at 10:03:55PM -0400, Dan Sugalski wrote: > 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 nee

patch test3.pasm

2001-09-13 Thread Gibbs Tanton - tgibbs
test3.pasm needed an end at the end of the file. Here is the patch This should fix one of the bugs reported by purify. Index: test3.pasm === RCS file: /home/perlcvs/parrot/t/test3.pasm,v retrieving revision 1.1 diff -u -r1.1 test3.p

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Nathan Torkington
Andy Dougherty writes: > > #include "config.h" > > rather than > > #include Isn't the correct solution to this problem to say #include That is, include the subdirectory prefix in all #includes. You -I the directory containing parrot/, and that avoids randomly located config.h files from b

Re: #include "config.h" or #include "parrot/config.h"

2001-09-13 Thread Dave Mitchell
Andy Dougherty <[EMAIL PROTECTED]> wrote: > On Wed, 12 Sep 2001, Dan Sugalski wrote: > > > > > changing parrot.h to do #include "parrot/config.h" and > > > > then changing > > > > Makefile to add -I./include to CCFLAGS. > > > One thing to keep in mind is that the directory may not be sufficien

Re: patch: assembly listings from assembler

2001-09-13 Thread Benjamin Stuhl
--- Brian Wheeler <[EMAIL PROTECTED]> wrote: > > Index: assemble.pl > === > RCS file: /home/perlcvs/parrot/assemble.pl,v > retrieving revision 1.14 > diff -r1.14 assemble.pl > 7a8 > > use Getopt::Long; > 9,12c10,33 > < my $opt_c; > <

Things we need to do.

2001-09-13 Thread Simon Cozens
If you're looking for something to do, we *always* have good little jobs for people. :) 1) See if there's a neat way of making the assembler grok shortened forms of ops: add I1, I2, I3 => add_i I1, I2, I3 print S1 => print_s S1 2) Extend the Configure.pl syste

Re: Patch to fix C++ style comments

2001-09-13 Thread Tom Hughes
In message <[EMAIL PROTECTED]> Simon Cozens <[EMAIL PROTECTED]> wrote: > On Thu, Sep 13, 2001 at 09:35:33AM +0100, Tom Hughes wrote: > > BTW I have had to resend this because my first attempt was bounced > > apparently for having the patch as a text/plain attachment rather than > > inline

Patch to fix arithmetic on void * pointers

2001-09-13 Thread Tom Hughes
This patch fixes a couple of cases where arithmetic on void * pointers is being done, which isn't valid although gcc seems to allow it. Of course the memory.c code is broken anyway because it assumes a pointer will fit in an IV and I'm not sure that will always be true will it? Anyway with this

Re: Using int32_t instead of IV for code

2001-09-13 Thread Philip Kendall
On Wed, Sep 12, 2001 at 10:03:55PM -0400, Dan Sugalski wrote: > 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 nee

another purify run

2001-09-13 Thread Josh Wilmes
FYI.. There are a few interesting things in here which look like they may be real errors. (i'd ignore the PLKs for now) --Josh perl assemble.pl t/test.pasm > t/test.pbc ./test_prog t/test.pbc > t/test.out Purify instrumented test_prog (pid 17982 at Thu Sep 13 02:08:41 2001) * Purify

[PATCH]Assembler.pl

2001-09-13 Thread Gibbs Tanton - tgibbs
This patch allows 0-9 in the opcode name (for atan2 and log10 etc...). It also uses the pack_type hash for the pack instead of the real_type. Index: assemble.pl === RCS file: /home/perlcvs/parrot/assemble.pl,v retrieving revision 1.

Re: Using int32_t instead of IV for code

2001-09-13 Thread Simon Cozens
On Thu, Sep 13, 2001 at 10:06:51AM +0100, Philip Kendall wrote: > I think we're also going to need an integer type which is guaranteed to be > the same width as a pointer, so we can freely typecast between the two. I thought that was what IVs are *for*. Simon

Re: another purify run

2001-09-13 Thread Simon Cozens
On Thu, Sep 13, 2001 at 02:21:16AM -0700, Josh Wilmes wrote: > There are a few interesting things in here which look like they may be > real errors. (i'd ignore the PLKs for now) Thanks for doing this, but to be honest, I expect our memory allocation to be all to hell because we have no freeing

Re: another purify run

2001-09-13 Thread Josh Wilmes
Yeah at this point I figure the allocation stuff isn't that useful. However the "uninitialized memory read", "invalid pointer read", and "free memory write" errors might be of interest. --Josh At 10:18 on 09/13/2001 BST, Simon Cozens <[EMAIL PROTECTED]> wrote: > On Thu, Sep 13, 2001 at 02:2

config.h.in

2001-09-13 Thread Philip Kendall
Two small changes to config.h.in: * Actually use ${nv} for the numeric type, rather than `${iv} double'. * Make MASK_CHUNK_LOW_BITS 64 bit clean. Phil Index: config.h.in === RCS file: /home/perlcvs/parrot/config.h.in,v retrieving r

Quick success report for Win32

2001-09-13 Thread Benjamin Stuhl
I had to hand-apply the NV patch and some of the casting patches to get VC++ to shut up and compile, but Parrot works on Win32 (Win2k, VC++ 6.0SP5). (it takes <1 sec to count to ten million on my PIII 1Ghz) I'll post the hacked-up Makefile that I fed through nmake to get it to work when I get back

Re: What about arrays?

2001-09-13 Thread Dan Sugalski
At 01:30 PM 9/13/2001 -0400, Gregor N. Purdy wrote: >All -- > >How far away are we from being able to deal with arrays? I'd like to >write some tests that involve arrays... Soon, though scalars will probably come first. I need to finalize the key specification stuff first so we can actually get

patch: assemble.pl choosing wrong op sometimes...

2001-09-13 Thread Brian Wheeler
I caught it trying to use inc_i_ic instead of inc_i in a test program I was running. this patch fixes it. Brian Index: assemble.pl === RCS file: /home/perlcvs/parrot/assemble.pl,v retrieving revision 1.12 diff -r1.12 assemble.pl 1

Re: PDD 6 (parrot assembly) now in CVS

2001-09-13 Thread Dan Sugalski
At 06:07 PM 9/13/2001 +0200, Buggs wrote: >On Wednesday 12 September 2001 17:45, Dan Sugalski wrote: > > 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 > >Lines 2

Re: patch: print op cleanups, new ops, assembler support of \(whatever)

2001-09-13 Thread Simon Cozens
On Thu, Sep 13, 2001 at 10:25:15AM -0500, Brian Wheeler wrote: > This patch gives the assembler support of '\a','\n','\r','\t', and '\\' > in string constants. Oh that's cute. > In addition, it changes (for all registers) "I reg %li is ..." to just > the value of the register. Printing constant

Re: CVS update mailing list

2001-09-13 Thread Dan Sugalski
At 06:20 PM 9/13/2001 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> For those of you who might want to be kept up to date with changes > DS> to the CVS repository, there is a mailing list that posts all the > DS> changes to the repository. Send ma

[patch] Us of opcode table fingerprints in assemble.pl anddisassemble.pl

2001-09-13 Thread Gregor N. Purdy
All -- This patch to assemble.pl and disassemble.pl makes the assembler output constant #0 as the hex string representation of the MD5 sum of opcode_table. It also makes disassemble.pl check that the fingerprint matches before disassembling, and warns if there is no constant pool at all. The nex

Patch to fix += on rvalue

2001-09-13 Thread Tom Hughes
The inc_n_nc op does this: (NV)NUM_REG(P1) += P2 Unfortunately the (NV) cast means that the LHS is not an lvalue and cannot therefore be assigned to in ANSI C. It seems that gcc allows you to get away with this, but other compiler don't. The cast is also unnecessary as NUM_REG() gives an NV a