Re: [patch] First cut at TODO "allow add I4, I4, 3 instead of add_i_ic ..."
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 root and the formal argument types (qualifiers)
> so that, e.g. $opqual{'add'}{'i:ic'} == 'add_i_ic'.
>
> This appears to work. I've tested the output of assembling euclid.pasm
> and got the same results as before. YMMV.
>
> I left some debugging printfs in the file but commented out. A cooler
> approach would do some sort of partial matching if you specified some
> qualifiers, such as "add_i I4, I4, 3" mapping to "add_i_ic I4, I4, 3".
Thanks; I'm not going to apply this yet, because someone else might come
up with a less messy way of doing it. :)
Simon
Re: pasm.pl: a different parrot assembler
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. > > Here it is...feedback is always welcome. Cool. Now, if it only handled abbreviated op names, I'd apply it... :) Simon
Re: Patch: Common opcode_table parsing
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 track. I like it, if only because reduction of common code is always good, and reduction of common code while everything's in a lot of flux is even better. > Whether this patch makes it in or not, it would be nice if either > the "end" opcode was renamed, or if something was added to munge > the opcode function names--the CVS parrot still cores on FreeBSD > due to a symbol conflict with libc. Urgh, urgh, urgh. I don't *like* the idea of munging opcode function names, but I equally don't like coredumps. Isn't there a way of telling the linker to use our own symbols? Simon
Re: jsr_ic & ret support
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 this one. And yes, we really need a test suite. :( If someone modifies the "print_s" op to *just* print the contents of the register, we can have a "ok $n" style test which can be run through the Perl test harnesses. Anyone up for it? Simon
Re: #include "config.h" or #include "parrot/config.h"
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 file > >> named "config.h" > >> in /usr/local/include. Other conflicts with "string.h" > >> and "memory.h" > >> are also conceivable. > > Yep, those two are definitely worrisome, as are some of the others. > (Stack.h, registers.h...) *Nod*. Patches, especially from the bandwidth police, would be very welcome. :)
Re: String API
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 more cumbersome > > because you have to manage a vtable[num_encodings] array. > > I don't know why I did this. Patches welcome. Oh well; I've patched it so that string->encoding is a vtable pointer. Simon
Re: Patch: Common opcode_table parsing
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, but I'd like to know first if the > > approach it takes is on the right track. > > I like it, if only because reduction of common code is always good, > and reduction of common code while everything's in a lot of flux > is even better. OK, I'll go through and update it again. This patch takes out the parsing of interp_guts.h, which I think is good for a variety of reasons. (Summary: it makes things simpler, and I don't think parsing it will buy us anything at this point in time.) Is this OK, or should I put it back in? > Urgh, urgh, urgh. I don't *like* the idea of munging opcode function > names, but I equally don't like coredumps. Isn't there a way of > telling the linker to use our own symbols? Actually, the problem is that the linker IS using our symbols. :> There appears to be an "end" symbol somewhere in libc that is getting munged by the Parrot symbol. I think. I didn't look deeply enough to see exactly how things were going wrong, once I traced the core to a symbol clash. 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. - Damien
Re: Patch: Common opcode_table parsing
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, 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? Simon
Re: Patch: Common opcode_table parsing
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 the Perl 5 approach of lots of macros. I'd rather have a short prefix attached to all symbols. par_foo() rather than foo() in all cases. For very commonly used macros (the equivalent of PUSHi()), you might relax this rule. Look at the current source: Is it really going to be any harder to always type par_string_length() rather than string_length(), or Par_Allocate_Aligned() rather than Allocate_Aligned()? The symbol names are long enough to begin with that an extra four characters isn't going to make much difference. Even a single character would do a lot to eliminate symbol clashes: Pstring_length() and PAllocate_Aligned(), for example. (Speaking of the above, someone authoritative may want to dictate whether functions are Upper_Case or lower_case.) Talking just about the opcode functions, however: Will code be calling opcode functions directly very often? Perhaps I'm wrong, but I'd think that ops being called outside the runops() loop will be rare. In fact, if ops can be embedded into a switch statement in runops() at compile time, there won't even be any assurance that there ARE any op functions to call. Unwieldy op function names shouldn't be a problem. - Damien
Patch to link with the maths library
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 -r1.9 Makefile *** Makefile2001/09/13 07:22:36 1.9 --- Makefile2001/09/13 08:20:54 *** *** 12,18 all : $(O_FILES) test_prog test_prog: test_main$(O) $(O_FILES) ! gcc -o test_prog $(O_FILES) test_main$(O) test_main$(O): $(H_FILES) --- 12,18 all : $(O_FILES) test_prog test_prog: test_main$(O) $(O_FILES) ! gcc -o test_prog $(O_FILES) test_main$(O) -lm test_main$(O): $(H_FILES) Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Re: Patch to link with the maths library
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 link in libm. Simon
Patch to fix += on rvalue
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 anyway, so this
patch removes the cast:
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.11
diff -u -r1.11 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/13 07:27:46 1.11
+++ basic_opcodes.ops 2001/09/13 08:27:40
@@ -219,7 +219,7 @@
// INC Nx, nnn
AUTO_OP inc_n_nc {
- (NV)NUM_REG(P1) += P2;
+ NUM_REG(P1) += P2;
}
// DEC Nx
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
Re: Patch to link with the maths library
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 this into Configure.pl somehow? Configure.pl > will know if we have to link in libm. I've put the patch in for now, since we don't really *have* a decent configure system. I'll think about hacking one up later today, if I get chance.
Patch to fix C++ style comments
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 rather than
inline. Isn't that a bit OTT though? I can understand blocking HTML
messages and attachments but I prefer to send patches as attachments
as it ensures that trailing blank lines and such like are properly
preserved and basically that the patch arrives completely intact.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
diff -u parrot/basic_opcodes.ops parrot.fixed/basic_opcodes.ops
--- parrot/basic_opcodes.opsThu Sep 13 08:27:46 2001
+++ parrot.fixed/basic_opcodes.ops Thu Sep 13 09:23:13 2001
@@ -7,47 +7,47 @@
#include "parrot.h"
#include "math.h"
-// SET Ix, CONSTANT
+/* SET Ix, CONSTANT */
AUTO_OP set_i_ic {
INT_REG(P1) = P2;
}
-// SET Ix, Ix
+/* SET Ix, Ix */
AUTO_OP set_i {
INT_REG(P1) = INT_REG(P2);
}
-// ADD Ix, Iy, Iz
+/* ADD Ix, Iy, Iz */
AUTO_OP add_i {
INT_REG(P1) = INT_REG(P2) +
INT_REG(P3);
}
-// SUB Ix, Iy, Iz
+/* SUB Ix, Iy, Iz */
AUTO_OP sub_i {
INT_REG(P1) = INT_REG(P2) -
INT_REG(P3);
}
-// MUL Ix, Iy, Iz
+/* MUL Ix, Iy, Iz */
AUTO_OP mul_i {
INT_REG(P1) = INT_REG(P2) *
INT_REG(P3);
}
-// DIV Ix, Iy, Iz
+/* DIV Ix, Iy, Iz */
AUTO_OP div_i {
INT_REG(P1) = INT_REG(P2) /
INT_REG(P3);
}
-// MOD Ix, Iy, Iz
+/* MOD Ix, Iy, Iz */
AUTO_OP mod_i {
INT_REG(P1) = INT_REG(P2) %
INT_REG(P3);
}
-// EQ Ix, Iy, EQ_BRANCH, NE_BRANCH
+/* EQ Ix, Iy, EQ_BRANCH, NE_BRANCH */
MANUAL_OP eq_i_ic {
if (INT_REG(P1) == INT_REG(P2)) {
RETURN(P3);
@@ -56,7 +56,7 @@
}
}
-// NE Ix, Iy, NE_BRANCH, EQ_BRANCH
+/* NE Ix, Iy, NE_BRANCH, EQ_BRANCH */
MANUAL_OP ne_i_ic {
if (INT_REG(P1) != INT_REG(P2)) {
RETURN(P3);
@@ -65,7 +65,7 @@
}
}
-// LT Ix, Iy, LT_BRANCH, GE_BRANCH
+/* LT Ix, Iy, LT_BRANCH, GE_BRANCH */
MANUAL_OP lt_i_ic {
if (INT_REG(P1) < INT_REG(P2)) {
RETURN(P3);
@@ -74,7 +74,7 @@
}
}
-// LE Ix, Iy, LE_BRANCH, GT_BRANCH
+/* LE Ix, Iy, LE_BRANCH, GT_BRANCH */
MANUAL_OP le_i_ic {
if (INT_REG(P1) <= INT_REG(P2)) {
RETURN(P3);
@@ -83,7 +83,7 @@
}
}
-// GT Ix, Iy, GT_BRANCH, LE_BRANCH
+/* GT Ix, Iy, GT_BRANCH, LE_BRANCH */
MANUAL_OP gt_i_ic {
if (INT_REG(P1) > INT_REG(P2)) {
RETURN(P3);
@@ -92,7 +92,7 @@
}
}
-// GE Ix, Iy, GE_BRANCH, LT_BRANCH
+/* GE Ix, Iy, GE_BRANCH, LT_BRANCH */
MANUAL_OP ge_i_ic {
if (INT_REG(P1) >= INT_REG(P2)) {
RETURN(P3);
@@ -101,7 +101,7 @@
}
}
-// IF IXx, TRUE_BRANCH, FALSE_BRANCH
+/* IF IXx, TRUE_BRANCH, FALSE_BRANCH */
MANUAL_OP if_i_ic {
if (INT_REG(P1)) {
RETURN(P2);
@@ -110,81 +110,81 @@
}
}
-// TIME Ix
+/* TIME Ix */
AUTO_OP time_i {
INT_REG(P1) = time(NULL);
}
-// PRINT Ix
+/* PRINT Ix */
AUTO_OP print_i {
printf("I reg %li is %li\n", P1, INT_REG(P1));
}
-// BRANCH CONSTANT
+/* BRANCH CONSTANT */
MANUAL_OP branch_ic {
RETURN(P1);
}
-// END
+/* END */
MANUAL_OP end {
RETURN(0);
}
-// INC Ix
+/* INC Ix */
AUTO_OP inc_i {
INT_REG(P1)++;
}
-// INC Ix, nnn
+/* INC Ix, nnn */
AUTO_OP inc_i_ic {
INT_REG(P1) += P2;
}
-// DEC Ix
+/* DEC Ix */
AUTO_OP dec_i {
INT_REG(P1)--;
}
-// DEC Ix, nnn
+/* DEC Ix, nnn */
AUTO_OP dec_i_ic {
INT_REG(P1) -= P2;
}
-// JUMP Ix
+/* JUMP Ix */
MANUAL_OP jump_i {
RETURN(INT_REG(P1));
}
-// SET Nx, CONSTANT
+/* SET Nx, CONSTANT */
AUTO_OP set_n_nc {
NUM_REG(P1) = P2;
}
-// ADD Nx, Ny, Nz
+/* ADD Nx, Ny, Nz */
AUTO_OP add_n {
NUM_REG(P1) = NUM_REG(P2) +
NUM_REG(P3);
}
-// SUB Nx, Ny, Iz
+/* SUB Nx, Ny, Iz */
AUTO_OP sub_n {
NUM_REG(P1) = NUM_REG(P2) -
NUM_REG(P3);
}
-// MUL Nx, Ny, Iz
+/* MUL Nx, Ny, Iz */
AUTO_OP mul_n {
NUM_REG(P1) = NUM_REG(P2) *
NUM_REG(P3);
}
-// DIV Nx, Ny, Iz
+/* DIV Nx, Ny, Iz */
AUTO_OP div_n {
NUM_REG(P1) = NUM_REG(P2) /
NUM_REG(P3);
}
-// EQ Nx, Ny, EQ_BRANCH, NE_BRANCH
+/* EQ Nx, Ny, EQ_BRANCH, NE_BRANCH */
MANUAL_OP eq_n_ic {
if (NUM_REG(P1) == NUM_REG(P2)) {
RETURN(P3);
@@ -193,7 +193,7 @@
}
}
-// IF Nx, TRUE_BRANCH, FALSE_BRANCH
+/* IF Nx, TRUE_BRANCH, FALSE_BRANCH */
MANUAL_OP if_n_ic {
if (NUM_REG(P1)) {
RETURN(P2);
@@ -202,369 +202,369 @@
}
}
-// TIME Nx
+/* TIME Nx */
AUTO_OP time_n {
NUM_REG(P1) = time(NULL);
}
-// PRINT Nx
+/* PRINT Nx */
AUTO_OP print_n {
printf("N reg %li is %f\n", P1, NUM_REG(P1));
}
-// INC Nx
+/* INC Nx */
AUTO_OP inc_n {
NUM_REG(P1) += 1;
}
-// INC Nx, nnn
+/* INC Nx, nnn */
AUTO_OP inc_n_nc
Re: Patch to fix += on rvalue
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 compiler don't. Naughty, naughty. Thanks, applied.
Patch to remove use of structure constant/cast
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 file: /home/perlcvs/parrot/strnative.c,v
retrieving revision 1.4
diff -u -r1.4 strnative.c
--- strnative.c 2001/09/13 07:14:24 1.4
+++ strnative.c 2001/09/13 08:36:34
@@ -55,7 +55,7 @@
STRING_VTABLE
string_native_vtable (void) {
-return (STRING_VTABLE) {
+STRING_VTABLE sv = {
enc_native,
string_native_compute_strlen,
string_native_max_bytes,
@@ -63,4 +63,5 @@
string_native_chopn,
string_native_substr,
};
+return sv;
}
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
Re: Patch to fix C++ style comments
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, and the other patch, (struct in strnative.c) applied.
Things we need to do.
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 system to autogenerate the Makefile as well. Use Makefile.in as a template, and fill in things like LIBS. 3) Move all the header files to "include/" and have the C source #include "parrot/include/" 4) Send me and Ben a patch to munge all the function names to meet the coding standards. You could even send a Perl script to do it! 5) Implement some more string encodings. docs/strings.pod tells you what you need to do. 6) A test suite! My kingdom for a test suite! Simon
Re: Patch to fix C++ style comments
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. Isn't that a bit OTT though? > > Hrm, I think other people have managed... Wierd. Must be something to do with the MIME that Gnus created then. > Both this, and the other patch, (struct in strnative.c) applied. I just realised I missed one: === RCS file: /home/perlcvs/parrot/config.h.in,v retrieving revision 1.1 diff -u -r1.1 config.h.in --- config.h.in 2001/09/11 09:44:00 1.1 +++ config.h.in 2001/09/13 08:52:26 @@ -13,7 +13,7 @@ typedef void DPOINTER; typedef void SYNC; -//typedef IV *(*opcode_funcs)(void *, void *) OPFUNC; +/*typedef IV *(*opcode_funcs)(void *, void *) OPFUNC; */ #define FRAMES_PER_CHUNK 16 Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Patch to fix arithmetic on void * pointers
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 patch and the others it now builds on
a Unixware box with the system compiler:
Index: memory.c
===
RCS file: /home/perlcvs/parrot/memory.c,v
retrieving revision 1.3
diff -u -r1.3 memory.c
--- memory.c2001/09/12 17:58:55 1.3
+++ memory.c2001/09/13 09:00:34
@@ -26,7 +26,7 @@
mem = malloc(max_to_alloc);
if (((IV)mem & mask) < (IV)mem) {
-mem = (void *)((IV)mem & mask) + ~mask + 1;
+mem = (void *)(((IV)mem & mask) + ~mask + 1);
}
return mem;
}
Index: strnative.c
===
RCS file: /home/perlcvs/parrot/strnative.c,v
retrieving revision 1.5
diff -u -r1.5 strnative.c
--- strnative.c 2001/09/13 08:44:08 1.5
+++ strnative.c 2001/09/13 09:00:34
@@ -26,7 +26,7 @@
/* b is now in native format */
string_grow(a, a->strlen + b->strlen);
-Sys_Memcopy(a->bufstart + a->strlen, b->bufstart, b->strlen);
+Sys_Memcopy((char *)a->bufstart + a->strlen, b->bufstart, b->strlen);
a->strlen = a->bufused = a->strlen + b->strlen;
return a;
}
@@ -47,7 +47,7 @@
/* Offset and length have already been "normalized" */
string_grow(dest, src->strlen - length);
-Sys_Memcopy(dest->bufstart, src->bufstart + offset, length);
+Sys_Memcopy(dest->bufstart, (char *)src->bufstart + offset, length);
dest->strlen = dest->bufused = length;
return dest;
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
Re: Using int32_t instead of IV for code
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 needs rewriting so all the ops are I32 and the > floating point constants are N64s. 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. Also, if we've got a system with 64 bit IVs, are the arguments to Parrot opcodes going to be 32 or 64 bit? If 32 bit, is there going to be any way of loading a 64 bit constant? Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/
another purify run
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 5.2 Solaris 2 (32-bit), Copyright (C) 1992-2000 Rational Software Corp. All rights reserved. * For contact information type: "purify -help" * Command-line: test_prog * Options settings: -purify -windows=no \ -purify-home=/usr/SD/rational/solaris2bin/../products/developertools.5.2.GA/releases/DeveloperTools.5.2/sun4_solaris2/bin/../../../purify-5.2-solaris2 * License successfully checked out. * Command-line: ./test_prog t/test.pbc Purify instrumented test_prog (pid 17982) UMR: Uninitialized memory read: * This is occurring while in: _unpacked_to_decimal_two [libc.so.1] __k_double_to_decimal [libc.so.1] double_to_decimal [libc.so.1] fconvert [libc.so.1] _doprnt[libc.so.1] printf [libc.so.1] * Reading 1 byte from 0xffbeda00 on the stack. * Address 0xffbeda00 is 1024 bytes below frame pointer in function _unpacked_to_decimal_two. Purify instrumented test_prog (pid 17982) Current file descriptors in use: 6 FIU: file descriptor 0: FIU: file descriptor 1: FIU: file descriptor 2: FIU: file descriptor 3: "t/test.pbc", O_RDONLY * File info: -rw-r--r-- 1 jwilmes eman 268 Sep 13 02:08 * File position: 0 * This file descriptor was allocated from: __open [libc.so.1] _open [libc.so.1] main [test_main.c:62] _start [crt1.o] FIU: file descriptor 26: FIU: file descriptor 27: Purify instrumented test_prog (pid 17982) Purify: Searching for all memory leaks... Memory leaked: 0 bytes (0%); potentially leaked: 57400 bytes (77.8%) PLK: 32768 bytes potentially leaked at 0xa9b60 * This memory was allocated from: malloc [rtlib.o] Allocate_Aligned [memory.c:27] make_interpreter [interpreter.c:30] main [test_main.c:26] _start [crt1.o] PLK: 8192 bytes potentially leaked at 0xa7b08 * This memory was allocated from: malloc [rtlib.o] Allocate_Aligned [memory.c:27] make_interpreter [interpreter.c:29] main [test_main.c:26] _start [crt1.o] PLK: 8192 bytes potentially leaked at 0xb1bb8 * This memory was allocated from: malloc [rtlib.o] Allocate_Aligned [memory.c:27] make_interpreter [interpreter.c:31] main [test_main.c:26] _start [crt1.o] PLK: 8192 bytes potentially leaked at 0xb3c10 * This memory was allocated from: malloc [rtlib.o] Allocate_Aligned [memory.c:27] make_interpreter [interpreter.c:32] main [test_main.c:26] _start [crt1.o] PLK: 56 bytes potentially leaked at 0xa7a78 * This memory was allocated from: malloc [rtlib.o] Sys_Allocate [memory.c:35] make_interpreter [interpreter.c:24] main [test_main.c:26] _start [crt1.o] Purify Heap Analysis (combining suppressed and unsuppressed blocks) BlocksBytes Leaked 00 Potentially Leaked 665600 In-Use 1 8192 Total Allocated 773792 Purify instrumented test_prog (pid 17982) * Program exited with status code 0. * 1 access error, 3 total occurrences. * 0 bytes leaked. * 57400 bytes potentially leaked. * Basic memory usage (including Purify overhead): 462068 code 93516 data/bss 81920 heap (peak use) 2664 stack * Shared library memory usage (including Purify overhead): 1456 libpure_solaris2_init.so.1 (shared code) 252 libpure_solaris2_init.so.1 (private data) 141202 libm.so.1_pure_p3_c0_520_57_32_106368 (shared code) 1276 libm.so.1_pure_p3_c0_520_57_32_106368 (private data) 1051960 libc.so.1_pure_p3_c0_520_57_32_1115336 (shared code) 108024 libc.so.1_pure_p3_c0_520_57_32_1115336 (private data) 2316 libdl.so.1_pure_p3_c0_520_57_32_4528 (shared code) 4 libdl.so.1_pure_p3_c0_520_57_32_4528 (private data) 13528 libinternal_stubs.so.1 (shared code) 916 libinternal_stubs.so.1 (private data) 14284 libc_psr.so.1_pure_p3_c0_520_57_32 (shared code) 0 libc_psr.so.1_pure_p3_c0_520_57_32 (private data) * Memory mapped usage: 8192 mmap'd at 0xfebb perl assemble.pl t/test2.pasm > t/test2.pbc ./test_prog t/test2.pbc > t/test2.out Purify instrumented test_prog (pid 18081 at Thu Sep 13 02:12:41 2001) * Purify 5.2 Solaris 2 (32-bit), Copyright (C) 1992-2000 Rational So
Re: Using int32_t instead of IV for code
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
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 and no garbage collection. Simon
Re: another purify run
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: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 and no garbage collection. > > Simon
config.h.in
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 revision 1.1
diff -u -r1.1 config.h.in
--- config.h.in 2001/09/11 09:44:00 1.1
+++ config.h.in 2001/09/13 09:44:10
@@ -7,7 +7,7 @@
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef ${iv} IV;
-typedef ${iv} double NV;
+typedef ${nv} NV;
typedef struct _vtable VTABLE;
typedef void DPOINTER;
@@ -22,7 +22,7 @@
#define FRAMES_PER_INT_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_STR_REG_CHUNK FRAMES_PER_CHUNK
-#define MASK_CHUNK_LOW_BITS 0xf000
+#define MASK_CHUNK_LOW_BITS ((IV)~0x0fff)
${headers}
Quick success report for Win32
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 from classes. -- BKS __ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/
Re: #include "config.h" or #include "parrot/config.h"
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 directory portion of the > include filename. (And the suffix, generally, but that's separate) Hmm. So would you suggest adding -I[.include] -I[.include.parrot] for VMS as well? (My VMS days were a very long time ago.) > 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 :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: pasm.pl: a different parrot assembler
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 tested and ran all of the current
> > t/*.pasm files.
> >
> > Here it is...feedback is always welcome.
>
> Cool. Now, if it only handled abbreviated op names, I'd apply it... :)
>
> Simon
You, sir, are a very picky man. :)
Here it is...I tested it on this euclid.pasm:
MAIN: set I1, 96
set I2, 64
set I3, 0
set S1, "Algorithm E (Euclid's algorithm)"
print S1
E1: mod I4, I1, I2
E2: eq I4, I3, DONE, E3
E3: set I1, I2
set I2, I4
branch E1
DONE: print I2
end
Enjoy!
Brian
#! /usr/bin/perl -w
#
# pasm.pl - take a parrot assembly file and spit out a bytecode file
# This is based heavily on assemble.pl
# Brian Wheeler ([EMAIL PROTECTED])
use strict;
my $opt_c;
if (@ARGV and $ARGV[0] eq "-c") {
shift @ARGV;
$opt_c = 1;
}
# define data types
my(%pack_type)=('i'=>'l','n'=>'d');
my(%real_type)=('I'=>'i','i'=>'i',
'N'=>'i','n'=>'n',
'S'=>'i','s'=>'i',
'D'=>'i');
# compute sizes
my(%sizeof);
foreach (keys(%real_type)) {
$sizeof{$_}=length(pack($pack_type{$real_type{$_}},0));
}
# get opcodes from guts.
open GUTS, "interp_guts.h";
my %opcodes;
while () {
next unless /\tx\[(\d+)\] = ([a-z_]+);/;
$opcodes{$2}{CODE} = $1;
}
close GUTS;
# get opcodes and their arg lists
open OPCODES, ") {
next if /^\s*#/;
chomp;
s/^\s+//;
next unless $_;
my ($name, $args, @types) = split /\s+/, $_;
my @rtypes=@types;
@types=map { $_ = $real_type{$_}} @types;
$opcodes{$name}{ARGS} = $args;
$opcodes{$name}{TYPES} = [@types];
$opcodes{$name}{RTYPES}=[@rtypes];
}
close OPCODES;
# read source and assemble
my $pc=0; my $op_pc=0;
my ($bytecode,%label,%fixup,%constants,@constants);
my $line=0;
while(<>) {
$line++;
chomp;
s/^\s*//;
s/\s*$//;
next if(/^\#/ || $_ eq "");
if(m/^((\S+):)?\s*(.+)?/) {
my($label,$code)=($2,$3);
if(defined($label) && $label ne "") {
if(exists($label{$label})) {
error("'$label' already defined!");
}
if(exists($fixup{$label})) {
# backpatch everything with this PC.
while(scalar(@{$fixup{$label}})) {
my $op_pc=shift(@{$fixup{$label}});
my $offset=shift(@{$fixup{$label}});
substr($bytecode,$offset,4)=pack('l',($pc-$op_pc)/4);
}
delete($fixup{$label});
}
$label{$label}=$pc; # store it.
}
next if(!defined($code));
1 while $code=~s/\"([^\\\"]*(?:\\.[^\\\"]*)*)\"/constantize($1)/eg;
$code=~s/,/ /g;
my($opcode,@args)=split(/\s+/,$code);
$opcode=lc($opcode);
if (!exists $opcodes{$opcode}) {
# try to determine _real_ opcode.
my @arg_t=();
foreach (@args) {
if(m/^([INPS])\d+$/) {
# a register.
push @arg_t,lc($1);
} elsif(m/^\d+$/) {
# a constant of some sort
push @arg_t,'(ic|nc|sc)';
} else {
# a label
push @arg_t,'ic';
}
}
my $test;
my($first,$last)=($arg_t[0],$arg_t[-1]);
if($first ne $last) {
$test="$opcode\_$first\_$last";
} else {
$test="$opcode\_$first";
}
my($found_op)=0;
foreach my $op (grep($_=~/^$opcode/,keys(%opcodes))) {
if($op=~/$test/) {
$opcode=$op;
$found_op=1;
last;
}
}
error("No opcode $opcode in <$_>") if(!$found_op);
}
if (@args != $opcodes{$opcode}{ARGS}) {
error("Wrong arg count--got ".scalar(@args)." needed
".$opcodes{$opcode}{ARGS});
}
$bytecode .= pack "l", $opcodes{$opcode}{CODE};
$op_pc=$pc;
$pc+=4;
foreach (0..$#args) {
my($rtype)=$opcodes{$opcode}{RTYPES}[$_];
my($type)=$opcodes{$opcode}{TYPES}[$_];
if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq
"S") {
# its a register argument
$args[$_]=~s/^[INPS](\d+)$/$1/i;
$pc+=$sizeof{$rtype}
} elsif($rtype eq "D") {
# a destination
if(!exists($label{$args[$_]})) {
# we have not seen it yet...put it on the fixup list
push(@{$fixup{$args[$_]}},$op_pc,$pc);
$args[$_]=0x;
} else {
$args[$_]=($label{$args[$_]}-$op_pc)/4;
}
$pc+=$sizeof{$rtype};
} else {
$args[$_]=oct($args[$_]) if($args[$_]=~/^0/);
$pc+=$sizeof{$rtype};
Attention! Re: pasm.pl: a different parrot assembler
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 assembler. Simon
Re: [patch] First cut at TODO "allow add I4, I4, 3 instead ofadd_i_ic ..."
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 parser/compiler combo to generate > the bytecode automatically, so I don't think it's worth the effort. Simple > is OK at this level. :) I was thinking along the lines of having a complete assembly language for writing programs for the Parrot ISA, with all that that implies. If I'm the only one thinking that way, that's ok, but it just seems to me to be the right thing: A powerful ISA + A powerful assembler + multiple powerful language compilers. What, exactly, will be written directly in pasm? Low-level ops will be written in C, high-level stuff can be written in whatever language is built on top of PISA (Parrot Instruction Set Architecture). I was imagining a set of intermediate support stuff to be written in pasm. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Re: #include "config.h" or #include "parrot/config.h"
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 sufficient on > > some platforms. VMS, specifically, ignores the directory portion of the > > include filename. (And the suffix, generally, but that's separate) > > Hmm. So would you suggest adding -I[.include] -I[.include.parrot] for VMS > as well? (My VMS days were a very long time ago.) > > > 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 :-). Perhaps I'm missing something here, but I always thought that #include "config.h" rather than #include would ensure that the local Perl version would get always get picked up in preference.
[patch (really)] Removed opcode qualifers t/euclid.pasm to exerciseopcode inference
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)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/ Index: t/euclid.pasm === RCS file: /home/perlcvs/parrot/t/euclid.pasm,v retrieving revision 1.1 diff -u -r1.1 euclid.pasm --- t/euclid.pasm 2001/09/12 18:48:09 1.1 +++ t/euclid.pasm 2001/09/13 14:24:50 @@ -19,15 +19,15 @@ # E2: Is it zero? # E3: Reduce. # -MAIN: set_i_ic I1, 96 -set_i_ic I2, 64 -set_i_ic I3, 0 -set_s_sc S1, "Algorithm E (Euclid's algorithm)" -print_s S1 -E1: mod_i I4, I1, I2 -E2: eq_i_ic I4, I3, DONE, E3 -E3: set_i I1, I2 -set_i I2, I4 -branch_ic E1 -DONE: print_i I2 +main: setI1, 96 +setI2, 64 +setI3, 0 +setS1, "Algorithm E (Euclid's algorithm)" +print S1 +e1: modI4, I1, I2 +e2: eq I4, I3, done, e3 +e3: setI1, I2 +setI2, I4 +branch e1 +done: print I2 end
[patch] Removed opcode qualifers t/euclid.pasm to exercise opcodeinference
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)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
[PATCH]Assembler.pl
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.11
diff -u -r1.11 assemble.pl
--- assemble.pl 2001/09/13 13:42:41 1.11
+++ assemble.pl 2001/09/13 14:37:43
@@ -31,7 +31,7 @@
open GUTS, "interp_guts.h";
my %opcodes;
while () {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
+next unless /\tx\[(\d+)\] = ([a-z0-9_]+);/;
$opcodes{$2}{CODE} = $1;
}
close GUTS;
@@ -127,7 +127,7 @@
foreach (0..$#args) {
my($rtype)=$opcodes{$opcode}{RTYPES}[$_];
-my($type)=$opcodes{$opcode}{TYPES}[$_];
+my($type)=$pack_type{$opcodes{$opcode}{TYPES}[$_]};
if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq
"S") {
# its a register argument
patch: assemble.pl choosing wrong op sometimes...
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
112c112
< if($op=~/$test/) {
---
> if($op=~/^$test$/) {
Re: patch: assemble.pl choosing wrong op sometimes...
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: /home/perlcvs/parrot/assemble.pl,v
> retrieving revision 1.12
> diff -r1.12 assemble.pl
> 112c112
> < if($op=~/$test/) {
> ---
> > if($op=~/^$test$/) {
Unless $test is really a pattern here this is $op eq $test...
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
[patch] Us of opcode table fingerprints in assemble.pl anddisassemble.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 next issue would be making the interpreter do something with the
fingerprint...
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
? assemble.pl.diff
? fingerprint.diff
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.12
diff -u -r1.12 assemble.pl
--- assemble.pl 2001/09/13 14:38:31 1.12
+++ assemble.pl 2001/09/13 15:05:37
@@ -5,6 +5,7 @@
# Brian Wheeler ([EMAIL PROTECTED])
use strict;
+use Digest::MD5 qw(&md5_hex);
my $opt_c;
if (@ARGV and $ARGV[0] eq "-c") {
@@ -37,8 +38,10 @@
close GUTS;
# get opcodes and their arg lists
+my $opcode_table;
open OPCODES, ") {
+$opcode_table .= $_;
next if /^\s*#/;
chomp;
s/^\s+//;
@@ -51,7 +54,8 @@
$opcodes{$name}{RTYPES}=[@rtypes];
}
close OPCODES;
-
+my $opcode_fingerprint = md5_hex($opcode_table);
+constantize($opcode_fingerprint); # Make it constant zero.
# read source and assemble
my $pc=0; my $op_pc=0;
Index: disassemble.pl
===
RCS file: /home/perlcvs/parrot/disassemble.pl,v
retrieving revision 1.5
diff -u -r1.5 disassemble.pl
--- disassemble.pl 2001/09/13 07:21:37 1.5
+++ disassemble.pl 2001/09/13 15:05:37
@@ -5,6 +5,7 @@
# Turn a parrot bytecode file into text
use strict;
+use Digest::MD5 qw(&md5_hex);
my(%opcodes, @opcodes);
@@ -32,8 +33,10 @@
$opcodes{$2}{CODE} = $1;
}
+my $opcode_table;
open OPCODES, ") {
+$opcode_table .= $_;
next if /^\s*#/;
s/^\s+//;
chomp;
@@ -48,6 +51,7 @@
TYPES => [@types]
}
}
+my $opcode_fingerprint = md5_hex($opcode_table);
$/ = \4;
@@ -62,6 +66,7 @@
my $count=unpack('l', <>);
print "# Constants: $count entries ($constants bytes)\n";
print "# ID FlagsEncoding Type Size Data\n";
+my $constant_num = 0;
foreach (1..$count) {
my $flags=unpack('l',<>);
my $encoding=unpack('l',<>);
@@ -74,7 +79,12 @@
# strip off any padding nulls
$data=substr($data,0,$size);
printf("%04x: %08x %08x %08x %08x
%s\n",$_-1,$flags,$encoding,$type,$size,$data);
+
+ die "Cannot disassemble (differing opcode table)!" if $constant_num == 0 and
+$data ne $opcode_fingerprint;
+ $constant_num++;
}
+} else {
+warn "Disassembling without opcode table fingerprint!";
}
print "# Code Section\n";
my $offset=0;
Re: patch: assemble.pl choosing wrong op sometimes...
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
> > ===
> > RCS file: /home/perlcvs/parrot/assemble.pl,v
> > retrieving revision 1.12
> > diff -r1.12 assemble.pl
> > 112c112
> > < if($op=~/$test/) {
> > ---
> > > if($op=~/^$test$/) {
>
> Unless $test is really a pattern here this is $op eq $test...
>
It is a pattern. If you have a constant, it doesn't know what kind, so
the pattern it creates is "(ic|nc|sc)"
Brian
Re: #include "config.h" or #include "parrot/config.h"
--- 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 thing to keep in mind is that the directory may
> not be sufficient on
> > > some platforms. VMS, specifically, ignores the
> directory portion of the
> > > include filename. (And the suffix, generally, but
> that's separate)
> >
> > Hmm. So would you suggest adding -I[.include]
> -I[.include.parrot] for VMS
> > as well? (My VMS days were a very long time ago.)
> >
> > > 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 :-).
>
> Perhaps I'm missing something here, but I always thought
> that
>
> #include "config.h"
> rather than
> #include
>
> would ensure that the local Perl version would get always
> get picked up in
> preference.
>
The point is not us finding our config.h; the problem is if
we are embedded, we don't want to clobber our embedder's
config.h. (Besides, when we're being embedded, there're no
promises about what order the -I flags will be when we're
compiled. E.g.:
#include "parrot/embed.h" /* includes "parrot/config.h"
#include "project.h" /* includes "config.h" */
int call_parrot(...)
{
IV i;
...
#ifdef USE_FUNCTION_FOO
embedders_foo();
#endif
...
}
-- BKS
__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
patch: print op cleanups, new ops, assembler support of \(whatever)
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_nc).
Brian
? pasm.pl
? patch
? test2.pbc
? test3.pbc
? euclid0.pbc
? euclid1.pbc
? euclid.pbc
? print_cleanups.diff
? bitops.pbc
? bitops+assembler.patch
? t/bitops.pasm
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.12
diff -r1.12 assemble.pl
112c112
< if($op=~/$test/) {
---
> if($op=~/^$test$/) {
121,122c121
< error("Wrong arg count--got ".scalar(@args)." needed
< ".$opcodes{$opcode}{ARGS});
---
> error("Wrong arg count--got ".scalar(@args)." needed
>".$opcodes{$opcode}{ARGS});
131,132c130
< if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq
< "S") {
---
> if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq "S") {
219a218,220
> # handle \ characters in the constant
> my %escape = ('a'=>"\a",'n'=>"\n",'r'=>"\r",'t'=>"\t",'\\'=>'\\',);
> $s=~s/\\([anrt\\])/$escape{$1}/g;
223a225
>
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.13
diff -r1.13 basic_opcodes.ops
120c120
< printf("I reg %li is %li\n", P1, INT_REG(P1));
---
> printf("%li", INT_REG(P1));
121a122,127
>
> /* PRINT ic */
> AUTO_OP print_ic {
> printf("%li", P1);
> }
>
212c218
< printf("N reg %li is %f\n", P1, NUM_REG(P1));
---
> printf("%f", NUM_REG(P1));
214a221,225
> /* PRINT nc */
> AUTO_OP print_nc {
> printf("%f", P1);
> }
>
317c328,334
bufstart);
---
> printf("%.*s",(int)string_length(s),(char *) s->bufstart);
> }
>
> /* PRINT sc */
> AUTO_OP print_sc {
> STRING *s = Parrot_string_constants[P1];
> printf("%.*s",(int)string_length(s),(char *) s->bufstart);
318a336
>
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.12
diff -r1.12 opcode_table
56a57
> print_sc 1 s
86a88
> print_ic 1 i
88a91
> print_nc 1 n
Re: #include "config.h" or #include "parrot/config.h"
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 sufficient on > > some platforms. VMS, specifically, ignores the directory portion of the > > include filename. (And the suffix, generally, but that's separate) > >Hmm. So would you suggest adding -I[.include] -I[.include.parrot] for VMS >as well? (My VMS days were a very long time ago.) It's not the compiler switches. That's just a portability issue. The issue is making sure we can safely differentiate between, say, our strings.h and the system one. Prepending a directory isn't necessarily enough to make sure that happens. I'm not sure that #include "parrot/strings.h" is any safer than #include "strings.h" and I know less-recent versions of Dec C did what I'd consider counter-intuitive (from a Unix perspective, at least) things with path prefixes on headers. It's usually just a problem with system headers, but I remember being bit with user headers. (Our system headers aren't actual separate files--they're just entries in one big text library) > > 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 include DOS-only machines. I don't think we should actively discourage them, but neither do I think we should be bound by their limitations. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using int32_t instead of IV for code
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 answer to get things working--a first > > draft if you will. It needs rewriting so all the ops are I32 and the > > floating point constants are N64s. > >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. IVs generally should be. >Also, if we've got a system with 64 bit IVs, are the arguments to Parrot >opcodes going to be 32 or 64 bit? If 32 bit, is there going to be any >way of loading a 64 bit constant? We may have a way to embed larger constants into the constant area rather than in the bytecode stream itself. I don't think we're going to have inline 64-bit constants, though. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: #include "config.h" or #include "parrot/config.h"
> > > 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 include DOS-only machines. I Tsk, tsk. > don't think we should actively discourage them, but neither do I think we > should be bound by their limitations. If we want to be nice about this we should have enough metadata about any embedded filenames to be able to convert those to help less forturnate filesystems. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Patch to fix C++ style comments
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 while. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: jsr_ic & ret support
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 no bounds checking, but its >enough to get started. I'm working on the generic call/push stack code now. We should have proper single-register pushing and jsr/return support as soon as I finish digging out from under perl6-internals... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH]Transcendental Math Functions
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 samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using int32_t instead of IV for 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 such a waste") being bandied around, without
>much hard numbers to support the claims. IV is usually the native
>integer datatype of the CPU which means that it will run fast.
>Unless you are thinking of huge and/or multidimensional arrays
>of tightly packed integers, I don't think you should care.
FWIW, test runs I did on Alpha systems clocked 32-bit ints as faster than
64-bit ones. It was a little surprising, but ultimately ended up being a
bandwidth issue--the time spent doing the extra twiddling to get only the
32-bit portion of the integers was less than the time to get the larger
values in from memory.
Granted, this was on a TurboLaser, which is seriously backplane bandwidth
limited these days, so it's not representative of modern Alpha hardware,
but 32 bits seemed sufficient for our purposes as inlined integer constants
and opcode parameters/numbers/whatever.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: print_n doesn't work?
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 beginning to regret doing this. :( Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch: Common opcode_table parsing
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 exported by the Parrot > > code need a prefix. > >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? We're almost never going to be calling opcode functions by name in the core, the core build doesn't care since all that stuff is autogenerated, and nobody had better be calling these functions from extensions, so... I say we munge 'em. Throw a parrot_op_ prefix on them in the preprocessing stage and be done with it. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to fix += on rvalue
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 seems that gcc allows > > you to get away with this, but other compiler don't. > >Naughty, naughty. Thanks, applied. There's a *reason* I'm designing rather than writing all the code... (It's amazing how many bad habits of mine have already been exposed) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to fix arithmetic on void * pointers
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 it assumes a >pointer will fit in an IV and I'm not sure that will always be true >will it? Anyway with this patch and the others it now builds on >a Unixware box with the system compiler: IVs will always be large enough to hold pointers, so this should be OK. If you'd rather (And I think it'd be a good idea) we can define a set of types for specific purposes. One for pointer abuse, one for opcodes, one for opcode constants (well, two, one integer and one float), and probably some more I can't remember at the moment. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: another purify run
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 doing something wrong somewhere. >At 10:18 on 09/13/2001 BST, Simon Cozens <[EMAIL PROTECTED]> wrote: > > > 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 and no garbage collection. > > > > Simon Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Yet another patch: assemble.pl - better opcode guessing
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
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.12
diff -r1.12 assemble.pl
95,97d94
< } elsif(m/^\d+$/) {
< # a constant of some sort
< push @arg_t,'(ic|nc|sc)';
99,100c96,109
< # a label
< push @arg_t,'ic';
---
> # a constant of some sort
> if(m/^\[(\d+)\]$/) {
> # string
> push @arg_t,'sc';
> } elsif(m/^((-?\d+)|(0b[01]+)|(0x[0-9a-f]+))$/i) {
> # integer
> push @arg_t,'ic';
> } elsif(m/^[a-z][\w]*$/i) {
> # label
> push @arg_t,'ic';
> } else {
> # numeric
> push @arg_t,'nc';
> }
109a119
> print STDERR "test: $test\n";
112c122
< if($op=~/$test/) {
---
> if($op eq $test) {
121,122c131
< error("Wrong arg count--got ".scalar(@args)." needed
< ".$opcodes{$opcode}{ARGS});
---
> error("Wrong arg count--got ".scalar(@args)." needed
>".$opcodes{$opcode}{ARGS});
131,132c140
< if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq
< "S") {
---
> if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq "S") {
145a154,156
> } elsif($rtype eq 's') {
> $args[$_]=~s/[\[\]]//g;
> $pc+=$sizeof{$rtype};
220,222c231,238
< return $constants{$s} if exists $constants{$s};
< push @constants, $s;
< return $constants{$s} = $#constants;
---
> # handle \ characters in the constant
> my %escape = ('a'=>"\a",'n'=>"\n",'r'=>"\r",'t'=>"\t",'\\'=>'\\',);
> $s=~s/\\([anrt\\])/$escape{$1}/g;
> if(!exists($constants{$s})) {
> push(@constants,$s);
> $constants{$s}=$#constants;
> }
> return "[".$constants{$s}."]";
223a240
>
Re: patch: print op cleanups, new ops, assembler support of \(whatever)
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 constants is also supported, but > alas, you have to specify the type (print_sc, print_ic, print_nc). Cool, thanks.
Re: [patch] Us of opcode table fingerprints in assemble.pl and disassemble.pl
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
Re: patch: assemble.pl choosing wrong op sometimes...
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. :)
Re: PDD 6 (parrot assembly) now in CVS
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 249 to 261 seem to duplicate 204 to 216. D'oh! Thanks, fixed. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6 (parrot assembly) now in CVS
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
CVS update mailing list
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 --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6 (parrot assembly) now in CVS
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 duplicate headers (=item, =head1, =head2, =head3), run MD5 checksums on paragraphs, and other mildly interesting things. Anyone care to take a shot at it? I hear there's a good text-processing language on the net somewhere we could grab and use... ;-) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6 (parrot assembly) now in CVS
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 === RCS file: /home/perlcvs/parrot/docs/parrot_assembly.pod,v retrieving revision 1.1 diff -u -3 -p -r1.1 parrot_assembly.pod --- docs/parrot_assembly.pod2001/09/12 15:44:40 1.1 +++ docs/parrot_assembly.pod2001/09/13 16:06:44 @@ -246,20 +246,6 @@ omitted, increment is 1. Decrement register x by nn. nn is an integer constant. If nn is omitted, decrement by 1. -=item iton Nx, Iy - -Copy the integer value from register y to the numeric register x. - -=item ntoi Ix, Ny - -Copy the number from register y to register x. Copy is truncated, and -may be capped if it is too large or small for an integer. - -=item tostring Sx, ty, Iz - -Take the value in register y and convert it to a string of type z, -storing the result in string register x. - =back =head2 Transcendental operations
Test ( was: Re: Things we need to do. )
> 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:
* what other functions are required?
* where should tests reside? ( t/op/*.t, t/misc/*.t, etc? )
* where should helper perl5 modules go?
( lib/Test/Parrot.pm ? )
To Schwern:
* Test::Parrot ( or whatever ), needs to be special cased
in Test::Simple::ok ( as Test::More is ), to report test
line correctly.
Regards
Mattia
use strict;
use lib 'lib';
use Test::Parrot;
Test::Parrot::output_is( <
#
package Test::Parrot;
require File::Spec;
use Test::More qw(no_plan);
use strict;
# this kludge is an hopefully portable way of having
# redirections ( tested on Linux and Win2k )
sub _run_command {
my( $command, %redir ) = @_;
my( $redir_string );
while( my @dup = each %redir ) {
my( $from, $to ) = @dup;
if( $to eq 'STDERR' ) { $to = "qq{>&STDERR}" }
elsif( $to eq 'STDOUT' ) { $to = "qq{>&STDOUT}" }
elsif( $to eq '/dev/null' ) { $to = ( $^O eq 'MSWin32' ) ?
'qq{> NUL:}' : "qq{> $to}" }
else { $to = "qq{> $to}" }
$redir_string .= "open $from, $to;"
}
system "perl -e \"$redir_string;system qq{$command};\"";
}
sub output_is($$) {
my( $assembly, $output ) = @_;
local( *ASSEMBLY, *OUTPUT );
my( $as_f, $by_f, $out_f ) = qw(test.pasm test.pbc test.out);
open ASSEMBLY, "> $as_f" or die "Unable to open '$as_f'";
binmode ASSEMBLY;
print ASSEMBLY $assembly;
close ASSEMBLY;
_run_command( "perl assemble.pl $as_f", 'STDOUT' => $by_f );
_run_command( "./test_prog $by_f", 'STDOUT' => $out_f );
my $prog_output;
open OUTPUT, "< $out_f";
{
local $/ = undef;
$prog_output = ;
}
close OUTPUT;
Test::More::is( $prog_output, $output );
}
1;
Re: Using int32_t instead of IV for code
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 freely typecast between the two.
The language lawyer in me insists that I point out that this is
inherently nonportable. C does not guarantee that it is possible to
convert losslessly between pointers and integers; there have been
systems on which this was impossible (or hugely inefficient) for
hardware reasons.
The correct approach to storing pointers and integerss in the same
value is to use a union. Personally, I would use:
typedef union {
int i;
void *p;
} IV;
I realize that I'm probably in a minority of one on this. :>
> Also, if we've got a system with 64 bit IVs, are the arguments to Parrot
> opcodes going to be 32 or 64 bit? If 32 bit, is there going to be any
> way of loading a 64 bit constant?
This reminds me of something I've been meaning to ask: Is Parrot byte
code intended to be network-portable?
- Damien
Re: Using int32_t instead of IV for code
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
Re: #include "config.h" or #include "parrot/config.h"
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 > > #include "config.h" > rather than > #include > > would ensure that the local Perl version would get always get picked up in > preference. Yes, while you're building Parrot, you're probably right. However, you're missing at least two things: 1. First, suppose that Parrot's header files (including config.h) have been installed into /usr/local/parrot/include/... and that someone else has installed a different config.h into /usr/local/include. Now, imagine that you're building an add-on module or embedding Parrot into another application, and you want to compile and include some of your /usr/local/ stuff. If you do cc -I/usr/local/include -I/usr/local/parrot/include/ which "config.h" will you get? The wrong one. Sure, you can rearrange the order of the -I directives, but that's not always easy to do (may involve editing a Makefile or series of Makefiles) and indicates a fragility of design that we'd like to avoid. 2. If parrot.h contains #include "config.h", then "obviously", the C compiler will look for "config.h" in the same directory as it found "parrot.h" even if there's a "config.h" earlier in the include chain (e.g. in /usr/local/include). Right? Alas, no. I don't recall the platform (and can't easily think of p5p archive keywords to narrow a search), but I'm sure I received a credible report to the contrary -- possibly from a Windows C/C++ compiler -- at some point in the past. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: #include "config.h" or #include "parrot/config.h"
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 buggering you up. Nat
RE: Using int32_t instead of IV for code
> 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 stuff with code stream. > > Also, if we've got a system with 64 bit IVs, are the arguments to Parrot > opcodes going to be 32 or 64 bit? If 32 bit, is there going to be any > way of loading a 64 bit constant? The arguments are always 32-bit. For larger constant, such as 64-bit int, number, bigint/bigfloat/string, you must use constant pool. There is not much benefit to embed 64-bit value into code stream, since it is rarely used and bloat up everything else. Hong
[patch] Complete Opcode Table Fingerprinting
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.pl, disassemble.pl, and
interpreter.c.
A musician, if he's a messenger, is like a child who
hasn't been handled too many times by man,
hasn't had too many fingerprints across his brain.
-- James Marshall Hendrix
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
? fingerprint.diff
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.12
diff -u -r1.12 assemble.pl
--- assemble.pl 2001/09/13 14:38:31 1.12
+++ assemble.pl 2001/09/13 17:07:19
@@ -5,6 +5,7 @@
# Brian Wheeler ([EMAIL PROTECTED])
use strict;
+use Digest::MD5 qw(&md5_hex);
my $opt_c;
if (@ARGV and $ARGV[0] eq "-c") {
@@ -37,8 +38,10 @@
close GUTS;
# get opcodes and their arg lists
+my $opcode_table;
open OPCODES, ") {
+$opcode_table .= $_;
next if /^\s*#/;
chomp;
s/^\s+//;
@@ -51,7 +54,8 @@
$opcodes{$name}{RTYPES}=[@rtypes];
}
close OPCODES;
-
+my $opcode_fingerprint = md5_hex($opcode_table);
+constantize($opcode_fingerprint); # Make it constant zero.
# read source and assemble
my $pc=0; my $op_pc=0;
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.3
diff -u -r1.3 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/11 22:21:16 1.3
+++ build_interp_starter.pl 2001/09/13 17:07:19
@@ -1,5 +1,6 @@
# !/usr/bin/perl -w
use strict;
+use Digest::MD5 qw(&md5_hex);
open INTERP, "> interp_guts.h" or die "Can't open interp_guts.h, $!/$^E";
@@ -18,8 +19,10 @@
#define BUILD_TABLE(x) do { \\
CONST
+my $opcode_table;
my $count = 1;
while () {
+$opcode_table .= $_;
chomp;
s/#.*$//;
s/^\s+//;
@@ -30,8 +33,11 @@
print INTERP "\tx[$num] = $name; \\\n";
$count++ unless $name eq 'end';
}
+close OPCODES;
+my $opcode_fingerprint = md5_hex($opcode_table);
print INTERP "} while (0);\n";
+
# Spit out the DO_OP function
print INTERP <) {
+$opcode_table .= $_;
next if /^\s*#/;
s/^\s+//;
chomp;
@@ -48,6 +51,7 @@
TYPES => [@types]
}
}
+my $opcode_fingerprint = md5_hex($opcode_table);
$/ = \4;
@@ -62,6 +66,7 @@
my $count=unpack('l', <>);
print "# Constants: $count entries ($constants bytes)\n";
print "# ID FlagsEncoding Type Size Data\n";
+my $constant_num = 0;
foreach (1..$count) {
my $flags=unpack('l',<>);
my $encoding=unpack('l',<>);
@@ -74,7 +79,12 @@
# strip off any padding nulls
$data=substr($data,0,$size);
printf("%04x: %08x %08x %08x %08x
%s\n",$_-1,$flags,$encoding,$type,$size,$data);
+
+ die "Cannot disassemble (differing opcode table)!" if $constant_num == 0 and
+$data ne $opcode_fingerprint;
+ $constant_num++;
}
+} else {
+warn "Disassembling without opcode table fingerprint!";
}
print "# Code Section\n";
my $offset=0;
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.6
diff -u -r1.6 interpreter.c
--- interpreter.c 2001/09/11 22:21:17 1.6
+++ interpreter.c 2001/09/13 17:07:19
@@ -13,6 +13,24 @@
time through */
IV *(*func)();
void **temp;
+
+ if (Parrot_num_string_constants == 0) {
+printf("Warning: Bytecode does not include opcode table fingerprint!\n");
+ } else {
+const char * fp_data;
+IV fp_len;
+
+fp_data = Parrot_string_constants[0]->bufstart;
+fp_len = Parrot_string_constants[0]->buflen;
+
+if (strncmp(OPCODE_FINGERPRINT, fp_data, fp_len)) {
+ printf("Error: Opcode table fingerprint in bytecode does not match
+interpreter!\n");
+ printf(" Bytecode:%*s\n", -fp_len, fp_data);
+ printf(" Interpreter: %s\n", OPCODE_FINGERPRINT);
+ exit(1);
+}
+ }
+
while (*code) {
DO_OP(code, temp, func, interpreter);
}
Re: String API
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_destroy(STRING *s) > > *cough* Namespace pollution *cough* > > These should proably all be prefixed... Especially since all function names starting with str are strictly speaking reserved to ANSI/ISO for future expansion of the string.h facilities ;-) Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
What about arrays?
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 we'll make_object P1, "ARRAY" # Handles memory allocation somehow call_method P1, "push" # How to pass in args? call_method P1, "DESTROY" # Or, is there another way? Dan? Simon? Are we far away from this, or getting close? Are we implementing the guts of such things in C and accessing via PMC and methods, or are we implementing ops for vectors-of-pointers on top of which the ARRAY API will be built? I'd at least like to know enough about how its going to look so a sample program can be exhibited. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Re: What about arrays?
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 individual array entries out. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using int32_t instead of IV for code
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 integers] Well, sort of. More precisely, an IV is definitely supposed to be big enough to hold a pointer. The reverse isn't necessarily true. If you build with -Duse64bitall, for example, you might well end up with 32-bit pointers but 64-bit IVs and UVs. Perl does do some integer to pointer casts (see the INT2PTR stuff in perl.h), but it's only supposed to do those in restricted situations where we "know" that the int will actually fit into the pointer. >Is that portable enough for you? Don't we also still have ptr-vs-int alignment issues with one of the big iron systems? Sorry I don't recall any more details. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Using int32_t instead of IV for code
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 guaranteed to be the same width as a pointer, so > > we can freely typecast between the two. > >The language lawyer in me insists that I point out that this is >inherently nonportable. C does not guarantee that it is possible to >convert losslessly between pointers and integers; there have been >systems on which this was impossible (or hugely inefficient) for >hardware reasons. Oddly enough (given I wrote the code in question... :) I'm painfully aware of this. The code in memory.c is pretty much a placeholder, there to provide basic functionality but we will have something a lot better. (There's no provision for GC, it leaks like a sieve, is horribly wasteful, and is about as portable as your average 12-ton rock) Once we get things a bit more stable and documented, memory.c needs to be completely trashed and redone. > > Also, if we've got a system with 64 bit IVs, are the arguments to Parrot > > opcodes going to be 32 or 64 bit? If 32 bit, is there going to be any > > way of loading a 64 bit constant? > >This reminds me of something I've been meaning to ask: Is Parrot byte >code intended to be network-portable? Yes. The bytecode will have word length and byte-ordering markers embedded in it. When the bytecode loader finds 'inefficient' bytecode it will, instead of mmapping it in, process it in and build a more efficient in-memory version. (I expect generally that'll be restricted to big/little endian issues, but for platforms that don't do 32-bit integers, or do them really slowly relative to 64-bit ones, that'll mean expanding things appropriately) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6 (parrot assembly) now in CVS
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 :-) > > That's actually an interesting thing to consider. We could check for > duplicate headers (=item, =head1, =head2, =head3), run MD5 checksums on > paragraphs, and other mildly interesting things. > > Anyone care to take a shot at it? I hear there's a good text-processing > language on the net somewhere we could grab and use... ;-) Yeah, someone really should implement such a language. Interesting in the context of testing dox could be, Dr. Dobb's, #323 April 2001, p. 145, "Suffix Arrays" by Jon Bentley. Listing One is stated to have "found the longest repeated string in the 4,460,056 character's of the King James Bible in about 36 seconds on a 600-MHz Celeron processor". Have fun, Buggs
RE: [PATCH]Assembler.pl
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
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.14
diff -u -r1.14 assemble.pl
--- assemble.pl 2001/09/13 16:29:24 1.14
+++ assemble.pl 2001/09/13 17:38:42
@@ -31,7 +31,7 @@
open GUTS, "interp_guts.h";
my %opcodes;
while () {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
+next unless /\tx\[(\d+)\] = ([a-z0-9_]+);/;
$opcodes{$2}{CODE} = $1;
}
close GUTS;
@@ -135,7 +135,7 @@
foreach (0..$#args) {
my($rtype)=$opcodes{$opcode}{RTYPES}[$_];
-my($type)=$opcodes{$opcode}{TYPES}[$_];
+my($type)=$pack_type{$opcodes{$opcode}{TYPES}[$_]};
if($rtype eq "I" || $rtype eq "N" || $rtype eq "P" || $rtype eq
"S") {
# its a register argument
$args[$_]=~s/^[INPS](\d+)$/$1/i;
A quick note on The Big Picture
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* at the moment) * On-disk bytecode files * Documented public APIs for embedders and extension writers * The assembly language Or, basically, anything in a PDD. Things that are *not* cast in stone: * All the source So, while critiques of the source as it currently stands are *very* welcome (no, really, they are!), it's best to not assume that the final interpreter will use the code you think is nasty now. (Of course, pointing out (and fixing, though that's optional) the problems helps fix them) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH]coding standards
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 changed the name to mem_sys_memcopy, but I didn't uppercase
it because I thought it might be changed to a function sometime in the
future and we wouldn't want to have to go through and lowercase it then. If
ya'll would like, I can uppercase it. Also, functions such as
int main()
were changed to:
int
main()
according to the PDD.
I'll keep looking for other coding standard changes.
Thanks!
Tanton
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.5
diff -u -r1.5 bytecode.c
--- bytecode.c 2001/09/12 09:54:46 1.5
+++ bytecode.c 2001/09/13 18:52:14
@@ -72,7 +72,7 @@
num = GRAB_IV(program_code);
len -= sizeof(IV);
-Parrot_string_constants = Allocate_Aligned(num * sizeof(STRING*));
+Parrot_string_constants = mem_allocate_aligned(num * sizeof(STRING*));
while (len > 0) {
IV flags= GRAB_IV(program_code);
Index: global_setup.c
===
RCS file: /home/perlcvs/parrot/global_setup.c,v
retrieving revision 1.2
diff -u -r1.2 global_setup.c
--- global_setup.c 2001/09/10 09:53:14 1.2
+++ global_setup.c 2001/09/13 18:52:14
@@ -9,6 +9,7 @@
#define INSIDE_GLOBAL_SETUP
#include "parrot.h"
-void init_world() {
+void
+init_world() {
string_init(); /* Set up the string subsystem */
}
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.6
diff -u -r1.6 interpreter.c
--- interpreter.c 2001/09/11 22:21:17 1.6
+++ interpreter.c 2001/09/13 18:52:14
@@ -8,7 +8,8 @@
#include "parrot.h"
#include "interp_guts.h"
-void runops (struct Perl_Interp *interpreter, IV *code) {
+void
+runops (struct Perl_Interp *interpreter, IV *code) {
/* Move these out of the inner loop. No need to redeclare 'em each
time through */
IV *(*func)();
@@ -18,18 +19,19 @@
}
}
-struct Perl_Interp *make_interpreter() {
+struct Perl_Interp *
+make_interpreter() {
struct Perl_Interp *interpreter;
/* Get an empty interpreter from system memory */
- interpreter = Sys_Allocate(sizeof(struct Perl_Interp));
+ interpreter = mem_sys_allocate(sizeof(struct Perl_Interp));
/* Set up the memory allocation system */
- Setup_Allocator(interpreter);
+ mem_setup_allocator(interpreter);
/* Set up the initial register chunks */
- interpreter->int_reg_base = Allocate_Aligned(sizeof(struct IRegChunk));
- interpreter->num_reg_base = Allocate_Aligned(sizeof(struct NRegChunk));
- interpreter->string_reg_base = Allocate_Aligned(sizeof(struct
SRegChunk));
- interpreter->pmc_reg_base = Allocate_Aligned(sizeof(struct PRegChunk));
+ interpreter->int_reg_base = mem_allocate_aligned(sizeof(struct
IRegChunk));
+ interpreter->num_reg_base = mem_allocate_aligned(sizeof(struct
NRegChunk));
+ interpreter->string_reg_base = mem_allocate_aligned(sizeof(struct
SRegChunk));
+ interpreter->pmc_reg_base = mem_allocate_aligned(sizeof(struct
PRegChunk));
/* Set up the initial register frame pointers */
interpreter->int_reg = &interpreter->int_reg_base->IReg[0];
@@ -64,15 +66,15 @@
Parrot_clear_p(interpreter);
/* Need a default stack */
- interpreter->stack_base = Allocate_New_Stack();
+ interpreter->stack_base = mem_allocate_new_stack();
/* Need an empty stash */
- interpreter->perl_stash = Allocate_New_Stash();
+ interpreter->perl_stash = mem_allocate_new_stash();
/* The default opcode function table would be a good thing here... */
{
void **foo;
-foo = Sys_Allocate(2048 * sizeof(void *));
+foo = mem_sys_allocate(2048 * sizeof(void *));
BUILD_TABLE(foo);
Index: memory.c
===
RCS file: /home/perlcvs/parrot/memory.c,v
retrieving revision 1.3
diff -u -r1.3 memory.c
--- memory.c2001/09/12 17:58:55 1.3
+++ memory.c2001/09/13 18:52:14
@@ -7,7 +7,8 @@
#include "parrot.h"
/* Allocate a chunk of memory aligned on a power-of-2 boundary */
-void *Allocate_Aligned(IV size) {
+void *
+mem_allocate_aligned(IV size) {
IV max_to_alloc;
IV mask;
IV i;
@@ -31,11 +32,13 @@
return mem;
}
-void *Sys_Allocate(IV size) {
+void *
+mem_sys_allocate(IV size) {
return malloc(size);
}
-void Setup_Allocator(struct Perl_Interp *interpreter) {
+void
+mem_setup_allocator(struct Perl_Interp *interpreter) {
}
Index: memory.h
===
RCS file: /home/perlcvs/parrot/memory.h,v
retrieving revision 1.2
diff -u -r1.2 memory.h
--- memory.
patch: bitops with constants
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
? const_bitops.diff
? bitops.pbc
? t/bitops.pasm
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.14
diff -u -r1.14 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/13 16:16:38 1.14
+++ basic_opcodes.ops 2001/09/13 19:13:43
@@ -562,6 +562,12 @@
INT_REG(P1) = INT_REG(P2) & INT_REG(P3);
}
+/* AND_i_ic */
+AUTO_OP and_i_ic {
+ INT_REG(P1) = INT_REG(P2) & P3;
+}
+
+
/* NOT_i */
AUTO_OP not_i {
INT_REG(P1) = ! INT_REG(P2);
@@ -572,17 +578,37 @@
INT_REG(P1) = INT_REG(P2) | INT_REG(P3);
}
+/* OR_i_ic */
+AUTO_OP or_i_ic {
+ INT_REG(P1) = INT_REG(P2) | P3;
+}
+
/* SHL_i_ic */
AUTO_OP shl_i_ic {
INT_REG(P1) = INT_REG(P2) << P3;
}
+/* SHL_i */
+AUTO_OP shl_i {
+ INT_REG(P1) = INT_REG(P2) << INT_REG(P3);
+}
+
/* SHR_i_ic */
AUTO_OP shr_i_ic {
INT_REG(P1) = INT_REG(P2) >> P3;
}
+/* SHR_i */
+AUTO_OP shr_i {
+ INT_REG(P1) = INT_REG(P2) >> INT_REG(P3);
+}
+
/* XOR_i */
AUTO_OP xor_i {
INT_REG(P1) = INT_REG(P2) ^ INT_REG(P3);
+}
+
+/* XOR_i_ic */
+AUTO_OP xor_i_ic {
+ INT_REG(P1) = INT_REG(P2) ^ P3;
}
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.13
diff -u -r1.13 opcode_table
--- opcode_table2001/09/13 16:16:38 1.13
+++ opcode_table2001/09/13 19:13:44
@@ -152,9 +152,15 @@
# Bitwise Ops
and_i 3 I I I
+and_i_ic 3 I I i
not_i 2 I I
or_i 3 I I I
+or_i_ic3 I I i
+shl_i 3 I I I
shl_i_ic 3I I i
+shr_i 3 I I I
shr_i_ic 3I I i
xor_i 3 I I I
+xor_i_ic 3 I I i
+
patch - strnative.c grows incorrectly
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 === RCS file: /home/perlcvs/parrot/strnative.c,v retrieving revision 1.5 diff -u -r1.5 strnative.c --- strnative.c 2001/09/13 08:44:08 1.5 +++ strnative.c 2001/09/13 19:57:42 @@ -26,7 +26,7 @@ /* b is now in native format */ string_grow(a, a->strlen + b->strlen); -Sys_Memcopy(a->bufstart + a->strlen, b->bufstart, b->strlen); +mem_sys_memcopy(a->bufstart + a->strlen, b->bufstart, b->strlen); a->strlen = a->bufused = a->strlen + b->strlen; return a; } @@ -46,8 +46,8 @@ dest->encoding = &(Parrot_string_vtable[enc_native]); /* Offset and length have already been "normalized" */ -string_grow(dest, src->strlen - length); -Sys_Memcopy(dest->bufstart, src->bufstart + offset, length); +string_grow(dest, length); +mem_sys_memcopy(dest->bufstart, src->bufstart + offset, length); dest->strlen = dest->bufused = length; return dest;
PDD in CVS
Will the coding standard get assigned a PDD number and be put into CVS? Just wondering, Tanton
patch: assembly listings from assembler
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
--listing=file
--checksyntax
* produces verbose listing of what the assembler saw :) Only one
nitpick with it: unknown symbols are given as 0x,
unfortunately, this includes symbols which may be defined later in the
file (i.e. forward jumps).
Brian
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 (@ARGV and $ARGV[0] eq "-c") {
< shift @ARGV;
< $opt_c = 1;
---
> my %options;
> GetOptions(\%options,('checksyntax',
> 'help',
> 'version',
> 'verbose',
> 'output=s',
> 'listing=s'));
>
> if($options{'version'}) {
> print $0,'Version $Id$ ',"\n";
> exit;
> }
>
> if($options{'help'}) {
> print "$0 - Parrot Assembler
> Options:
>--checksyntaxCheck assembler syntax only, no output
>--help This text
>--listingDump assembly listing to file
>--output File to dump bytecode into
>--verboseShow what's going on
>--versionShow assembler version
> ";
> exit;
14a36,44
> if(exists($options{'output'}) && $options{'output'} eq "") {
> print STDERR "You must provide a file with --output flag!\n";
> exit;
> }
>
> if(exists($options{'listing'}) && $options{'listing'} eq "") {
> print STDERR "You must provide a file with --listing flag!\n";
> exit;
> }
54a85,87
> my $listing="PARROT ASSEMBLY LISTING - ".scalar(localtime)."\n\n";
>
>
62a96
> my $sline=$_;
65c99,104
< next if(/^\#/ || $_ eq "");
---
> if(/^\#/ || $_ eq "") {
> if($options{'listing'}) {
> $listing.=sprintf("%4d %08x %-44s %s\n", $line, $op_pc, '',$sline);
> }
> next;
> }
121a161
> log_message("substituting $op for $opcode");
161a202,209
> if($options{'listing'}) {
> # add line to listing.
> my $odata;
> foreach (unpack('l*',substr($bytecode,$op_pc))) {
> $odata.=sprintf("%08x ",$_);
> }
> $listing.=sprintf("%4d %08x %-44s %s\n", $line, $op_pc, $odata,$sline);
> }
163a212
> $listing.="\n" if($options{'listing'});
173c222,229
< # FIXUP
---
> # FIXUP (also, dump listing symbols)
> if($options{'listing'}) {
> $listing.="DEFINED SYMBOLS:\n";
> foreach (sort(keys(%label))) {
> $listing.=sprintf("\t%08x %s\n",$label{$_},$_);
> }
> }
>
184c240,244
< exit;
---
> $listing.="\nUNDEFINED SYMBOLS:\n";
> foreach (sort(keys(%fixup))) {
> $listing.="\t$_\n";
> }
> exit; # some day, unresolved symbols won't be an error!
195a256,258
> if($options{'listing'}) {
> $listing.="\nSTRING CONSTANTS\n";
> }
196a260
> my $counter=0;
204c268,271
<}
---
> }
> $listing.=sprintf("\t%04x %08x [[%s]]\n",$counter,length($_),$_)
> if($options{'listing'});
> $counter++;
217,218c284,298
< if(!$opt_c) {
< print $output;
---
> if(!$options{'checksyntax'}) {
> if($options{'output'} ne "") {
> open O,">$options{'output'}" || die $!;
> print O $output;
> close O;
> } else {
> print $output;
> }
> }
>
>
> if($options{'listing'}) {
> open L,">$options{'listing'}" || die $!;
> print L $listing;
> close L;
224a305,311
> }
>
> sub log_message {
> my($message)=@_;
> if($options{'verbose'}) {
> print STDERR "INFO ($line): $message\n";
> }
Re: Using int32_t instead of IV for code
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 needs rewriting so all the ops are I32 and the
> floating point constants are N64s. (Whether you can play Pokemon Stadium or
> not on your floats is a question I'm not touching... :)
>
> Patches welcome (with configure patches to choose the right type), and I'll
> see about fixing it up tomorrow if nobody's got a chance before that.
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 works on both my Alpha and i386 boxen...
Phil
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.14
diff -u -r1.14 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/13 16:16:38 1.14
+++ basic_opcodes.ops 2001/09/13 20:30:51
@@ -122,7 +122,7 @@
/* PRINT ic */
AUTO_OP print_ic {
- printf("%li", P1);
+ printf("%li", (IV)P1);
}
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.5
diff -u -r1.5 bytecode.c
--- bytecode.c 2001/09/12 09:54:46 1.5
+++ bytecode.c 2001/09/13 20:30:51
@@ -21,7 +21,7 @@
#include "parrot.h"
-#define GRAB_IV(x) *((IV*)*x)++
+#define GRAB_BYTECODE(x) *((int32_t*)*x)++
/*
@@ -40,7 +40,7 @@
static int
check_magic(void** program_code) {
-return (GRAB_IV(program_code) == PARROT_MAGIC);
+return (GRAB_BYTECODE(program_code) == PARROT_MAGIC);
}
/*
@@ -63,34 +63,34 @@
static void
read_constants_table(void** program_code)
{
-IV len = GRAB_IV(program_code);
-IV num;
+int32_t len = GRAB_BYTECODE(program_code);
+int32_t num;
IV i = 0;
if (len == 0)
return;
-num = GRAB_IV(program_code);
-len -= sizeof(IV);
+num = GRAB_BYTECODE(program_code);
+len -= sizeof(int32_t);
Parrot_string_constants = Allocate_Aligned(num * sizeof(STRING*));
while (len > 0) {
-IV flags= GRAB_IV(program_code);
-IV encoding = GRAB_IV(program_code);
-IV type = GRAB_IV(program_code);
-IV buflen = GRAB_IV(program_code);
+IV flags= GRAB_BYTECODE(program_code);
+IV encoding = GRAB_BYTECODE(program_code);
+IV type = GRAB_BYTECODE(program_code);
+IV buflen = GRAB_BYTECODE(program_code);
int pad;
-len -= 4 * sizeof(IV);
+len -= 4 * sizeof(int32_t);
Parrot_string_constants[i++] = string_make(*program_code /* ouch */, buflen,
encoding, flags, type);
(char*)*program_code += buflen;
len -= buflen;
/* Padding */
- pad=buflen % sizeof(IV);
+ pad=buflen % sizeof(int32_t);
if(pad) {
- pad=sizeof(IV)-pad;
+ pad=sizeof(int32_t)-pad;
len -= pad;
(char*)*program_code += pad;
}
@@ -120,9 +120,9 @@
static void
read_fixup_table(void** program_code)
{
-IV len = GRAB_IV(program_code);
+int32_t len = GRAB_BYTECODE(program_code);
/* For now, just skip over it */
-((IV*)*program_code) += len;
+((int32_t*)*program_code) += len;
}
/*
Index: config.h.in
===
RCS file: /home/perlcvs/parrot/config.h.in,v
retrieving revision 1.1
diff -u -r1.1 config.h.in
--- config.h.in 2001/09/11 09:44:00 1.1
+++ config.h.in 2001/09/13 20:30:52
@@ -7,7 +7,7 @@
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef ${iv} IV;
-typedef ${iv} double NV;
+typedef ${nv} NV;
typedef struct _vtable VTABLE;
typedef void DPOINTER;
@@ -22,7 +22,7 @@
#define FRAMES_PER_INT_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_STR_REG_CHUNK FRAMES_PER_CHUNK
-#define MASK_CHUNK_LOW_BITS 0xf000
+#define MASK_CHUNK_LOW_BITS ((IV)~0x0fff)
${headers}
Index: events.h
===
RCS file: /home/perlcvs/parrot/events.h,v
retrieving revision 1.1
diff -u -r1.1 events.h
--- events.h2001/08/29 12:07:02 1.1
+++ events.h2001/09/13 20:30:52
@@ -7,7 +7,7 @@
#if !defined(PARROT_EVENT_H_GUARD)
#define PARROT_EVENT_H_GUARD
-#define EXECUTE_OPCODE(x) interpreter->opcode_funcs[*(IV *)x]->(code, interpreter)
+#define EXECUTE_OPCODE(x) interpreter->opcode_funcs[*(int32_t *)x]->(code,
+interpreter)
#define CHECK_EVENTS(x)
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.6
diff -u -r1.6 interpreter.c
--- interpreter.c
patch test3.pasm
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.pasm --- test3.pasm 2001/09/10 22:18:43 1.1 +++ test3.pasm 2001/09/13 20:36:28 @@ -194,4 +194,4 @@ print_i I1 pop_i print_i I1 - \ No newline at end of file +end \ No newline at end of file
Re: patch: assembly listings from assembler
--- 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 (@ARGV and $ARGV[0] eq "-c") {
> < shift @ARGV;
> < $opt_c = 1;
> ---
> > my %options;
> > GetOptions(\%options,('checksyntax',
> > 'help',
> > 'version',
> > 'verbose',
> > 'output=s',
> > 'listing=s'));
> >
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?
Many thanks,
-- BKS
__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
Re: Using int32_t instead of IV for code
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 guarantee that there's a native integral type with 32 bits. And having an int32_t type that *isn't* 32-bits is just plain confusing. Just ask anyone who's gotten burnt by perl5's I32, which has the exact same problem. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Using int32_t instead of IV for code
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.c). > >I think this is a bad idea. There simply is no guarantee that there's >a native integral type with 32 bits. And having an int32_t type that >*isn't* 32-bits is just plain confusing. Just ask anyone who's gotten >burnt by perl5's I32, which has the exact same problem. Well, since bytecode is defined to be 32-bit, it makes sense to define it as an int32_t type and have the definition of an int32_t be platform-specific.
RE: Things we need to do.
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 system to autogenerate the #Makefile as well. Use Makefile.in as a template, and #fill in things like LIBS. I'll take care of Configure.pl. This will also give me a chance to let you select a different C compiler, which may help on Windows. (My system has a copy of gcc with DJGPP, but it's broken somehow--keeps complaining about compiling header files.) Does Perl 5's Configure know when to do the -lm stuff? Do I detect that by checking the compiler flags thing in %Config for /\b-lm\b/? # 3) Move all the header files to "include/" and have the #C source #include "parrot/include/" # # 4) Send me and Ben a patch to munge all the function names #to meet the coding standards. You could even send a Perl #script to do it! # # 5) Implement some more string encodings. docs/strings.pod #tells you what you need to do. # # 6) A test suite! My kingdom for a test suite! --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
parrot/config.h patch
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.
Re: CVS update mailing list
> "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 it make sense for patches to be only sent to simon and then we can be notified by the cvs list? it is hard to track what people are doing when some patches are in and others are rejected, etc. when i screw my brains back in (been out most of the summer) i will endeavor to stick my nose into the code base here. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: CVS update mailing list
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 mail to > DS> [EMAIL PROTECTED] to start the process. > >does it make sense for patches to be only sent to simon and then we can >be notified by the cvs list? it is hard to track what people are doing >when some patches are in and others are rejected, etc. That's an interesting question. Personally, I think patches to the list are the best thing, followed (way, *way* down) by patches to Simon. Patches directly to me are a bad thing, but that's mainly because my Inbox is a black hole which things fall into and never emerge from. :) Pretty soon we'll be getting more folks with checkin permission, and I'm working on getting some of the independent subsystems sketched out so folks can, for example, start in on the I/O system or the various variable types. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: patch: assembly listings from assembler
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 than the plain diff output. Any patch is a good patch, but readable patches are better. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD in CVS
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. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using int32_t instead of IV for code
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 my Alpha (modifications to config.h.in and register.c). >> >>I think this is a bad idea. There simply is no guarantee that there's >>a native integral type with 32 bits. And having an int32_t type that >>*isn't* 32-bits is just plain confusing. Just ask anyone who's gotten >>burnt by perl5's I32, which has the exact same problem. > >Well, since bytecode is defined to be 32-bit, it makes sense to define it >as an int32_t type and have the definition of an int32_t be platform-specific. Yeah, but it isn't, that's the problem. I was thinking more that we'd have a type OP for opcodes, for example. #typedef'd to int, or long, or int32_t, but conceptually standalone so we could change it if need be. (The possibility still exists that we might shrink to 16 bit opcodes...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Things we need to do.
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 things like LIBS.
#
# I'll take care of Configure.pl. This will also give me a chance to let
# you select a different C compiler, which may help on Windows. (My
# system has a copy of gcc with DJGPP, but it's broken somehow--keeps
# complaining about compiling header files.)
It didn't take very long. Patch for Configure.pl below my sig (yes, I
finally did get PPT to work); delete Makefile and add the attached
Makefile.in.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- Configure.pl.oldThu Sep 13 15:34:06 2001
+++ Configure.plThu Sep 13 15:31:34 2001
@@ -1,7 +1,7 @@
#!/usr/bin/perl -w
#so we get -w
-#Configre.pl, written by Brent Dax
+#Configure.pl, written by Brent Dax
use strict;
use Config;
@@ -22,11 +22,18 @@
#defaults for them.
#XXX Figure out better defaults
my(%c)=(
- iv => ($Config{ivtype}||'long'),
- nv => ($Config{nvtype}||'long double')
+ iv => ($Config{ivtype}||'long'),
+ nv => ($Config{nvtype}||'long double'),
+ cc => $Config{cc},
+ ccflags => '-Wall -o $@',
+ libs => $Config{libs}
);
#inquire about numeric sizes
+
+prompt("What C compiler do you want to use?", 'cc');
+prompt("What flags would you like passed to your C compiler?",
'ccflags');
+prompt("Which libraries would you like your C compiler to include?" ,
'libs');
prompt("How big would you like integers to be?", 'iv');
prompt("How about your floats?", 'nv');
@@ -43,22 +50,16 @@
$c{headers}.=defineifdef((/^i_(.*)$/));
}
-#now let's assemble the config.h file
-my $config_h;
-{
- local $/;
- open(CONFIG_HT, ";
- close CONFIG_HT;
-}
+print <<"END";
-# ${field} is replaced with $c{field}
-$config_h =~ s/\$\{(\w+)\}/$c{$1}/g;
+Okay, that's finished. I'm now going to write your very
+own Makefile and config.h to disk.
+END
-#write out the config.h file
-open(CONFIG_H, ">config.h");
-print CONFIG_H $config_h;
-close CONFIG_H;
+#now let's assemble the config.h file
+buildfile("config.h");
+#and the makefile
+buildfile("Makefile");
print <<"END";
@@ -91,3 +92,17 @@
$c{$field}=$input||$c{$field};
}
+sub buildfile {
+ my($filename)=shift;
+
+ local $/;
+ open(IN, "<$filename.in");
+ my $text=;
+ close(IN);
+
+ $text =~ s/\$\{(\w+)\}/$c{$1}/g;
+
+ open(OUT, ">$filename");
+ print OUT $text;
+ close(OUT);
+}
Makefile.in
Re: Using int32_t instead of IV for code
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 64bits.) Basically on platforms that can't do 32-bits easily we'll preprocess the input, the same way we would if we passed a little-endian bytecode stream to a big-endian machine. Right now we mmap for simplicity, but the ultimate "right" way to do things is: 1) Open bytecode 2a) Check endian signature 2b) Check bytecode size 3) If 2a and 2b don't match our requirements, generate a temporary in-memory version that does 4) Run code We need to get that done soonish, so we can pass bytecode between alpha and x86 systems, as well as get the bytecode endian translator written. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: patch: assembly listings from assembler
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 either -c or -u diffs. Both can be > fed to patch, and both read far more easily than the plain diff output. The following lines, placed in ~/.cvsrc, make cvs work much better: update -dP diff -u The -d option to update makes cvs check out newly-created directories; without it, it will silently ignore them. -P prunes empty directories, which compensates for the fact that directories can't be deleted. And the -u to diff (or -c) is just a good idea. :> - Damien
Re: #include "config.h" or #include "parrot/config.h"
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 what > could be > > reasonably considered antique systems. That'd include DOS-only machines. I > >Tsk, tsk. I know, I'm horrible. :) > > don't think we should actively discourage them, but neither do I think we > > should be bound by their limitations. > >If we want to be nice about this we should have enough metadata >about any embedded filenames to be able to convert those to help >less forturnate filesystems. Works. I'm all for putting in whatever we need so folks with limitations can work around 'em. I'm thinking also of some of the big iron systems that might want to run perl natively rather than in a Unix compatibility mode, as well as antique versions of currently supported OSes. (SunOS 4.x, VMS 5.5-2h, AmigaDOS 1.3, whatever) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Using int32_t instead of IV for code
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 tests running > > >on my Alpha (modifications to config.h.in and register.c). > > > >I think this is a bad idea. There simply is no guarantee that there's > >a native integral type with 32 bits. And having an int32_t type that > >*isn't* 32-bits is just plain confusing. Just ask anyone who's gotten > >burnt by perl5's I32, which has the exact same problem. > > Well, since bytecode is defined to be 32-bit, it makes sense to define it > as an int32_t type and have the definition of an int32_t be platform-specific. I'd have thought it made sense to define it as a bytecode_t type, or some such which could be platform specific. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Fibonaci
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: result (a)
# I2: n (i)
# I3: temp (b)
# I4: temp (c)
# I5: scratch
#
# implement loop some day
main:
setI2, 24
# calling convent n in I2
fibo: set S1, "(Fibonacis function)\n"
print S1
set I5, 1
eqI2, I5, done1, or
or: set I5, 2
eqI2, I5, done1, else
else: dec I2, 2
set I1, 1
set I3, 1
set I5, 0
eqI2, I5, done2, while
while: set I4, I1
add I1, I1,I3
set I3, I4
dec I2
eqI2, 0, done2, while
done1: set I1,1
done2: print I1
set S2, "\n"
print S2
end
# Enjoy,
