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
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 tested and ran all of the current
> t/*.pasm files.
>
> He
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
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
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
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
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,
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,
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
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:
Index: Makefile
===
RCS file: /home/perlcvs/parrot/Makefile,v
retrieving revision 1.9
diff -c
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
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
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 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: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
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: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
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
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
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, 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
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
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
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
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.
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
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
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, 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
> >
--- 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
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
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
> > > 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
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 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 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 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 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 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 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
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
=
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
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 09:54:35AM -0500, Brian Wheeler wrote:
> < if($op=~/$test/) {
> ---
> > if($op=~/^$test$/) {
Seems to be applied as part of your other patch. :)
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
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
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
-
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
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
=
> 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 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
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, 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
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
> 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
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
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
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
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
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 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
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 :-)
>
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
==
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*
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
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
?
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
--- 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;
> <
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
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
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
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.
> "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
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
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 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 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
>> >
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 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 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 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 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
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
1 - 100 of 111 matches
Mail list logo
