>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
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
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
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
--- 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
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
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
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
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
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
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
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
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
> > > 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 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
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,
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
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,
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
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
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, 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 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 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 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 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
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
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 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 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
>> >
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
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
==
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
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
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
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
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 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
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
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*
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
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
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
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
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
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 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
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
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
?
> "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 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
==
Will the coding standard get assigned a PDD number and be put into CVS?
Just wondering,
Tanton
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
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
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
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
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
--- 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;
> <
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
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
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
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
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
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.
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
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
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
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
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
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
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
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 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
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
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
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
77 matches
Mail list logo
