float constants
If floats are so non-portable, why do we have a constant table section for them? Or is that temporary? -- Bryan C. Warnock [EMAIL PROTECTED]
[PATCH] INTVALs and opcodes
The attached patch addresses the non-printf related casting problems between
opcodes (which are currently doubling as PBC chunks in addition to just
being an opcode number) and INTVALs. Handles sizeof(opcode_t) <=>
sizeof(INTVAL). Includes a couple other casting fixes.
Casting between opcode_t entities and INTVALs should now be done via the
macros OP2INT() and INT2OP(). Truncation of INTVALs > opcode_t is untested.
printf formats of entities > long are still unsupported, pending a viable
solution.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.24
diff -u -r1.24 Configure.pl
--- Configure.pl2001/10/08 18:30:46 1.24
+++ Configure.pl2001/10/12 03:44:34
@@ -114,6 +114,11 @@
$c{cc_debug} = ' ';
}
+# Make sure types are signed. We'll mark the unsigned ones as necessary
+foreach my $type (qw(iv nv opcode_t)) {
+$c{$type} =~ s/^\s*unsigned\s+//;
+}
+
print <<"END";
Okay. Now I'm gonna probe Perl 5's configuration to see
@@ -145,6 +150,25 @@
unlink('test.c', "test_siz$c{exe}", "test$c{o}");
}
+# Validate the sizes, and compute the proper op->int/int->op conversions
+if ($c{intvalsize} < $c{opcode_t_size}) {
+ print <<"END";
+
+Your INTs are smaller than your opcodes, but need to be at
+least the same size. I'll promote them for you.
+END
+$c{iv} = $c{opcode_t};
+$c{intvalsize} = $c{opcode_t_size};
+}
+if ($c{intvalsize} == $c{opcode_t_size}) {
+$c{op2int_conversion} = "(signed $c{iv})";
+$c{int2op_conversion} = "(unsigned $c{opcode_t})";
+}
+else {
+$c{op2int_conversion} = "($c{iv})(signed $c{opcode_t})";
+$c{int2op_conversion} = "(unsigned $c{opcode_t})";
+}
+
print <<"END";
Done. Now I'm figuring out what formats to pass to pack() for the
@@ -299,4 +323,4 @@
sub runtestc {
`./test_siz$c{exe}`
-}
\ No newline at end of file
+}
Index: config_h.in
===
RCS file: /home/perlcvs/parrot/config_h.in,v
retrieving revision 1.8
diff -u -r1.8 config_h.in
--- config_h.in 2001/10/06 00:57:43 1.8
+++ config_h.in 2001/10/12 03:44:34
@@ -7,11 +7,15 @@
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
#include
+
typedef ${iv} INTVAL;
typedef ${nv} FLOATVAL;
-typedef ${opcode_t} opcode_t;
+typedef unsigned ${opcode_t} opcode_t;
typedef size_t ptrcast_t;
+
+#define OP2INT(x) (${op2int_conversion} x )
+#define INT2OP(x) (${int2op_conversion} x )
typedef struct _vtable VTABLE;
typedef void DPOINTER;
Index: packfile.c
===
RCS file: /home/perlcvs/parrot/packfile.c,v
retrieving revision 1.12
diff -u -r1.12 packfile.c
--- packfile.c 2001/10/08 00:21:02 1.12
+++ packfile.c 2001/10/12 03:44:37
@@ -328,11 +328,11 @@
cursor += sizeof(opcode_t);
#if TRACE_PACKFILE
-printf("PackFile_unpack(): Unpacking %ld bytes for fixup table...\n",
segment_size);
+printf("PackFile_unpack(): Unpacking %lu bytes for fixup table...\n",
segment_size);
#endif
if (segment_size % sizeof(opcode_t)) {
-fprintf(stderr, "PackFile_unpack: Illegal fixup table segment size
%d (must be multiple of %d)!\n",
+fprintf(stderr, "PackFile_unpack: Illegal fixup table segment size
%lu (must be multiple of %d)!\n",
segment_size, sizeof(opcode_t));
return 0;
}
@@ -353,11 +353,11 @@
cursor += sizeof(opcode_t);
#if TRACE_PACKFILE
-printf("PackFile_unpack(): Unpacking %ld bytes for constant
table...\n", segment_size);
+printf("PackFile_unpack(): Unpacking %lu bytes for constant
table...\n", segment_size);
#endif
if (segment_size % sizeof(opcode_t)) {
-fprintf(stderr, "PackFile_unpack: Illegal constant table segment
size %d (must be multiple of %d)!\n",
+fprintf(stderr, "PackFile_unpack: Illegal constant table segment
size %lu (must be multiple of %d)!\n",
segment_size, sizeof(opcode_t));
return 0;
}
@@ -378,7 +378,7 @@
cursor += sizeof(opcode_t);
#if TRACE_PACKFILE
-printf("PackFile_unpack(): Unpacking %ld bytes for byte code...\n",
segment_size);
+printf("PackFile_unpack(): Unpacking %lu bytes for byte code...\n",
segment_size);
#endif
self->byte_code_size = segment_size;
@@ -518,7 +518,7 @@
PackFile_dump(struct PackFile * self) {
opcode_t i;
-printf("MAGIC => 0x%08x,\n", self->magic);
+printf("MAGIC => 0x%08lx,\n", self->magic);
printf("FIXUP => {\n");
@@ -536,9 +536,9 @@
for (i = 0; i < self->byte_code_size / 4; i++) {
if (i % 8 == 0) {
-printf("\n%08x: ", i * 4);
+printf("\n%08lx: ", i * 4);
}
-printf("%08x ", ((opcode_t *)(self->byte_code))[i]);
+printf("%08lx ", ((opcode_t *)(self->byte_
Re: Fetching the PC?
On 11 Oct 2001, Brian Wheeler wrote: > On Thu, 2001-10-11 at 21:23, Dan Sugalski wrote: > > At 09:12 PM 10/11/2001 -0500, Brian Wheeler wrote: > > >On Thu, 2001-10-11 at 20:49, Dan Sugalski wrote: > > > > At 08:25 PM 10/11/2001 -0500, Brian Wheeler wrote: > > > > >Since we're passing guilt around, there's an equate of '*' which is the > > > > >current PC...and I didn't document it. You can do > > > > > set I1,* > > > > >and it will set I1 to the current PC. It doesn't allow any math, > > > > >though. I thought about hooking up eval to various brackets but I never > > > > >got the time before my job got busy... > > > > > > > > Absolute or relative PC? > > > > > >Well, its relative to the start of the bytecode...which I suppose would > > >be absolute...unless multiple bytecode chunks are placed in the same > > >memory block, in which case it'd be relative. Now I'm confused. :) > > > > Absolute addresses are, well, absolute addresses. Relative addresses are > > offsets from the current location. > > > > I think the confusion's because the jump opcode's broken. When you say > > > >jump 12 > > > > It should jump to absolute address 12, not 12 bytes/words/opcodes from the > > current position. > > > > Ok, fair enough...but should it be jumping to: > (char *)byte_code+12 > or > (char *)12 > > If its the former, it seems there will be some problems jumping to other > bytecode blocks, and if its the latter, at the very least someone can do > a "jump 0" and coredump the process. Latter, and yes it has potential problems. That's one of the reasons the Safe-mode interpreter will be slower--branches and jumps will validate their destination addresses. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Fetching the PC? [RESEND]
Argh, my mailer crashed as I sent this, so I don't know if it went out. On Thu, 2001-10-11 at 21:23, Dan Sugalski wrote: > At 09:12 PM 10/11/2001 -0500, Brian Wheeler wrote: > >On Thu, 2001-10-11 at 20:49, Dan Sugalski wrote: > > > At 08:25 PM 10/11/2001 -0500, Brian Wheeler wrote: > > > >Since we're passing guilt around, there's an equate of '*' which is the > > > >current PC...and I didn't document it. You can do > > > > set I1,* > > > >and it will set I1 to the current PC. It doesn't allow any math, > > > >though. I thought about hooking up eval to various brackets but I never > > > >got the time before my job got busy... > > > > > > Absolute or relative PC? > > > >Well, its relative to the start of the bytecode...which I suppose would > >be absolute...unless multiple bytecode chunks are placed in the same > >memory block, in which case it'd be relative. Now I'm confused. :) > > Absolute addresses are, well, absolute addresses. Relative addresses are > offsets from the current location. > > I think the confusion's because the jump opcode's broken. When you say > >jump 12 > > It should jump to absolute address 12, not 12 bytes/words/opcodes from the > current position. > Ok, fair enough...but should it be jumping to: (char *)byte_code+12 or (char *)12 If its the former, it seems there will be some problems jumping to other bytecode blocks, and if its the latter, at the very least someone can do a "jump 0" and coredump the process. I could be missing stuff, because I've not had a chance to review the changes over the last few weeks > > > >Though I like Gregor's way of doing it: we know the addresses (more or > > > >less) at compile time, so we might as well not waste ops doing > > > >arithmetic that we know in advance... > > > > > > Fair enough, though we don't really know the absolute PC at assembly time, > > > as we're all position independent. Thinking further, having the getpc > > > opcode take an offset would let us do something like: > > > > > >getpc I0, FOO > > > > > > to put the absolute address of FOO into I0, suitable for jumps and jsrs. > > > > > > >This just comes out as a specialized add, right? In fact, isn't it > >this: > > set I0,* > > inc I0,FOO <-- assuming the assembler knew that this is an address > > Yup. Only set doesn't take * as a parameter--it can't, because there's no > way to know at assembly time what the real PC will be. > Yeah, I thought about that afterwards (the condition where real PC is actually a memory address) > >How are multiple bytecode chunks (i.e. libraries) going to be handled? > > They're just going to get mmapped in wherever the system puts 'em. > > >Are they going to be contiguous? > > Nope. > > >Are they going to be segmented somehow > >so there's a "far jump" which takes us out of the current block? > > Nope. Jumps and jsrs take absolute addresses, so they can go anywhere. > Branches are relative so fixing them up to bounce between segments would be > tough, but we're not going to do that. :) > > Fair enough :) Brian > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk
Re: Fetching the PC?
At 09:12 PM 10/11/2001 -0500, Brian Wheeler wrote: >On Thu, 2001-10-11 at 20:49, Dan Sugalski wrote: > > At 08:25 PM 10/11/2001 -0500, Brian Wheeler wrote: > > >Since we're passing guilt around, there's an equate of '*' which is the > > >current PC...and I didn't document it. You can do > > > set I1,* > > >and it will set I1 to the current PC. It doesn't allow any math, > > >though. I thought about hooking up eval to various brackets but I never > > >got the time before my job got busy... > > > > Absolute or relative PC? > >Well, its relative to the start of the bytecode...which I suppose would >be absolute...unless multiple bytecode chunks are placed in the same >memory block, in which case it'd be relative. Now I'm confused. :) Absolute addresses are, well, absolute addresses. Relative addresses are offsets from the current location. I think the confusion's because the jump opcode's broken. When you say jump 12 It should jump to absolute address 12, not 12 bytes/words/opcodes from the current position. > > >Though I like Gregor's way of doing it: we know the addresses (more or > > >less) at compile time, so we might as well not waste ops doing > > >arithmetic that we know in advance... > > > > Fair enough, though we don't really know the absolute PC at assembly time, > > as we're all position independent. Thinking further, having the getpc > > opcode take an offset would let us do something like: > > > >getpc I0, FOO > > > > to put the absolute address of FOO into I0, suitable for jumps and jsrs. > > > >This just comes out as a specialized add, right? In fact, isn't it >this: > set I0,* > inc I0,FOO <-- assuming the assembler knew that this is an address Yup. Only set doesn't take * as a parameter--it can't, because there's no way to know at assembly time what the real PC will be. >How are multiple bytecode chunks (i.e. libraries) going to be handled? They're just going to get mmapped in wherever the system puts 'em. >Are they going to be contiguous? Nope. >Are they going to be segmented somehow >so there's a "far jump" which takes us out of the current block? Nope. Jumps and jsrs take absolute addresses, so they can go anywhere. Branches are relative so fixing them up to bounce between segments would be tough, but we're not going to do that. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Fetching the PC?
On Thu, 2001-10-11 at 20:49, Dan Sugalski wrote: > At 08:25 PM 10/11/2001 -0500, Brian Wheeler wrote: > >Since we're passing guilt around, there's an equate of '*' which is the > >current PC...and I didn't document it. You can do > > set I1,* > >and it will set I1 to the current PC. It doesn't allow any math, > >though. I thought about hooking up eval to various brackets but I never > >got the time before my job got busy... > > Absolute or relative PC? Well, its relative to the start of the bytecode...which I suppose would be absolute...unless multiple bytecode chunks are placed in the same memory block, in which case it'd be relative. Now I'm confused. :) > > >Though I like Gregor's way of doing it: we know the addresses (more or > >less) at compile time, so we might as well not waste ops doing > >arithmetic that we know in advance... > > Fair enough, though we don't really know the absolute PC at assembly time, > as we're all position independent. Thinking further, having the getpc > opcode take an offset would let us do something like: > >getpc I0, FOO > > to put the absolute address of FOO into I0, suitable for jumps and jsrs. > This just comes out as a specialized add, right? In fact, isn't it this: set I0,* inc I0,FOO <-- assuming the assembler knew that this is an address How are multiple bytecode chunks (i.e. libraries) going to be handled? Are they going to be contiguous? Are they going to be segmented somehow so there's a "far jump" which takes us out of the current block? Brian
Re: Fetching the PC?
At 08:25 PM 10/11/2001 -0500, Brian Wheeler wrote: >Since we're passing guilt around, there's an equate of '*' which is the >current PC...and I didn't document it. You can do > set I1,* >and it will set I1 to the current PC. It doesn't allow any math, >though. I thought about hooking up eval to various brackets but I never >got the time before my job got busy... Absolute or relative PC? >Though I like Gregor's way of doing it: we know the addresses (more or >less) at compile time, so we might as well not waste ops doing >arithmetic that we know in advance... Fair enough, though we don't really know the absolute PC at assembly time, as we're all position independent. Thinking further, having the getpc opcode take an offset would let us do something like: getpc I0, FOO to put the absolute address of FOO into I0, suitable for jumps and jsrs. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Fetching the PC?
On Thu, 2001-10-11 at 19:49, Dan Sugalski wrote: > At 06:05 PM 10/11/2001 -0400, Gregor N. Purdy wrote: > >I'm guilty. > > > >I needed address arithmetic for Jako subroutine support. I also needed > >a quick and easy way to detect it in the .pasm file. I use the square > >brackes as a quotation device to make it easy to parse. Eventually > >we will need an assembler with a syntax that is *designed* rather > >than *evolved* (this is not intended as a disparaging comment), at > >which point the syntax for various constructs would be up for grabs. > > Are you sure it's not just stolen? Some of us do have extensive (if really, > really old) experience with macro assemblers :) > > >For example, I think registers should start with '%' or some other > >sigil, since I could very reasonably want to use a label that looked > >like a register reference. > > Heh. Well, too bad--use S0 and get string register 0. I'm OK with that. > > >Anyway, we definitely should have address arithmetic documented in > >the assembler docs, and I should have written it right at the outset, > >but I forgot. > > While I think I'd prefer * as the PC indicator, @ is OK and it won't > conflict with constant arithmetic someone might want to do. > Since we're passing guilt around, there's an equate of '*' which is the current PC...and I didn't document it. You can do set I1,* and it will set I1 to the current PC. It doesn't allow any math, though. I thought about hooking up eval to various brackets but I never got the time before my job got busy... > I think we need some opcode that'll fetch the current PC and stick it in a > register. Maybe: > > getpc I0 > > to put the PC for the next instruction into I0. > Sort of what happens above, though its one off. > Having "fake" opcodes would be useful, like so: > > getlabelabs I0, FOO > > to put the absolute address of the label FOO into I0, which'd probably > translate into: > > getPC I0 > add I0, I0, FOO > > or something like that. > Though I like Gregor's way of doing it: we know the addresses (more or less) at compile time, so we might as well not waste ops doing arithmetic that we know in advance... Brian > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk
rand/srand patch
I was playing with Parrot and wanted a basic random numbers implementation. Just in case anyone else wants it too, here are the appropriate diffs and test file. It seemed logical for rand to return a real number between 0 and 1 instead of having any reliance on RAND_MAX. Any other ideas? - This message made possible by vi. - Ryan O'Neil - basic_opcodes.ops.diff Description: Binary data opcode_table.diff Description: Binary data parrot_assembly.pod.diff Description: Binary data rand.t Description: Binary data
Re: Fetching the PC?
At 06:05 PM 10/11/2001 -0400, Gregor N. Purdy wrote: >I'm guilty. > >I needed address arithmetic for Jako subroutine support. I also needed >a quick and easy way to detect it in the .pasm file. I use the square >brackes as a quotation device to make it easy to parse. Eventually >we will need an assembler with a syntax that is *designed* rather >than *evolved* (this is not intended as a disparaging comment), at >which point the syntax for various constructs would be up for grabs. Are you sure it's not just stolen? Some of us do have extensive (if really, really old) experience with macro assemblers :) >For example, I think registers should start with '%' or some other >sigil, since I could very reasonably want to use a label that looked >like a register reference. Heh. Well, too bad--use S0 and get string register 0. I'm OK with that. >Anyway, we definitely should have address arithmetic documented in >the assembler docs, and I should have written it right at the outset, >but I forgot. While I think I'd prefer * as the PC indicator, @ is OK and it won't conflict with constant arithmetic someone might want to do. I think we need some opcode that'll fetch the current PC and stick it in a register. Maybe: getpc I0 to put the PC for the next instruction into I0. Having "fake" opcodes would be useful, like so: getlabelabs I0, FOO to put the absolute address of the label FOO into I0, which'd probably translate into: getPC I0 add I0, I0, FOO or something like that. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] strnative.c typo
In message <[EMAIL PROTECTED]> Tom Hughes <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> > Bryan C. Warnock <[EMAIL PROTECTED]> wrote: > > > Assignment, not comparison. (Plus formatted for coding standards) > > Committed. The tests should really have caught this, so I'm going to > do some work on them to make them more comprehensive... Attached is a patch to string.t to extend the testing of the comparison ops - there is now a list of pairs of strings and each of the twelve comparison ops is tried with each pair of strings from the list. I'll commit this tomorrow unless somebody spots a problem. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ Index: string.t === RCS file: /home/perlcvs/parrot/t/op/string.t,v retrieving revision 1.9 diff -u -w -r1.9 string.t --- string.t2001/10/10 18:21:05 1.9 +++ string.t2001/10/11 23:07:03 @@ -150,320 +150,150 @@ done OUTPUT +my @strings = ( + "hello", "hello", + "hello", "world", + "world", "hello", + "hello", "hellooo", + "hellooo", "hello", + "hello", "hella", + "hella", "hello", + "hella", "hellooo", + "hellooo", "hella", + "hElLo", "HeLlO", + "hElLo", "hElLo" +); + output_is(<
Re: Revamping the build system
At 03:06 PM 10/11/2001 -0700, Josh Wilmes wrote: >It seems to me that we should look at cons before writing Yet Another Perl >Build System. (i haven't used it myself, so I don;'t know if it's good >or not). For reference: http://www.dsmit.com/cons/ It's GPL, so we couldn't ship with it unless the author was willing to re-license it to us. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: preprocessor directives...
At 06:13 PM 10/11/2001 -0700, Wizard wrote: >I noticed that many of header files use the following format: >#if !defined(H_GUARD) >Is this preferable to "#ifndef"? I find it clearer to read. > I always thought that the defined() >function was only for more complex tests. Doesn't really matter--both work fine. >Additionally, the defined() >function may not be entirely portable (it might be missing on AIX, but I'm >not positive as I don't have such a system handy). >just curious, Well, other definedness checks use it, so platforms without it are sorta out of luck anyway. I'd be really surprised if the AIX C compiler doesn't do this. (I think it's a C89 requirement, but I'm not 100% sure) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
preprocessor directives...
I noticed that many of header files use the following format: #if !defined(H_GUARD) #define H_GUARD Is this preferable to "#ifndef"? I always thought that the defined() function was only for more complex tests. Additionally, the defined() function may not be entirely portable (it might be missing on AIX, but I'm not positive as I don't have such a system handy). just curious, Grant M.
Re: Revamping the build system
It seems to me that we should look at cons before writing Yet Another Perl Build System. (i haven't used it myself, so I don;'t know if it's good or not). For reference: http://www.dsmit.com/cons/ --Josh At 12:18 on 10/11/2001 PDT, Robert Spier <[EMAIL PROTECTED]> wrote: > > | I'm OK requiring a C compiler and a build tool for a platform. It's a C > | compiler and perl 5 that I don't want to require. (Rather nasty > | bootstrapping issues there... :) > > This makes things a lot harder. Suddenly we're > re-implementing make. (in C) > > Speaking of re-implementing make, I just finished cranking > out a really simple make-alike in perl. It uses essentially > the same syntax, but has no frills. > > Frills = parallel building, implicit rules, variables. > > Most of these frills are "in progress". > > But - if perl5 is going to be a nono - then this isn't going > to be an option. > > Would it make sense to start with something like this and > re-evaluate it when python/perl6 has matured so that it can > bootstrap its own build process? > > -R
Re: Fetching the PC?
Dan, Sam, All -- > > Did we put a patch into parrot that lets you fetch the current PC and store > > it in an integer register? I seem to recall someone did, but I can't find it. > > That's the '@' thing I was talking about making a doc patch for. I then > realized that I didn't understand it well enough to explain it! The > little I grok is that a '@' in the assembly gets replaced by the value of > $op_pc. Jako does stuff like: > >set I31, [ printit - @ - 3 ] > > For function calls. As I thought about documenting '@' I realized I had > no idea what those braces are for... Seems to me whoever put in this > hack should be the one to document it. I'm guilty. I needed address arithmetic for Jako subroutine support. I also needed a quick and easy way to detect it in the .pasm file. I use the square brackes as a quotation device to make it easy to parse. Eventually we will need an assembler with a syntax that is *designed* rather than *evolved* (this is not intended as a disparaging comment), at which point the syntax for various constructs would be up for grabs. For example, I think registers should start with '%' or some other sigil, since I could very reasonably want to use a label that looked like a register reference. Anyway, we definitely should have address arithmetic documented in the assembler docs, and I should have written it right at the outset, but I forgot. Right now, I'm in the middle of a moby patch (as I indicated in my message to the list earlier today) having to do with refactoring all the stuff related to opcode tables and definitions and code transformations. Things are working pretty well right now, although I'm not yet passing all the tests. Once I complete moby.patch, I can update the assembler docs, unless someone beats me to it. In the mean time, I'm hoping the above at least lets you understand it a bit. You can use labels, constants, @ and +/- in your address arithmetic. Enjoy. 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: Fetching the PC?
i just checked basic_opcodes.c but i can't see anything like that... but i found something that confused me: parrot_assembly.pod says: jump tx: Jump _to_ the address held in register x branch tx Branch forward or backward by the amount in register x. (X may be either Ix, Nx, or Px) Branch offset may also be an integer constant. all i can find in basic_opcodes is a branch_ic and the code for jump_i looks more like a branch_i because it does exactly what brach_ic does but with a register rather than a constant... jump should more look like: return interpreter->code->byte_code + cur_opcode[1]; /* jump_ic*/ return interpreter->code->byte_code + interpreter->int_reg->registers[cur_opcode[1]]; /* jump_i */ -daniel - Original Message - From: "Dan Sugalski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 11, 2001 11:13 PM Subject: Fetching the PC? > Did we put a patch into parrot that lets you fetch the current PC and store > it in an integer register? I seem to recall someone did, but I can't find it. > > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk >
Re: Fetching the PC?
On Thu, 11 Oct 2001, Dan Sugalski wrote: > Did we put a patch into parrot that lets you fetch the current PC and store > it in an integer register? I seem to recall someone did, but I can't find it. That's the '@' thing I was talking about making a doc patch for. I then realized that I didn't understand it well enough to explain it! The little I grok is that a '@' in the assembly gets replaced by the value of $op_pc. Jako does stuff like: set I31, [ printit - @ - 3 ] For function calls. As I thought about documenting '@' I realized I had no idea what those braces are for... Seems to me whoever put in this hack should be the one to document it. -sam
Fetching the PC?
Did we put a patch into parrot that lets you fetch the current PC and store it in an integer register? I seem to recall someone did, but I can't find it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Another parrot example
Here it goes... another simple parrot example. By the Way... jsr is not yet implemented? Or I didn't know how to use it? Just can't we do: jsr THERE end THERE: And... what's the argument to return? I didn't understand... Thanks Alberto Simões mdc.pasm Description: Binary data
Re: Revamping the build system
At 12:18 PM 10/11/2001 -0700, Robert Spier wrote: >| I'm OK requiring a C compiler and a build tool for a platform. It's a C >| compiler and perl 5 that I don't want to require. (Rather nasty >| bootstrapping issues there... :) > >This makes things a lot harder. Suddenly we're >re-implementing make. (in C) No, we don't have to do it in C. We can do it in perl, we just can't require perl for the initial build. The steps would be: 1) Build minimal perl 6 with default parameters using platform build tool 2) Run configure with minimal perl 6 3) Build full perl 6 with perl build tool and minimal perl 4) Build full perl 6 distrib with full perl Basically we ship a Makefile and bare-bones config.h, enough to build miniparrot. Miniparrot then reconfigures itself and builds full parrot, which then goes and builds the world. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
| I'm OK requiring a C compiler and a build tool for a platform. It's a C | compiler and perl 5 that I don't want to require. (Rather nasty | bootstrapping issues there... :) This makes things a lot harder. Suddenly we're re-implementing make. (in C) Speaking of re-implementing make, I just finished cranking out a really simple make-alike in perl. It uses essentially the same syntax, but has no frills. Frills = parallel building, implicit rules, variables. Most of these frills are "in progress". But - if perl5 is going to be a nono - then this isn't going to be an option. Would it make sense to start with something like this and re-evaluate it when python/perl6 has matured so that it can bootstrap its own build process? -R
Re: [PATCH] strnative.c typo
In message <[EMAIL PROTECTED]> Bryan C. Warnock <[EMAIL PROTECTED]> wrote: > Assignment, not comparison. (Plus formatted for coding standards) Committed. The tests should really have caught this, so I'm going to do some work on them to make them more comprehensive... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Yet another candidat for little_languages :")
http://www.tuxedo.org/~esr/kbuild/cml2-paper.html
TODO
Here is a simple script (I hope it works) to grep instructions that
are not implemented.
Cheers
Alberto
--
| Alberto Manuel Brandão Simões |
| [EMAIL PROTECTED] |
| http://numexp.sourceforge.net |
#!/usr/bin/perl -w
$file2grep = "docs/parrot_assembly.pod";
$opcodetable = "opcode_table";
open FG, $file2grep or die "Cannot open that file";
open OC, $opcodetable or die "Cannot open that file2";
while() {
next if /^#/;
next if /^\s*$/;
/^(\S+)/;
$op{$1} = 1;
}
while() {
if (/^=item\s+([a-z]\S+)/) {
$instruction = $1;
if ($op{$instruction}) {
} else {
print "TODO: $instruction\n";
}
}
}
close FG;
close OC;
[PATCH] strnative.c typo
Assignment, not comparison. (Plus formatted for coding standards)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Index: strnative.c
===
RCS file: /home/perlcvs/parrot/strnative.c,v
retrieving revision 1.16
diff -u -r1.16 strnative.c
--- strnative.c 2001/10/10 18:21:04 1.16
+++ strnative.c 2001/10/11 15:38:08
@@ -91,11 +91,15 @@
if (s1->bufused < s2->bufused) {
cmp = memcmp(s1->bufstart, s2->bufstart, s1->bufused);
-if (cmp == 0) cmp == -1;
+if (cmp == 0) {
+cmp = -1;
+}
}
else {
cmp = memcmp(s1->bufstart, s2->bufstart, s2->bufused);
-if (cmp ==0 && s1->bufused > s2->bufused) cmp = 1;
+if (cmp ==0 && s1->bufused > s2->bufused) {
+cmp = 1;
+}
}
return cmp;
Re: [RePATCH] content preserving register pushes
On Monday 08 October 2001 12:09 pm, Bryan C. Warnock wrote: > Supercedes the previous one. Patch withdrawn. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Revamping the build system
At 05:04 PM 10/11/2001 +0200, Bart Lateur wrote: >On Thu, 11 Oct 2001 09:59:56 -0400, Dan Sugalski wrote: > > >At 06:10 PM 10/10/2001 -0700, Dave Storrs wrote: > >>Any interest in using something less painful than Make for this? I was > >>thinking of Cons, myself...built in Perl 5 (which we are already requiring > >>you to have), and much more friendly than Make. > > > >Don't forget that our requirement for perl 5 is ultimately temporary. The > >build system is the one thing that *can't* be in perl, since we'd need a > >working simple makefile to build the first go-round of perl 6 which then > >configures and rebuilds itself. > >OTOH, "make" isn't very user friendly (the tabs vs. spaces thing is >notorious), and not all "make" tools work the same on all platforms. Oh, I have few nice things to say about make other than "It works OK". The single advantage we have is that there's likely to be a make-ish tool of some sort available for every platform that we can ship a simple script for. (Even if for some platforms it's as simple as a shell script or its platform equivalent) I'm OK requiring a C compiler and a build tool for a platform. It's a C compiler and perl 5 that I don't want to require. (Rather nasty bootstrapping issues there... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
On Thu, 11 Oct 2001 09:59:56 -0400, Dan Sugalski wrote: >At 06:10 PM 10/10/2001 -0700, Dave Storrs wrote: >>Any interest in using something less painful than Make for this? I was >>thinking of Cons, myself...built in Perl 5 (which we are already requiring >>you to have), and much more friendly than Make. > >Don't forget that our requirement for perl 5 is ultimately temporary. The >build system is the one thing that *can't* be in perl, since we'd need a >working simple makefile to build the first go-round of perl 6 which then >configures and rebuilds itself. OTOH, "make" isn't very user friendly (the tabs vs. spaces thing is notorious), and not all "make" tools work the same on all platforms. -- Bart.
FYI - Working on unifying all op/opfunc related stuff
All -- I don't have time to go into all the details right now, but I am working on unifying all the stuff that process through opcode_table, basic_opcodes.ops, etc. I'm writing some Parrot::* Perl modules for reading and processing the files, and reworking how everything connects up. I'm hoping the net result of this refactoring is a simplified system and one that takes us a step closer to being able to have multiple separate oplibs. Stay tuned, and I hope I don't conflict with anyone... 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: Mais um
At 02:41 PM 10/11/2001 +0100, Alberto Manuel Brandao Simoes wrote: > One more example... this time to calculate the maximum common > divisor. > > One more question... does jsr working? I can't use it... Nope. Soon, though. > And, finally... can anybody explain the argument to return? No, and I wrote the docs. :( I think I'm going to yank it out. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl6]Re: Breaking up configure
I'm working on a semi-spike implementation of this, I'll post it up here for comment when I have it ready so I don't go too far down the wrong road. On 10/11/01 5:03 AM, "Simon Cozens" <[EMAIL PROTECTED]> wrote: > On Wed, Oct 10, 2001 at 05:13:21PM -0700, Zach Lipton wrote: >> I was thinking about configure and was wondering why we have to keep >> everything all in one file. Why not create a config/ directory (or something >> like that) and have a set of .cm files (ConfigureModule) that do the actual >> work, using a helper module to do the grunt work. That way, to add a >> configure question, I just write something like: > > Yep, that's the plan. We're reimplementing metaconfig in Perl...
Mais um
One more example... this time to calculate the maximum common divisor. One more question... does jsr working? I can't use it... And, finally... can anybody explain the argument to return? Thanks.. Cheers -- | Alberto Manuel Brandão Simões | | [EMAIL PROTECTED] | | http://numexp.sourceforge.net | # (C)2001 Alberto Simões # # max common divisor (mdc - maximo divisor comum) # # Values are placed on I1 and I2. Result is on any of them # # NOTE: I don't really know if this is the best algorith, # the idea is to be, only an example. set I1, 7 set I2, 20 LOOP: eq I1, I2, FINISH gt I1, I2, OTHER sub I2, I2, I1 branch LOOP OTHER: sub I1, I1, I2 branch LOOP FINISH: print I1 end
Re: Revamping the build system
At 06:10 PM 10/10/2001 -0700, Dave Storrs wrote: >Any interest in using something less painful than Make for this? I was >thinking of Cons, myself...built in Perl 5 (which we are already requiring >you to have), and much more friendly than Make. Don't forget that our requirement for perl 5 is ultimately temporary. The build system is the one thing that *can't* be in perl, since we'd need a working simple makefile to build the first go-round of perl 6 which then configures and rebuilds itself. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Breaking up configure
On Wed, Oct 10, 2001 at 05:13:21PM -0700, Zach Lipton wrote: > I was thinking about configure and was wondering why we have to keep > everything all in one file. Why not create a config/ directory (or something > like that) and have a set of .cm files (ConfigureModule) that do the actual > work, using a helper module to do the grunt work. That way, to add a > configure question, I just write something like: Yep, that's the plan. We're reimplementing metaconfig in Perl... -- It is now pitch dark. If you proceed, you will likely fall into a pit.
