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 :-)
>
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
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
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
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Actually, I'm expecting almost nothing to be written in pasm after
DS> we get a working parser and compiler. We might write template code
DS> for the compiler in it, but that's probably about it. Well, other
DS> than the JAPHs tha
At 06:35 PM 9/13/2001 -0700, Brent Dax wrote:
>Brad Hughes:
># Brent Dax wrote:
># [...]
># >
># > +sub buildfile {
># > + my($filename)=shift;
># > +
># > + local $/;
># > + open(IN, "<$filename.in");
>#
># According to the coding guidelines PDD (which still doesn't seem
># to h
Brad Hughes:
# Brent Dax wrote:
# [...]
# >
# > +sub buildfile {
# > + my($filename)=shift;
# > +
# > + local $/;
# > + open(IN, "<$filename.in");
#
# According to the coding guidelines PDD (which still doesn't seem
# to have been assigned a PDD number), filenames shouldn't have
Brent Dax wrote:
[...]
>
> +sub buildfile {
> + my($filename)=shift;
> +
> + local $/;
> + open(IN, "<$filename.in");
According to the coding guidelines PDD (which still doesn't seem
to have been assigned a PDD number), filenames shouldn't have more
than one '.' in them. I kno
At 09:42 AM 9/13/2001 -0400, Gregor N. Purdy wrote:
>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 n
> I'd have thought it made sense to define it as a bytecode_t type, or
> some such which could be platform specific.
It is better called opcode_t, since we are not using bytecode anyway.
Hong
> To Schwern:
> * Test::Parrot ( or whatever ), needs to be special cased
> in Test::Simple::ok ( as Test::More is ), to report test
> line correctly.
A Test::Simple function to know the actual test number would
be nice, too.
Regards
Mattia
Hi
Here is the fibonaci function
#
# fibo.pasm
#
# int fibo(int i) {
# int a,b,c = 0;
# if(i == 1 || i == 2) {
#a = 1;
# } else {
#i = i - 2;
#a = 1;
#b = 1;
#while(i != 0) {
# c = a;
# a = a + b;
# b = c;
# i--;
#}
# }
# return a;
# }
#
# I1: res
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
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
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
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
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
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
>> >
At 03:04 PM 9/13/2001 -0500, Gibbs Tanton - tgibbs wrote:
>Will the coding standard get assigned a PDD number and be put into CVS?
I think it already has one somewhere. If not, I'll talk to Ziggy (the perl
6 librarian) and see about getting things coordinated so it has one.
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 either -c or -u diffs. Both can be
fed to patch, and both read far more easily
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
> "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
I have a patch that puts parrot/ in front of all the header files and adds
-I.. to the makefile. However, I will wait until some of the other patches
get applied because my version is extremely hacked up and I don't want to
keep sending all these patches munged together.
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
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
> >on my Alpha (modifications to config.h.in and register
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
>on my Alpha (modifications to config.h.in and register.c).
I think this is a bad idea. There simply is no guaran
--- 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;
> <
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
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
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
Will the coding standard get assigned a PDD number and be put into CVS?
Just wondering,
Tanton
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
==
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
?
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
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*
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
==
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 :-)
>
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
In perl.perl6.internals, you 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
>trick.
[interchanging pointers and
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
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
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
Simon --
> > The next issue would be making the interpreter do something with the
> > fingerprint...
>
> I like this, but I don't want to apply it yet until I see it all working
> together.
I've attached a new patch that adds the necessary bits to bytecode.[hc],
assemble.pl build_interp_starter
> 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 guaranteed to be the same width as a pointer, so
> we can freely typecast between the two.
You are not supposed to do fancy
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
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
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
trick.
Is that portable enough for you?
Simon
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 guaranteed to be the same width as a pointer, so
> we can fr
> If you're looking for something to do, we *always* have good
> little jobs for people. :)
Great!
> 6) A test suite! My kingdom for a test suite!
I had a first stab at it; attached module + sample script,
for discussion only, because it is a kludge; I'll tidy it up
this evening.
Questions:
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 249 to 261 seem to duplicate 204 to 216.
Buggs
=
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 :-)
That's actually an interesting thing to consider. We could check for
d
For those of you who might want to be kept up to date with changes to the
CVS repository, there is a mailing list that posts all the changes to the
repository. Send mail to [EMAIL PROTECTED] to start the process.
Dan
-
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 :-)
Nat
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
On Thu, Sep 13, 2001 at 09:54:35AM -0500, Brian Wheeler wrote:
> < if($op=~/$test/) {
> ---
> > if($op=~/^$test$/) {
Seems to be applied as part of your other patch. :)
On Thu, Sep 13, 2001 at 11:05:58AM -0400, Gregor N. Purdy wrote:
> The next issue would be making the interpreter do something with the
> fingerprint...
I like this, but I don't want to apply it yet until I see it all working
together.
Simon
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
This does a better job at guessing the correct opcode: the constant is
compared to a regex and determined which kind it is, instead of saying
"its just some sort of constant". This fixes the guessing problems with
my (print_ic print_sc print_nc) patch.
Brian
Index: assemble.pl
=
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
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
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
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
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
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
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
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
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
> > > 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
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
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
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
--- 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
On Thu, 2001-09-13 at 09:52, Jarkko Hietaniemi wrote:
> On Thu, Sep 13, 2001 at 09:54:35AM -0500, Brian Wheeler wrote:
> > 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
> >
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
On Thu, Sep 13, 2001 at 09:54:35AM -0500, Brian Wheeler wrote:
> 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: /hom
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
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.
All --
The attached patch removes the opcode qualifiers from t/euclid.pasm
to exercise opcode inference in the new assembler.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
G
All --
The attached patch removes the opcode qualifiers from t/euclid.pasm
to exercise opcode inference in the new assembler.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
G
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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. Isn't that a bit OTT though?
Hrm, I think other people have managed...
Both this, an
Setting up the strnative vtable is being done by casting a {}
delimited list of values to a structure type but this is a gcc
extension not ANSI C, so the following patch reworks this to
be ANSI compliant:
Index: strnative.c
===
RCS f
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 seems that gcc allows
> you to get away with this, but other c
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.
BTW I have had to resend this because my first attempt was bounced
apparently for having the patch as a text/plain attachment rat
On Thu, Sep 13, 2001 at 09:17:28AM +0100, Simon Cozens wrote:
> 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
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
1 - 100 of 111 matches
Mail list logo
