[COMMIT] Major GC Refactoring
Last night I committed the GC refactoring I submitted the other day, then spent a couple hours putting out fires on the tinderbox. The last thing I attempted was to align my pointer accesses, because Tru64 was giving lots of warnings about Unaligned access pid=246428 va=0x1400b7364 pc=0x12005e408 ra=0x120037228 inst=0xb52c0010 After attempting to solve them for myself unsuccessfully, I went to: http://csa.compaq.com/Dev_Tips/unalign.htm and http://csa.compaq.com/Dev_Tips/unalign_example.htm which give instructions on tracking them down. Turns out set_keyed_string, and plenty of other parrot code, has the same problems I did. I believe there's a way to turn this off in the compilation, but I'm not sure if we want to do that. Finally, it appears that there are still 64-bit issues with the code I comitted last night, mostly in regards to the GC failing on the more intensive tests. I will try to look into this tomorrow night, but I'm not sure how much progress I'll be able to make, since I'm quite unfamiliar with gdb, and 64-bit platforms (and each individually, for that matter. :) Worst comes to worst, and DrForr needs to make 0.0.7, I can undo the changes to get the tests passing on all platforms, again. And then try it with JUST the stackwalking code to avoid neonate problems. Thanks, Mike Lambert
Re: PARROT QUESTIONS: Use the source, Luke
On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote: > At 09:27 PM 7/14/2002 -0700, Brent Dax wrote: > > Wow, Brent lives! :) > > >Here's the rules, roughly as they stand right now: > > > >-Functions start with Parrot_[a-z] or just [a-z]. > >-Typedefed names start with Parrot_[A-Z] or just [A-Z]. > >-Macros and constants start with PARROT_[A-Z] or just [A-Z]. > >-Struct names are of the form parrot_[a-z_]+_t. > > > >Perhaps we should change the rules to this: > > > >-Public functions start with Parrot_[a-z]. > >-Typedefed names start with Parrot_[A-Z] or just [A-Z]. > >-Macros and constants start with PARROT_[A-Z] or just [A-Z]. > >-Struct names are of the form parrot_[a-z_]+_t. > >-Private functions start with parrot_[a-z] or just [a-z]. > > > >If people want that scheme, speak now or forever hold your peace. :^) > > > ># Here's four: > ># > ># Parrot > ># parrot > ># _Parrot > ># _parrot > ># > ># Here's two more: > ># > ># __Parrot > ># __parrot > > > >The last four are reserved by various C and C++ standards. So are type names ending in _t, so that makes the Struct names rule above naughty too > So, I say use Parrot, _Parrot, or __Parrot with abandon and forever put > this ANSI/POSIX collision argument to bed. Although I agree it is unlikely we're going to collide, unless we encounter a POSIX standard parrot. (Camels have been jokingly described as a horse designed by a committee, so what would a parrot designed by committee look like?) On Mon, Jul 15, 2002 at 11:26:34AM -0700, Brent Dax wrote: > If at some point in the future, we no longer need Parrot_time, I don't > think we should have to leave it in for backwards compatibility with > embedders. Perhaps we should export it *if they ask for it somehow*, > but not by default, and not in a way that implies that it'll always be > there till the end of time. Which is why I think it would be really useful to be damn clear in what functions are part of the public API, and which are private and may go away, so that anyone with a copy of grep and nm could work out the public API by filtering the list of functions defined by the parrot library. (As we can't hide functions that need to be seen in multiple parrot object files, but aren't for public consumption) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
[PATCH] pmc.c
Hello i've added a function in pmc.c that handles
init_pmc() calls..
cheers
/Josef
--- ../parrot.key.orig/pmc.cThu Jul 18 00:37:54 2002
+++ pmc.c Thu Jul 18 15:32:20 2002
@@ -96,6 +96,41 @@
return pmc;
}
+PMC *
+pmc_new_sized_pmc(struct Parrot_Interp *interpreter,
+INTVAL base_type, PMC *p)
+{
+ PMC *pmc = new_pmc_header(interpreter);
+
+if (!pmc) {
+internal_exception(ALLOCATION_ERROR,
+ "Parrot VM: PMC allocation failed!\n");
+return NULL;
+}
+
+/* Ensure the PMC survives DOD during this function */
+pmc->flags |= PMC_immune_FLAG;
+
+pmc->vtable = &(Parrot_base_vtables[base_type]);
+
+if (!pmc->vtable || !pmc->vtable->init_pmc) {
+/* This is usually because you either didn't call init_world early
+ * enough or you added a new PMC class without adding
+ * Parrot_(classname)_class_init to init_world. */
+PANIC("Null vtable used");
+return NULL;
+}
+
+/* Call init_pmc with correct pmc */
+pmc->vtable->init_pmc(interpreter, pmc, p);
+
+/* Let the caller track this PMC */
+pmc->flags &= ~PMC_immune_FLAG;
+return pmc;
+}
+
+
+
/*
* Local variables:
* c-indentation-style: bsd
--- ../parrot.key.orig/include/parrot/pmc.h Thu Jul 18 00:37:54 2002
+++ include/parrot/pmc.hThu Jul 18 15:36:28 2002
@@ -122,6 +122,9 @@
PMC *pmc_new(struct Parrot_Interp *interpreter, INTVAL base_type);
PMC *pmc_new_sized(struct Parrot_Interp *interpreter, INTVAL base_type,
INTVAL size);
+PMC *pmc_new_sized_pmc(struct Parrot_Interp *interpreter, INTVAL base_type,
+ PMC *p);
+
#endif
[PATCH] Key.pmc and some core.ops functions
I've added a key.pmc. Why would we need a key.pmc one might ask.
Well it will be used when assigning keys through init_pmc(PMC *).
Example:
asm code
new P0, PerlArray[2] // array with size 2
will call
new_keyed_integer
which inturn constructs a key PMC to store its keyes
pmc_new_sized_pmc(., PMC *p)
Aldo Calpini ( alias dada on irc ) had a couple of good arguments why
having a key.pmc. I just want this patch in because i need it for my
soon to come matrix.pmc.
Those ops included in this patch RELIES HEAVILY on my earlier pmc.c patch
that added a pmc_new_sized_pmc function.
/Josef Höök
diff -urN parrot.orig/MANIFEST parrot/MANIFEST
--- parrot.orig/MANIFESTThu Jul 18 00:37:54 2002
+++ parrot/MANIFEST Thu Jul 18 00:44:52 2002
@@ -28,6 +28,7 @@
classes/perlnum.pmc
classes/perlstring.pmc
classes/perlundef.pmc
+classes/key.pmc
classes/pmc2c.pl
config/auto/byteorder.pl
config/auto/byteorder/test_c.in
diff -urN parrot.orig/assemble.pl parrot/assemble.pl
--- parrot.orig/assemble.pl Thu Jul 18 00:37:54 2002
+++ parrot/assemble.pl Thu Jul 18 15:25:27 2002
@@ -127,17 +127,18 @@
# XXX Must be generated from the enum in include/parrot/pmc.h
#
bless $self,$class;
- $self->{constants}{Array} = 0;
- $self->{constants}{PerlUndef} = 1;
- $self->{constants}{PerlInt} = 2;
- $self->{constants}{PerlNum} = 3;
- $self->{constants}{PerlString} = 4;
- $self->{constants}{PerlArray} = 5;
- $self->{constants}{PerlHash} = 6;
- $self->{constants}{Pointer} = 7;
- $self->{constants}{IntQueue} = 8;
- $self->{constants}{Sub} = 9;
- $self->{constants}{Coroutine} = 10;
+ $self->{constants}{Key} = 0;
+ $self->{constants}{Array} = 1;
+ $self->{constants}{PerlUndef} = 2;
+ $self->{constants}{PerlInt} = 3;
+ $self->{constants}{PerlNum} = 4;
+ $self->{constants}{PerlString} = 5;
+ $self->{constants}{PerlArray} = 6;
+ $self->{constants}{PerlHash} = 7;
+ $self->{constants}{Pointer} = 8;
+ $self->{constants}{IntQueue} = 9;
+ $self->{constants}{Sub} = 10;
+ $self->{constants}{Coroutine} = 11;
$self;
}
diff -urN parrot.orig/classes/key.pmc parrot/classes/key.pmc
--- parrot.orig/classes/key.pmc Thu Jan 1 01:00:00 1970
+++ parrot/classes/key.pmc Thu Jul 18 16:11:17 2002
@@ -0,0 +1,902 @@
+/* Key.pmc
+ * Copyright: (When this is determined...it will go here)
+ * CVS Info
+ * $Id: key.pmc,v 1.2 2002/07/18 14:09:14 joh Exp joh $
+ * Overview:
+ * These are the vtable functions for the Key base class
+ * Data Structure and Algorithms:
+ * History:
+ * Notes:
+ * References:
+ */
+
+#include "parrot/parrot.h"
+
+pmclass Key {
+
+void init () {
+ SELF->data = NULL;
+
+}
+
+void init_pmc (PMC* initializer) {
+ if((initializer->vtable->type(INTERP, SELF)) == enum_class_Key) {
+ SELF->data = initializer->data;
+ }
+}
+
+void morph (INTVAL type) {
+}
+
+PMC* mark (PMC* tail) {
+ return NULL;
+}
+
+void destroy () {
+}
+
+INTVAL type () {
+ return enum_class_Key;
+}
+
+INTVAL type_keyed (KEY* key) {
+ return 0;
+}
+
+INTVAL type_keyed_int (INTVAL* key) {
+ return 0;
+}
+
+UINTVAL subtype (INTVAL type) {
+ return 0;
+}
+
+UINTVAL subtype_keyed (KEY* key, INTVAL type) {
+ return 0;
+}
+
+UINTVAL subtype_keyed_int (INTVAL* key, INTVAL type) {
+ return 0;
+}
+
+STRING* name () {
+ return whoami;
+}
+
+STRING* name_keyed (KEY* key) {
+ return NULL;
+}
+
+STRING* name_keyed_int (INTVAL* key) {
+ return NULL;
+}
+
+PMC* clone () {
+PMC *dest;
+dest = pmc_new(INTERP, enum_class_Key);
+dest->data=SELF->data;
+return dest;
+}
+
+PMC* clone_keyed (KEY* key) {
+ // As we are a key just copy the data
+ PMC *dest;
+ dest = pmc_new(INTERP, enum_class_Key);
+ dest->data=SELF->data;
+ return dest;
+}
+
+PMC* clone_keyed_int (INTVAL* key) {
+ return NULL;
+}
+
+PMC* find_method (STRING* method_name) {
+ return NULL;
+}
+
+PMC* find_method_keyed (KEY* key, STRING* method_name) {
+ return NULL;
+}
+
+PMC* find_method_keyed_int (INTVAL* key, STRING* method_name) {
+ return NULL;
+}
+
+INTVAL get_integer () {
+ // need changes
+ INTVAL retval;
+ if(((KEY *)SELF->data)) {
+ retval = ((KEY*)SELF->data)->atom.val.int_val;
+ }
+ return retval;
+}
+
+INTVAL get_integer_keyed (KEY* key) {
+ return 0;
+}
+
+INTVAL get_integer_keyed_int (INTVAL* key) {
+ return 0;
+}
+
+FLOATVAL get_number () {
+ return 0;
+}
+
+FLOATVAL get_number_keyed (KEY* key) {
+ return 0;
+}
+
+FLOATVAL get_number_keyed_int (INTVAL* key) {
+
Re: [PATCH] Key.pmc and some core.ops functions
Josef Höök wrote: > Aldo Calpini ( alias dada on irc ) had a couple of good arguments > why having a key.pmc. I just want this patch in because i need it > for my soon to come matrix.pmc. that's embarassing, but it must have been someone else. I only ranted on IRC about tuple.pmc and some other braindead ideas, and while I followed the discussion about key.pmc, I didn't provide any good argument ;-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [PATCH] Key.pmc and some core.ops functions
On Thu, 18 Jul 2002, Aldo Calpini wrote: > Josef Höök wrote: > > Aldo Calpini ( alias dada on irc ) had a couple of good arguments > > why having a key.pmc. I just want this patch in because i need it > > for my soon to come matrix.pmc. > > that's embarassing, but it must have been someone else. > > I only ranted on IRC about tuple.pmc and some other braindead ideas, > and while I followed the discussion about key.pmc, I didn't provide > any good argument ;-) > > cheers, > Aldo > Kernel: OOPS Sorry about that.. I have a tendency to forget names.. :-( > __END__ > $_=q,just perl,,s, , another ,,s,$, hacker,,print; > >
Re: [COMMIT] Major GC Refactoring
On Thu, 18 Jul 2002, Mike Lambert wrote:
> Last night I committed the GC refactoring I submitted the other day, then
> spent a couple hours putting out fires on the tinderbox.
>
> The last thing I attempted was to align my pointer accesses, because Tru64
> was giving lots of warnings about
> Unaligned access pid=246428 va=0x1400b7364 pc=0x12005e408
> ra=0x120037228 inst=0xb52c0010
Using perl-5.8.0-RC3 compiled with 64bit integers and gcc-2.8.1 to build
Parrot, I get 51 warnings of the sort "cast increases required alignment
of target type" One or more of these may be relevant to the failures seen
on 64-bit machines.
For example, one warning in headers.c is:
headers.c:364: warning: cast increases required alignment of target type
and here is line 364:
ptr = (void**)((char*)headers->bufstart + headers->buflen - sizeof(void*));
On some architectures, some pointers must be aligned on certain
wordsize boundaries. For example, all void* pointers might be required to
be aligned on 8-byte boundaries. (See perl5's $Config{alignbytes}).
Although headers->bufstart is a void*, and hence is suitably aligned,
there is apparently no guarantee that headers->buflen is a suitably
sized integer. If it were '7', for example, then ptr would end up
trying to point to an odd address, and that might be forbidden.
Sometimes, you know from the larger picture that alignment *is*
guaranteed, and the warning can be ignored, even if the compiler can't
figure that out. Other times, howevever, the warning is pointing to a
real potential problem. I haven't traced through the headers code to
figure out for myself which it is in this case.
Not too long ago, I went through all the packfile stuff and changed it
from being a stream of char (all of which were assumed to be items
of sizeof(opcode_t)) to an actual stream of opcode_t. (Look at the
operations on "cursor" in packfile.c to see what I mean.)
Hmm. I see one packfile warning has snuck back in:
packfile.c:301: warning: cast increases required alignment of target type
cursor = (opcode_t*)((char*)packed + PACKFILE_HEADER_BYTES);
That's actually harmless, since PACKFILE_HEADER_BYTES = 16, so it is
an integral number of opcode_t's. The warning can be ignored. But
the statement could also be better written as
cursor = packed + PACKFILE_HEADER_BYTES/sizeof(opcode_t);
although the paranoid would include a test, perhaps at Configure
time, to verify that this still works -- suppose someone changes
PACKFILE_HEADER_BYTES to 17!
Generally speaking, if you have to cast to (char *) in order to do
pointer arithmetic, you also have to be very very careful that your
result is still suitably aligned for the final target.
Here is the full list of alignment warnings I got this morning:
intqueue.pmc:92: warning: cast increases required alignment of target type
debug.ops:96: warning: cast increases required alignment of target type
debug.ops:106: warning: cast increases required alignment of target type
packfile.c:301: warning: cast increases required alignment of target type
hash.c:95: warning: cast increases required alignment of target type
hash.c:101: warning: cast increases required alignment of target type
hash.c:112: warning: cast increases required alignment of target type
jit.c:213: warning: cast increases required alignment of target type
include/parrot/jit_emit.h:292: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:299: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:316: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:317: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:321: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:330: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:331: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:337: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:343: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:368: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:374: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:398: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:404: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:428: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:434: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:462: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:468: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:486: warning: cast increases required alignment of target
type
include/parrot/jit_emit.h:499:
Re: Perl 6, The Good Parts Version
> "pdcawley" == pdcawley <[EMAIL PROTECTED]> writes: pdcawley> Would I be right in thinking that it should be possible to implement a pdcawley> prolog like language almost entirely within a regular expression? pdcawley> Anyone want to step up to the plate? I've already done a Scheme proof pdcawley> of concept after all... This is already a thread on perlmonks.org... see user "ovid". -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [netlabs #757] Problem mixing labels, comments and quote-marks
On Sat, 13 Jul 2002, Tom Hughes wrote: > Of course... The attached patch should handle that I think... This patch is breaking several Solaris 32-bit tests. The following assembly (from t/pmc/perlarray1.pbc): new P0,.PerlArray set P0,0 set I0,P0 print I0 print "\n" set P0,1 set I0,P0 print I0 print "\n" set P0,5 set I0,P0 print I0 print "\n" end Is assembling to this (with this patch installed): # # Disassembly of Parrot Byte Code from 't/pmc/perlarray1.pbc' # # Segments: # # * Wordsize:1 bytes # * Byteorder:1 bytes # * Major:1 bytes # * Minor:1 bytes # * Flags:1 bytes # * FloatType:1 bytes # * Unused: 10 bytes # * Magic Number:8 bytes # * Opcode Type:8 bytes # * Fixup Table: 0 bytes # * Const Table:64 bytes # * Byte Code: 272 bytes (34 opcode_ts) # # Constant Type Data # -- #0 PFC_STRING"\n" # # WORD BYTE BYTE CODE LABEL OPERATIONARGUMENTS # -- -- --- []: 0751 0005 loadlib P0, S5 0006 [0024]: 0088 set P0, 0 0012 [0048]: 0093 set I0, P0 0018 [0072]: 0019 printI0 0022 [0088]: 0024 print[sc:0] 0026 [0104]: 0088 0001 set P0, 1 0032 [0128]: 0093 set I0, P0 0038 [0152]: 0019 printI0 0042 [0168]: 0024 print[sc:0] 0046 [0184]: 0088 0005 set P0, 5 0052 [0208]: 0093 set I0, P0 0058 [0232]: 0019 printI0 0062 [0248]: 0024 print[sc:0] 0066 [0264]: end When I roll back the patch, this is how it (correctly) disassembles: # # Disassembly of Parrot Byte Code from 't/pmc/perlarray1.pbc' # # Segments: # # * Wordsize:1 bytes # * Byteorder:1 bytes # * Major:1 bytes # * Minor:1 bytes # * Flags:1 bytes # * FloatType:1 bytes # * Unused: 10 bytes # * Magic Number:8 bytes # * Opcode Type:8 bytes # * Fixup Table: 0 bytes # * Const Table:64 bytes # * Byte Code: 272 bytes (34 opcode_ts) # # Constant Type Data # -- #0 PFC_STRING"\n" # # WORD BYTE BYTE CODE LABEL OPERATIONARGUMENTS # -- -- --- []: 0725 0005 new P0, 5 0006 [0024]: 0088 set P0, 0 0012 [0048]: 0093 set I0, P0 0018 [0072]: 0019 printI0 0022 [0088]: 0024 print[sc:0] 0026 [0104]: 0088 0001 set P0, 1 0032 [0128]: 0093 set I0, P0 0038 [0152]: 0019 printI0 0042 [0168]: 0024 print[sc:0] 0046 [0184]: 0088 0005 set P0, 5 0052 [0208]: 0093 set I0, P0 0058 [0232]: 0019 printI0 0062 [
[perl #15099] [PATCH] Remove redundant comments in test suite
# New Ticket Created by Simon Glover # Please include the string: [perl #15099] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15099 > These comments don't seem to be needed any more. Simon --- t/pmc/array.t.old Thu Jul 18 13:44:39 2002 +++ t/pmc/array.t Thu Jul 18 13:45:37 2002 @@ -44,20 +44,20 @@ output_is(<<'CODE', <<'OUTPUT', "Setting new P0, .Array set P0, 1 - set P0[0],-7 # set P0[0], -7 - set I0,P0[0] # set I0, P0[0] + set P0[0],-7 + set I0,P0[0] eq I0,-7,OK_1 print "not " OK_1: print "ok 1\n" - set P0[0],3.7 # set P0[0], 3.7 - set N0,P0[0] # set N0, P0[0] + set P0[0],3.7 + set N0,P0[0] eq N0,3.7,OK_2 print "not " OK_2: print "ok 2\n" - set P0[0],"Buckaroo" # set P0[0], "Buckaroo" - set S0,P0[0] # set S0, P0[0] + set P0[0],"Buckaroo" + set S0,P0[0] eq S0,"Buckaroo",OK_3 print "not " OK_3: print "ok 3\n" --- t/pmc/perlarray.t.old Thu Jul 18 13:44:45 2002 +++ t/pmc/perlarray.t Thu Jul 18 13:47:09 2002 @@ -29,28 +29,28 @@ OUTPUT output_is(<<'CODE', <<'OUTPUT', "set/get by index"); new P0,.PerlArray - set P0[0],3 # set P0[0], 3 - set I1,P0[0] # set I1, P0[0] + set P0[0],3 + set I1,P0[0] print I1 print "\n" set P0,2 - set P0[1],3.7 # set P0[1], 3.7 - set N1,P0[1] # set N1, P0[1] + set P0[1],3.7 + set N1,P0[1] print N1 print "\n" set P0,3 - set P0[2],"hey" # set P0[2], "hey" - set S1,P0[2] # set S1, P0[2] + set P0[2],"hey" + set S1,P0[2] print S1 print "\n" set P0, 4 new P1, .PerlInt set P1, 42 - set P0[3],P1 # set P0[3], P1 - set P2,P0[3] # set S1, P0[3] + set P0[3],P1 + set P2,P0[3] print P2 print "\n" @@ -64,25 +64,25 @@ OUTPUT output_is(<<'CODE', <<'OUTPUT', "same, but with implicit resizing"); new P0,.PerlArray - set P0[0],3 # set P0[0], 3 - set I1,P0[0] # set I1, P0[0] + set P0[0],3 + set I1,P0[0] print I1 print "\n" - set P0[1],3.7 # set P0[1], 3.7 - set N1,P0[1] # set N1, P0[1] + set P0[1],3.7 + set N1,P0[1] print N1 print "\n" - set P0[2],"hey" # set P0[2], "hey" - set S1,P0[2] # set S1, P0[2] + set P0[2],"hey" + set S1,P0[2] print S1 print "\n" new P1, .PerlInt set P1, 42 - set P0[3],P1 # set P0[3], P1 - set P2,P0[3] # set S1, P0[3] + set P0[3],P1 + set P2,P0[3] print P2 print "\n" @@ -132,7 +132,7 @@ output_is(<<'CODE', <<'OUTPUT', "If P"); branch NEXT TR: print "true\n" -NEXT: set P0[0], 1 # set P0[0], 1 +NEXT: set P0[0], 1 if P0, TR2 print "false\n" branch NEXT2 @@ -167,104 +167,104 @@ output_is(<<'CODE', <<'OUTPUT', "Negativ print "not " OK_1: print "ok 1\n" - set P0[0],7 # set P0[0], 7 + set P0[0],7 set I0,P0 eq I0,1,OK_2 print "not " OK_2: print "ok 2\n" - set I0,P0[0]# set I0, P0[0] + set I0,P0[0] eq I0,7,OK_3 print "not " OK_3: print "ok 3\n" - set I0,P0[-1] # set I0, P0[-1] + set I0,P0[-1] eq I0,7,OK_4 print "not " OK_4: print "ok 4\n" - set P0[-1],7# set P0[-1], 7 + set P0[-1],7 set I0,P0 eq I0,1,OK_5 print "not " OK_5: print "ok 5\n" - set I0,P0[0]# set I0, P0[0] + set I0,P0[0] eq I0,7,OK_6 print "not " OK_6: print "ok 6\n" - set I0,P0[-1] # set I0, P0[-1] + set I0,P0[-1] eq I0,7,OK_7 print "not " OK_7: print "ok 7\n" - set P0[0],7.2 # set P0[0], 7.2 + set P0[0],7.2 set I0,P0 eq I0,1,OK_8 print "not " OK_8: print "ok 8\n" - set N0,P0[0]# set N0, P0[0] + set N0,P0[0] eq N0,7.2,OK_9 print "not " OK_9: print "ok 9\n" - set N0,P0[-1] # set N0, P0[-1] + set N0,P0[-1] eq N0,7.2,OK_10 print "not " OK_10: print "ok 10\n" - set P0[-1],7.2 # set P0[-1], 7.2 + set P0[-1],7.2 set I0,P0 eq I0,1,OK_11 print "not " OK_11: print "ok 11\n" - set N0,P0[0]# set N0, PO[0] + set N0,P0[0] eq N0,7.2,OK_12 print "not " OK_12: print "ok 12\n" - set N0,P0[-1] # set N0, P0[-1] + set N0,P0[-1] eq N0,7.2,OK_13 print "not " OK_13: print "ok 13\n" - set P0[0],"Buckaroo" # set P0[0], "Buckaroo" + set P0[0],"Buckaroo" set I0,P0 eq I0
Re: Streams vs. Descriptors
On Tuesday, July 16, 2002, 5:42:28 PM, you (mailto:[EMAIL PROTECTED]) wrote: > On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote: >> And the aioread/aiowrite/listio, etc. are a POSIX standard now, so they >> should be reasonably available on most UNIXen. > Are the aio* calls available on Windows? No, but since it would seem helpful, here is the quick version of asynchronous IO on windows. NB. Windows NT/2000/XP supports async io on HDDs as well as sockets, pipes, ...; Win 9x/ME doesn't do it for HDDs. Basically there are three methods of performing asynchronous io on Windows, and these are essentially the same whatever you are reading from/writing to (including accepting connections on sockets). 1. Callback function. 2. Signal an event 3. IO Completion The first two are linked to individual IO operations (ReadFile(Ex), WriteFile(Ex)) if the handle was opened with the appropriate flag. In the first case the function is passed to the IO call, in the second an "OVERLAPPED" structure is passed containing the handle of an event. When using an event you can then wait for the event to be signalled (in much the same way that other kernel objects are signalled). Additionally there is a method for polling for completion. The third way involves associating the file (or whatever) handle with an IOCompletion port, you then have one or more threads sitting in a blocking call to PostQueuedCompletionStatus which returns as the various IO operations complete). The whole area shares a lot with the thread APIs and generally is not too hard to use once you get the hang of the style... however quite how compatible with the POSIX/Mac/... style I have no idea. (For more information see http://msdn.microsoft.com and follow the link to the library, File IO comes under Windows Base Services.) -- Richard mailto:[EMAIL PROTECTED]
Re: [netlabs #757] Problem mixing labels, comments and quote-marks
In message <[EMAIL PROTECTED]> "David M. Lloyd" <[EMAIL PROTECTED]> wrote: > On Sat, 13 Jul 2002, Tom Hughes wrote: > > > Of course... The attached patch should handle that I think... > > This patch is breaking several Solaris 32-bit tests. The following > assembly (from t/pmc/perlarray1.pbc): I've just tried that test on a Solaris 7 machine and it ran fine and produced the correct bytecode. I can't honestly see how that patch could cause it to generate completely the wrong op... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Subs?
On Wed, 2002-07-17 at 22:01, Melvin Smith wrote: > Subs, co-routines and continuations are at a very limited, but functional > state. > > Basically you can create a PMC with a bytecode address or label > and use the call/callco/callcc ops on it. > Subs seem to be broken right now. Here is a pasm file set_addr I0, MYSUB new P0, .Sub, I0 call end MYSUB: print "this is the sub\n" ret and the output from running the associated pbc file > ./parrot rough.pbc Segmentation fault > ./parrot -t rough.pbc PC=0; OP=65 (set_addr_i_ic); ARGS=(I0=0, 9) PC=3; OP=727 (new_p_ic_i); ARGS=(P0=0x81403c0, 9, I0=135578484) PC=7; OP=757 (call) If I understand things correctly, the problem is that the address argument (i.e. the last argument) to the new op is being ignored, and sub->init is always set to 0. So the call op is returning 0 as the next op for the interpreter (in core.ops): goto ADDRESS(sub->init); /* always 0 */ Is there a different pasm syntax I should be using for creating and calling subs? I seem to remember some discussion about changing how things are passed to constructors but I am not sure what the conclusion was. -- Jonathan Sillito
Re: Subs?
At 02:16 PM 7/18/2002 -0600, Jonathan Sillito wrote: >On Wed, 2002-07-17 at 22:01, Melvin Smith wrote: > > Subs, co-routines and continuations are at a very limited, but functional > > state. > > > > Basically you can create a PMC with a bytecode address or label > > and use the call/callco/callcc ops on it. > > > >Subs seem to be broken right now. Here is a pasm file > > set_addr I0, MYSUB > new P0, .Sub, I0 > call > end > > MYSUB: > print "this is the sub\n" > ret The temporary fix is to do: new P0, .Sub set_addr I0, MYSUB set P0, I0 call However, in my opinion, this is kludgy. -Melvin
.dev files
Ok, I would like to try and summarize what should be done for .dev files 1.) .dev files should not be used to describe individual functions. Instead, the .c file that contains the function should be used. 2.) .dev files should contain the sections as mentioned in PDD07. 3.) .dev files should mainly be used to describe a.) the general overview of the file in question (what it is for, where it fits in) b.) any algorithms that were chosen for use in that file along with a description of why. So, my final question is: should .dev files be plain text or POD?
RE: .dev files
Tanton Gibbs:
# So, my final question is: should .dev files be plain text or POD?
My vote is for pod. pod is close enough to plain text that I don't see
why it shouldn't be in it.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: cvs commit: parrot/lib/Parrot/Configure RunSteps.pm
At 20:15 on 07/18/2002 -, [EMAIL PROTECTED] wrote: > NOTE: The test file might not work right if the platform doesn't support ff lush(stdout). If > someone has a better idea, let me know. Are there platforms which do not? AFAIK, fflush() is specified in the C standard. If you want to be especially paranoid, it might make sense to run make "x" a parameter to your test program and run it once for each of the alignment sizes, rather than trying to do it all in one go. --Josh
Re: .dev files
At 14:18 on 07/18/2002 PDT, "Brent Dax" <[EMAIL PROTECTED]> wrote: > Tanton Gibbs: > # So, my final question is: should .dev files be plain text or POD? > > My vote is for pod. pod is close enough to plain text that I don't see > why it shouldn't be in it. Me too. That way you can all come to your senses and move them into the ..c files more easily. --Josh
[PATCH] dod.dev
This is the .dev file for dod.c I realize that the garbage collection is still kind of (ok very) volatile right now, but I thought we could go ahead and have this for people to look at and make comments on. BTW, I submitted this patch to the RT system, but it refused my email...any idea why? Thanks! Tanton dod.dev Description: Binary data
Re: [PATCH] Subs?
On Thu, 2002-07-18 at 14:27, Melvin Smith wrote:
> The temporary fix is to do:
>
> new P0, .Sub
> set_addr I0, MYSUB
> set P0, I0
> call
Attached are three small patches, two of them change example files
(examples/assembly/coroutine.pasm and examples/assembly/sub.pasm)
to use this fix that Melvin mentioned.
The third is a fix for a simple bug in coroutine.pmc: Parrot_Coroutine
was being cast to a Parrot_Sub which caused a seg fault when callco was
called.
(This is my first attempt at sending patches to the list, so any
comments about how this should really be done would be appreciated.)
--
Jonathan Sillito
Index: examples/assembly/sub.pasm
===
RCS file: /cvs/public/parrot/examples/assembly/sub.pasm,v
retrieving revision 1.2
diff -u -r1.2 sub.pasm
--- examples/assembly/sub.pasm 7 Jun 2002 23:41:21 - 1.2
+++ examples/assembly/sub.pasm 18 Jul 2002 22:51:09 -
@@ -1,13 +1,20 @@
+# sub.pasm
+#
# Sample sub-routines in Parrot
#
-# Create 2 subroutines
+# $Id: $
#
-set_addr I0, SUB
-new P0, .ParrotSub, I0
+
+# Create 2 subroutines
+set_addr I0, SUB
+new P0, .Sub
+set P0, I0
save P0
-new P0, .ParrotSub, I0
+new P0, .Sub
+set P0, I0
# Calling convention says P0 will contain the sub
call
+
restore P0
# Call second one
call
Index: classes/coroutine.pmc
===
RCS file: /cvs/public/parrot/classes/coroutine.pmc,v
retrieving revision 1.2
diff -u -r1.2 coroutine.pmc
--- classes/coroutine.pmc 18 Jul 2002 03:48:33 - 1.2
+++ classes/coroutine.pmc 18 Jul 2002 22:53:12 -
@@ -77,11 +77,11 @@
}
*/
void set_integer (PMC * value) {
- ((struct Parrot_Sub*)SELF->data)->init = (opcode_t*)value->vtable->get_integer(INTERP, value);
+ ((struct Parrot_Coroutine*)SELF->data)->init = (opcode_t*)value->vtable->get_integer(INTERP, value);
}
void set_integer_native (INTVAL value) {
- ((struct Parrot_Sub*)SELF->data)->init = (opcode_t*)value;
+ ((struct Parrot_Coroutine*)SELF->data)->init = (opcode_t*)value;
}
/*
void set_integer_bigint (BIGINT value) {
Index: examples/assembly/coroutine.pasm
===
RCS file: /cvs/public/parrot/examples/assembly/coroutine.pasm,v
retrieving revision 1.1
diff -u -r1.1 coroutine.pasm
--- examples/assembly/coroutine.pasm 7 Jun 2002 23:36:03 - 1.1
+++ examples/assembly/coroutine.pasm 18 Jul 2002 22:50:56 -
@@ -1,11 +1,17 @@
+# coroutine.pasm
+#
# Sample co-routines in Parrot
#
-# Create 2 coroutines
+# $Id: $
#
+
set_addr I0, MYCOROUTINE
-new P0, .ParrotCoroutine, I0
+new P0, .Coroutine
+set P0, I0
save P0
-new P0, .ParrotCoroutine, I0
+new P0, .Coroutine
+set P0, I0
+
# Calling convention says P0 will contain the sub so..
print "Calling 1st co-routine\n"
callco
Re: [PATCH] Subs?
At 05:00 PM 7/18/2002 -0600, Jonathan Sillito wrote: >On Thu, 2002-07-18 at 14:27, Melvin Smith wrote: > > The temporary fix is to do: >Attached are three small patches, two of them change example files >(examples/assembly/coroutine.pasm and examples/assembly/sub.pasm) >to use this fix that Melvin mentioned. > >The third is a fix for a simple bug in coroutine.pmc: Parrot_Coroutine >was being cast to a Parrot_Sub which caused a seg fault when callco was >called. Applied all of these. Thanks. -Melvin
Re: [PATCH] dod.dev
At 06:35 PM 7/18/2002 -0400, Tanton Gibbs wrote: >This is the .dev file for dod.c Applied, thanks. They are all in docs/dev now. -Melvin
Re: [PATCH] dod.dev
I really dislike this. --Josh At 22:56 on 07/18/2002 EDT, Melvin Smith <[EMAIL PROTECTED]> wrote: > At 06:35 PM 7/18/2002 -0400, Tanton Gibbs wrote: > >This is the .dev file for dod.c > > Applied, thanks. > They are all in docs/dev now. > > -Melvin > >
Re: [PATCH] dod.dev
At 11:54 PM 7/18/2002 -0400, Josh Wilmes wrote: >I really dislike this. It wasn't my choice, I just asked for a consensus on IRC since I didn't see a final decision on p6i. Feel free to move them wherever. -Melvin
[RELEASE] Parrot 007: Secret Agent Bird
"There's a bird who leads a life of hacking >From everyone he meets / He gets some backing With every patch he takes / Another build we make Odds are he won't be the same tomorrow Secret Agent bird / Secret agent bird They've built the perl 6 grammar / And taken away a kluge" "Do you expect me to squawk()?" "No, Mr. Parrot. I expect you to die()." Apologies to Johnny Rivers and Ian Fleming. Welcome to version 0.0.7 of Parrot. The big news: Perl 6 grammar and a small but functional compiler! Check out languages/perl6 and the tests, but make sure to build languages/imcc first. Functional subroutine, coroutine, and continuation PMCs Global variables Intermediate bytecode compiler (languages/imcc) Assembler now entirely in perl, no more PakFile2.xs Working GC As per usual, if you want to join in on the fun, start by downloading a copy of parrot-0.0.7 at CPAN at one of the following URLs (or a mirror): http://www.cpan.org/authors/id/J/JG/JGOFF/parrot-0.0.7.tgz http://www.cpan.org/src/parrot-0.0.7.tgz To get the latest CVS version: http://cvs.perl.org/ has the information you need. Once you've unpacked Parrot, build it as follows: perl Configure.pl make make test After you've done that, look at docs/parrot.pod to learn more about it. Discussion of Parrot takes place on the perl6-internals mailing list, and patches should be sent there as well. If you're not subscribed, look at: http://lists.perl.org/showlist.cgi?name=perl6-internals for tips on how to subscribe. CVS commit access is given out to developers who consistently submit good patches to the mailing list. "The name is Parrot. Percy Parrot." -- Jeff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
RE: [RELEASE] Parrot 007: Configure.pl glitch on Windows
Building from clean CVS download on Windows 2K w/VC++: Parrot Version 0.0.7 Configure 2.0 Configure.pl was crashing at the minimum pointer alignment test. In Step.pm there are two functions that run a test program: cc_run() and cc_run_capture(). In both cases the program is initiated with the string: ./test.exe 2>&1 which doesn't work under Windows (those durn backwards path separators). Either: .\test.exe 2>&1 or test.exe 2>&1 will work. I suppose that there is a flag indicating that the platform is Windows that could be used as a conditional in these two functions. I admit, I'm lazy, I deleted two characters in cc_run_capture() just to get it to run on my system. I didn't find it necessary to modify cc_run() for some reason. After that, everything compiled successfully and I ran the basic tests: All tests successful, 6 subtests skipped. mma > -Original Message- > From: jgoff@[207.144.19.38] [mailto:jgoff@[207.144.19.38]]On Behalf Of > Jeff > Sent: Thursday, July 18, 2002 9:30 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [RELEASE] Parrot 007: Secret Agent Bird > > Welcome to version 0.0.7 of Parrot. > > To get the latest CVS version: > http://cvs.perl.org/ > > has the information you need. > > Once you've unpacked Parrot, build it as follows: > > perl Configure.pl > make > make test >
