[PATCH] bug in clear_live_bits
sweep 0 was making parrot segfault for me. The patch explains why.
Luke
Index: src/dod.c
===
RCS file: /cvs/public/parrot/src/dod.c,v
retrieving revision 1.81
diff -u -r1.81 dod.c
--- src/dod.c 10 Jan 2004 19:43:06 - 1.81
+++ src/dod.c 11 Jan 2004 06:17:18 -
@@ -735,12 +735,11 @@
static void
clear_live_bits(Parrot_Interp interpreter)
{
-struct Small_Object_Pool *pool;
+struct Small_Object_Pool *pool = interpreter->arena_base->pmc_pool;
struct Small_Object_Arena *arena;
UINTVAL i;
UINTVAL object_size = pool->object_size;
-pool = interpreter->arena_base->pmc_pool;
/* Run through all the buffer header pools and mark */
for (arena = pool->last_Arena; arena; arena = arena->prev) {
#if ARENA_DOD_FLAGS
Re: [PATCH] The Return of the Priority DOD
Jeff Clites <[EMAIL PROTECTED]> writes: > It gets set in include/parrot/pobj.h, and is basically set to true if > your platform has some flavor of memalign(), which allows you to > allocate chunks of memory with arbitrary power-of-2 alignment. So all > the platforms being tested on the tinders probably have this. (Of > course, you can manually set ARENA_DOD_FLAGS to false in the source, > for testing.) Actually, at least FreeBSD doesn't have either of the memalign()'s parrot looks for, which is what Nicholas (and I) ran into. (If OpenBSD doesn't have one either, there's some clean-up to be done in parrot/config/init/hints/openbsd.pl :-) ) -- Lars Balker RasmussenConsult::Perl
Some imc questions
I am trying to create an array of global functions from the postgres
library mainly to ease passing parameters amongst other things. I have
snipped some repetitive code out. I am sure that there are a few errors
in the way I am using imc so any corrections or pointers would be much
appreciated, I am quite new to it.
I have been using the docs to try and pick this up and I am having a
hard time... imcc.faq version December 2001 hint hint.
1 .pcc_sub _MAIN prototyped
2 .param pmc argv
3 .include "/home/parrot/parrot/library/postgres.pasm"
4 .include "/home/parrot/lib/postgreslib.imc"
5 .include "/home/parrot/lib/Commandlib.imc"
6
7
8
9 dbstring = "host=lhost dbname=Forum user=user
password=password"
10
11 print "Entering Connect\n"
12 .pcc_begin prototyped
13 .arg Command
14 .arg dbstring
15 .pcc_call connect
16 retconnect:
17 .result CONN
18 .result int_answer
19 .result message
20 .pcc_end
21 .PRINT("Connection Message = ", message, " \n")
22 .PRINT("Connection state = ", int_answer, " \n")
23 eq -1, int_answer, fail
24 eq 1, int_answer, go
25 fail:
26 .PRINT("\n", message, "\n")
27 end
28 go:
29
30 query = "select * from parrot"
31 print "Entering Send Query \n"
32 .pcc_begin prototyped
33 .arg Command
34 .arg CONN
35 .arg query
36 .pcc_call pqsendquery
37 ret:
38 .result message
39 .pcc_end
postgreslib.imc contains sub definitions as follows
47 .sym Sub pqsendquery
48 newsub pqsendquery, .Sub, _pqsendquery
49 .local pmc PQSENDQUERY
50 PQSENDQUERY = global "PostgreSQL::PQsendQuery"
51
52
53
54 .sym Sub PQconnectStart
55 newsub PQconnectStart, .Sub, p_PQconnectStart_t
56 .local pmc PQCONNECTSTART
57
58 PQCONNECTSTART = global "PostgreSQL::PQconnectStart"
59
60
61 .sym Sub PQconnectPoll
62 newsub PQconnectPoll, .Sub, i_PQconnectPoll_p
63 .local pmc PQCONNECTPOLL
64
65 PQCONNECTPOLL = global "PostgreSQL::PQconnectPoll"
Commanlib.imc is where I will build an array to contain all the subs to
call.
1 .local PerlArray Command
2 Command = new PerlArray
3
4 Command[0] = PQCONNECTSTART
5 Command[1] = PQCONNECTPOLL
6 Command[18] = PQSTATUS
7 Command[31] = PQSENDQUERY
8
9 #Command[2] = PQCONNECTDB
10 #Command[3] = PQSETDBLOGIN
11 #Command[4] = PQFINISH
12 #Command[5] = PQCONNDEFAULTS
13 #Command[6] = PQCONNINFOFREE
14 #Command[7] = PQRESETSTART
15 #Command[8] = PQRESETPOLL
16 #Command[9] = PQRESET
17 #Command[10] = PQREQUESTCANCEL
The first function call to "connect" works and the array "Command" gets
passed into the funtion as follows. You will notice below that to get it
to work I had to take a local copy of the passed in array or it got
clobbered???
241 .pcc_sub _connect prototyped
242 .param PerlArray Command
243 .param PerlString s
244 .local PerlString message
245 message = new PerlString
246
247 .local PerlArray C
248 C = new PerlArray
249 C = Command
250
251 .local pmc CONN
252 .local int int_answer
253 print "About to Connect\n"
254 P0 = C[0]
255 S5 = s
256 invoke
257 CONN = P5
Various magic things happen in this function and we get a connection to
postgres and pass the CONN back out.
When I call the next funtion on line 32 above the call works but the
Array has not been passed correctly. You can see in the following
function that I am taking a local copy again.
192 .pcc_sub _pqsendquery prototyped
193 .param PerlArray Command
194 .param pmc CONN
195 .param PerlString query
196 .local PerlArray C
197 C = new PerlArray
198 C = Command
199 .local int answer
200 .local PerlString message
201 .PRINT("Sending query now\n", query, "\n\n")
202 P0 = C[31]
203 P5 = CONN
204 S5 = query
205 invoke
206 answer = I5
207 eq 0, answer, error
208 eq 1, answer, good
209 error:
210 .PQerrorMessage(CONN, message)
211 branch finish
212 good:
213 message = "Successful\n"
214 finish:
215 .pcc_begin_return
216 .return message
217.pcc_end_return
218 end
219 .end
Running this fails with the followng error.
set_string_native() not implemented in class 'PerlArray'
which suggests that I am trying to set an Array to a string which is
obviously wrong.
I am pretty sure that I am butchering imc syntax through
Re: [PATCH] The Return of the Priority DOD
On Jan 10, 2004, at 11:54 AM, Nicholas Clark wrote: On Sat, Jan 10, 2004 at 08:39:51PM +0100, Leopold Toetsch wrote: Nicholas Clark <[EMAIL PROTECTED]> wrote: src/dod.c: In function `clear_live_bits': src/dod.c:755: `cur_arena' undeclared (first use in this function) The appended patch cures it (and all tests pass) but I'm not sure if it is correct. Ah yep, thanks. I didn't test the patch with ARENA_DOD_FLAGS disabled and finally diceded that "arena" is as meaningful and readable as "cur_arena" and changed that before submitting - a policy which almost always causes an error somewhere :) How come most tinderboxes kept going without failing? What's making the choice on the value of ARENA_DOD_FLAGS ? It gets set in include/parrot/pobj.h, and is basically set to true if your platform has some flavor of memalign(), which allows you to allocate chunks of memory with arbitrary power-of-2 alignment. So all the platforms being tested on the tinders probably have this. (Of course, you can manually set ARENA_DOD_FLAGS to false in the source, for testing.) JEff
[perl #24866] [PATCH] Unified harness for IMCC tests
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #24866] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=24866 > Hi, this patch is an attempt at resolving an item from 'parrot/TODO': Unify t/* and imcc/t/* tests, so that one harness has just one result summary. I have merged 'parrot/imcc/t/harness' into 'parrot/t/harness'. 'make test' now gives an unified report for all test case, including imcc/t/*/*.t and t/src/*.t 'make fulltest' gives 6 reports. 5 reports for different parrot options plus 1 report for t/src/*.t. Single tests for imcc should now be called as: cd parrot; perl t/harness imcc/t/imcpasm/cfg.1. The file imcc/t/harness can be removed. TODO: Check for all long parrot options in t/harness. TODO. It might make sense to merge imcc/TestCompiler.pm into lib/Parrot/Test.pm . CU, Bernhard -- /* [EMAIL PROTECTED] */ +++ GMX - die erste Adresse fÃr Mail, Message, More +++ Neu: Preissenkung fÃr MMS und FreeMMS! http://www.gmx.net unified_harness_20040110.patch Description: Binary data
[perl #24868] [PATCH] floor/ceil ops
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24868]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24868 >
I have added floor and ceil ops (like I did for floor in september,
but noone noticed).
--
Lars Balker RasmussenConsult::Perl
Index: ops/math.ops
===
RCS file: /cvs/public/parrot/ops/math.ops,v
retrieving revision 1.11
diff -u -a -r1.11 math.ops
--- ops/math.ops 23 Oct 2003 17:41:55 - 1.11
+++ ops/math.ops 10 Jan 2004 21:59:25 -
@@ -413,6 +413,64 @@
+=item B(inout NUM)
+
+Set $1 to the smallest integral value greater than or equal to $1.
+
+=item B(out INT, in NUM)
+
+=item B(out NUM, in NUM)
+
+Set $1 to the smallest integral value greater than or equal to $2.
+
+=cut
+
+inline op ceil(inout NUM) {
+ $1 = ceil( $1 );
+ goto NEXT();
+}
+
+inline op ceil(out INT, in NUM) {
+ $1 = (INTVAL)ceil($2);
+ goto NEXT();
+}
+
+inline op ceil(out NUM, in NUM) {
+ $1 = ceil($2);
+ goto NEXT();
+}
+
+
+
+=item B(inout NUM)
+
+Set $1 to the largest integral value less than or equal to $1.
+
+=item B(out INT, in NUM)
+
+=item B(out NUM, in NUM)
+
+Set $1 to the largest integral value less than or equal to $2.
+
+=cut
+
+inline op floor(inout NUM) {
+ $1 = floor( $1 );
+ goto NEXT();
+}
+
+inline op floor(out INT, in NUM) {
+ $1 = (INTVAL)floor($2);
+ goto NEXT();
+}
+
+inline op floor(out NUM, in NUM) {
+ $1 = floor($2);
+ goto NEXT();
+}
+
+
+
=item B(inout INT)
=item B(inout NUM)
Index: t/op/arithmetics.t
===
RCS file: /cvs/public/parrot/t/op/arithmetics.t,v
retrieving revision 1.7
diff -u -a -r1.7 arithmetics.t
--- t/op/arithmetics.t 11 Sep 2003 14:48:51 - 1.7
+++ t/op/arithmetics.t 10 Jan 2004 21:59:26 -
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 18;
+use Parrot::Test tests => 20;
use Test::More;
my $fp_equality_macro = <<'ENDOFMACRO';
@@ -281,6 +281,142 @@
0.00
123.456789
123.456789
+OUTPUT
+
+output_is(<<'CODE', <
[perl #24867] [PATCH] more t/src cleanup
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24867]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24867 >
I have rewritten some more of the tests in t/src to use the "proper"
approach to doing resource-juggling. The tests that I haven't touched
don't seem to be reliant on this.
--
Lars Balker RasmussenConsult::Perl
Index: t/src/extend.t
===
RCS file: /cvs/public/parrot/t/src/extend.t,v
retrieving revision 1.13
diff -u -a -r1.13 extend.t
--- t/src/extend.t 13 Dec 2003 15:01:19 - 1.13
+++ t/src/extend.t 10 Jan 2004 21:54:41 -
@@ -337,42 +337,56 @@
c_output_is(<<'CODE', <<'OUTPUT', "call a parrot sub");
-#include
-/* have to cheat because of missing extend interfaces */
-/* #include "parrot/extend.h" */
-#include "parrot/parrot.h"
-#include "parrot/embed.h"
-
-void Parrot_call(Parrot_Interp interpreter, PMC* sub,
- Parrot_Int argcount, ...);
-/* also both the test PASM and main print to stderr
- * so that buffering in PIO isn't and issue
+#include
+#include
+
+static opcode_t *the_test(Parrot_Interp, opcode_t *, opcode_t *);
+
+int main(int argc, char* argv[])
+{
+Parrot_Interp interpreter = Parrot_new(NULL);
+if (!interpreter) {
+return 1;
+}
+Parrot_init(interpreter);
+
+Parrot_run_native(interpreter, the_test);
+
+Parrot_exit(0);
+return 0;
+}
+
+/* also both the test PASM and the_test() print to stderr
+ * so that buffering in PIO is not an issue
*/
-int main(int argc, char* argv[]) {
-Parrot_Interp interpreter;
+static opcode_t*
+the_test(Parrot_Interp interpreter, opcode_t *cur_op, opcode_t *start)
+{
struct PackFile *pf;
PMC *key, *sub, *arg;
-interpreter = Parrot_new(NULL);
pf = Parrot_readbc(interpreter, "temp.pbc");
Parrot_loadbc(interpreter, pf);
key = key_new_cstring(interpreter, "_sub1");
sub = VTABLE_get_pmc_keyed(interpreter,
-interpreter->globals->stash_hash, key);
+ interpreter->globals->stash_hash, key);
Parrot_call(interpreter, sub, 0);
-fprintf(stderr, "back\n");
-fflush(stderr); /* win32 seems to buffer stderr */
+PIO_eprintf(interpreter, "back\n");
+
+/* win32 seems to buffer stderr ? */
+PIO_flush(interpreter, PIO_STDERR(interpreter));
key = key_new_cstring(interpreter, "_sub2");
sub = VTABLE_get_pmc_keyed(interpreter,
-interpreter->globals->stash_hash, key);
+ interpreter->globals->stash_hash, key);
arg = pmc_new(interpreter, enum_class_PerlString);
VTABLE_set_string_native(interpreter, arg,
- string_from_cstring(interpreter, "hello ", 0));
+ string_from_cstring(interpreter, "hello ", 0));
Parrot_call(interpreter, sub, 1, arg);
-fprintf(stderr, "back\n");
-return 0;
+PIO_eprintf(interpreter, "back\n");
+
+return NULL;
}
CODE
in sub1
@@ -396,39 +410,53 @@
c_output_is(<<'CODE', <<'OUTPUT', "call a parrot sub, catch exception");
-#include
-/* have to cheat because of missing extend interfaces */
-/* #include "parrot/extend.h" */
-#include "parrot/parrot.h"
-#include "parrot/embed.h"
-
-void Parrot_call(Parrot_Interp interpreter, PMC* sub,
- Parrot_Int argcount, ...);
-/* also both the test PASM and main print to stderr
- * so that buffering in PIO isn't and issue
+
+#include
+#include
+
+static opcode_t *the_test(Parrot_Interp, opcode_t *, opcode_t *);
+
+int main(int argc, char* argv[])
+{
+Parrot_Interp interpreter = Parrot_new(NULL);
+if (!interpreter) {
+return 1;
+}
+Parrot_init(interpreter);
+
+Parrot_run_native(interpreter, the_test);
+
+Parrot_exit(0);
+return 0;
+}
+
+/* also both the test PASM and the_test() print to stderr
+ * so that buffering in PIO is not an issue
*/
-int main(int argc, char* argv[]) {
-Parrot_Interp interpreter;
+static opcode_t*
+the_test(Parrot_Interp interpreter, opcode_t *cur_op, opcode_t *start)
+{
struct PackFile *pf;
PMC *key, *sub;
Parrot_exception jb;
-interpreter = Parrot_new(NULL);
pf = Parrot_readbc(interpreter, "temp.pbc");
Parrot_loadbc(interpreter, pf);
key = key_new_cstring(interpreter, "_sub1");
sub = VTABLE_get_pmc_keyed(interpreter,
-interpreter->globals->stash_hash, key);
+ interpreter->globals->stash_hash, key);
+
if (setjmp(jb.destination)) {
- fprintf(stderr, "caught\n");
+ PIO_eprintf(interpreter, "caught\n");
}
else {
push_new_c_exception_handler(interpreter, &jb);
Parrot_call(interpreter, sub, 0);
}
-fprintf(stderr, "back\n");
-return 0;
+PIO_eprintf(interpreter, "back\n");
+
+return NULL;
}
CODE
in sub1
Index: t/src/io.t
===
RCS file: /cvs/public/parrot/t/src/io.t,v
retri
Re: nci
On Sat, Jan 10, 2004 at 08:31:21PM +0100, Leopold Toetsch wrote: > Jeff Clites <[EMAIL PROTECTED]> wrote: > > > I assume the plan is to get on-the-fly building of NCI stubs working > > "everywhere". Platforms where that works don't need the functions > > generated by build_nativecall.pl, but right now that's only i386; it's > > a JIT-like and pretty difficult piece of code to write, but it should > > eventually work on every platform which supports JIT, at least. > > It looks like, that we can't get each possible permutation of signatures > built statically. This would also boost executable size beyond any > reasonable limits. > > "I'ts a JIT-like" code but its not too difficult to implement and > indpendent of JIT is implemented. It just needs a bit of knowledge of > the architectures ABI (how functions get their params and return these) > and of course how to implement that. I'm really not an assembly code > hacker, but JITted NIC for i386 was implemented really quickly. I see Dan says in his blog "Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere." I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? Tim.
Re: additional test file for parrotobject.pmc
retry
additional test file for parrotobject.pmc
I have not figured out how to change the mime type of the attached file in mutt. :( -- stef
patch to support nums, strings and pmcs as attributes
--- classes/parrotobject.pmc.orig 2003-12-06 01:00:29.0 +0100
+++ classes/parrotobject.pmc2004-01-10 21:09:08.0 +0100
@@ -87,7 +87,12 @@
}
INTVAL get_integer_keyed (PMC* attr) {
- return SELF.get_integer_keyed_str(key_string(interpreter, attr));
+int flag = PObj_get_FLAGS(attr) & KEY_type_FLAGS;
+if ( flag & KEY_integer_FLAG) {
+ return SELF.get_integer_keyed_int(key_integer(interpreter, attr));
+} else {
+ return SELF.get_integer_keyed_str(key_string(interpreter, attr));
+}
}
void set_integer_keyed_int (INTVAL idx, INTVAL value) {
@@ -107,6 +112,175 @@
}
void set_integer_keyed (PMC* attr, INTVAL value) {
- SELF.set_integer_keyed_str(key_string(interpreter, attr), value);
+int flag = PObj_get_FLAGS(attr) & KEY_type_FLAGS;
+if ( flag & KEY_integer_FLAG) {
+ SELF.set_integer_keyed_int(key_integer(interpreter, attr), value);
+} else {
+ SELF.set_integer_keyed_str(key_string(interpreter, attr), value);
+}
}
+
+
+FLOATVAL get_number_keyed_int (INTVAL idx) {
+ PMC* data_array = (PMC*) PMC_data(SELF);
+ return VTABLE_get_number_keyed_int(interpreter, data_array,
+ idx + SELF->cache.int_val);
+}
+
+FLOATVAL get_number_keyed_str (STRING* attr) {
+ PMC* data_array = (PMC*) PMC_data(SELF);
+ PMC *class = VTABLE_get_pmc_keyed_int(interpreter, data_array,
+ POD_CLASS);
+ INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr);
+ if (idx < 0)
+ internal_exception(1, "No such attribute");
+ return SELF.get_number_keyed_int(idx);
+}
+
+FLOATVAL get_number_keyed (PMC* attr) {
+int flag = PObj_get_FLAGS(attr) & KEY_type_FLAGS;
+if ( flag & KEY_integer_FLAG) {
+ return SELF.get_number_keyed_int(key_integer(interpreter, attr));
+} else {
+ return SELF.get_number_keyed_str(key_string(interpreter, attr));
+}
+
+}
+
+void set_number_keyed_int (INTVAL idx, FLOATVAL value) {
+ PMC* data_array = (PMC*) PMC_data(SELF);
+ VTABLE_set_number_keyed_int(interpreter, data_array,
+ idx + SELF->cache.int_val, value);
+}
+
+void set_number_keyed_str (STRING* attr, FLOATVAL value) {
+ PMC* data_array = (PMC*) PMC_data(SELF);
+ PMC *class = VTABLE_get_pmc_keyed_int(interpreter, data_array,
+ POD_CLASS);
+ INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr);
+ if (idx < 0)
+ internal_exception(1, "No such attribute");
+ SELF.set_number_keyed_int(idx, value);
+}
+
+void set_number_keyed (PMC* attr, FLOATVAL value) {
+int flag = PObj_get_FLAGS(attr) & KEY_type_FLAGS;
+if ( flag & KEY_integer_FLAG) {
+ SELF.set_number_keyed_int(key_integer(interpreter, attr), value);
+} else {
+ SELF.set_number_keyed_str(key_string(interpreter, attr), value);
+}
+
+}
+
+
+
+
+
+
+STRING* get_string_keyed_int (INTVAL idx) {
+ PMC* data_array = (PMC*) PMC_data(SELF);
+ return VTABLE_get_string_keyed_int(interpreter, data_array,
+ idx + SELF->cache.int_val);
+}
+
+STRING* get_string_keyed_str (STRING* attr) {
+ PMC* data_array = (PMC*) PMC_data(SELF);
+ PMC *class = VTABLE_get_pmc_keyed_int(interpreter, data_array,
+ POD_CLASS);
+ INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr);
+ if (idx < 0)
+ internal_exception(1, "No such attribute");
+ return SELF.get_string_keyed_int(idx);
+}
+
+STRING* get_string_keyed (PMC* attr) {
+int flag = PObj_get_FLAGS(attr) & KEY_type_FLAGS;
+if ( flag & KEY_integer_FLAG) {
+ return SELF.get_string_keyed_int(key_integer(interpreter, attr));
+} else {
+ return SELF.get_string_keyed_str(key_string(interpreter, attr));
+}
+}
+
+void set_string_keyed_int (INTVAL idx, STRING* value) {
+ PMC* data_array = (PMC*) PMC_data(SELF);
+ VTABLE_set_string_keyed_int(interpreter, data_array,
+ idx + SELF->cache.int_val, value);
+}
+
+void set_string_keyed_str (STRING* attr, STRING* value) {
+ PMC* data_array = (PMC*) PMC_data(SELF);
+ PMC *class = VTABLE_get_pmc_keyed_int(interpreter, data_array,
+ POD_CLASS);
+ INTVAL idx = VTABLE_get_integer_keyed_str(interpreter, class, attr);
+ if (idx < 0)
+ internal_exception(1, "No such attribute");
+ SELF.set_string_keyed_int(idx, value);
+}
+
+void set_string_keyed (PMC* attr, STRING* value) {
+int flag = PObj_get_FLAGS(attr) & KEY_type_FLAGS;
+if ( flag & KEY_integer_FLAG) {
+ SELF.set_string_keyed_int(key_integer(interpreter, attr), value);
+} else {
+ SELF.set
Re: [PATCH] The Return of the Priority DOD
On Sat, Jan 10, 2004 at 08:39:51PM +0100, Leopold Toetsch wrote: > Nicholas Clark <[EMAIL PROTECTED]> wrote: > > > src/dod.c: In function `clear_live_bits': > > src/dod.c:755: `cur_arena' undeclared (first use in this function) > > > The appended patch cures it (and all tests pass) but I'm not sure if it > > is correct. > > Ah yep, thanks. I didn't test the patch with ARENA_DOD_FLAGS disabled > and finally diceded that "arena" is as meaningful and readable as > "cur_arena" and changed that before submitting - a policy which almost > always causes an error somewhere :) How come most tinderboxes kept going without failing? What's making the choice on the value of ARENA_DOD_FLAGS ? Yes, I think arena makes as much sense as cur_arena, implying that the cur_ is redundant. Nicholas Clark
Re: nci
Jeff Clites <[EMAIL PROTECTED]> wrote: > I assume the plan is to get on-the-fly building of NCI stubs working > "everywhere". Platforms where that works don't need the functions > generated by build_nativecall.pl, but right now that's only i386; it's > a JIT-like and pretty difficult piece of code to write, but it should > eventually work on every platform which supports JIT, at least. It looks like, that we can't get each possible permutation of signatures built statically. This would also boost executable size beyond any reasonable limits. "I'ts a JIT-like" code but its not too difficult to implement and indpendent of JIT is implemented. It just needs a bit of knowledge of the architectures ABI (how functions get their params and return these) and of course how to implement that. I'm really not an assembly code hacker, but JITted NIC for i386 was implemented really quickly. We'll need some architecure around that though that caches known function signatures and avoids rebuilding these stubs. > JEff leo
Re: [PATCH] The Return of the Priority DOD
Nicholas Clark <[EMAIL PROTECTED]> wrote: > src/dod.c: In function `clear_live_bits': > src/dod.c:755: `cur_arena' undeclared (first use in this function) > The appended patch cures it (and all tests pass) but I'm not sure if it > is correct. Ah yep, thanks. I didn't test the patch with ARENA_DOD_FLAGS disabled and finally diceded that "arena" is as meaningful and readable as "cur_arena" and changed that before submitting - a policy which almost always causes an error somewhere :) Thanks, fixed. > Nicholas Clark leo
Re: [PATCH] Fix for remaining PPC JIT failures
On Jan 9, 2004, at 11:05 AM, Robert wrote:
Yeah, I inquired about that ("Patch submission gone missing?" of
1/1/2004), and Robert Spier indicated that it was in the RT
moderation queue. If it doesn't show up in a bit, I'll re-send that
patch submission directly to the list.
It was in the -list- submission queue. I'm pretty sure I saw it show
up.. but since I don't have full archives on my notebook, and I'm
somewhere over Arizona, I can't be of much use right now.
Leo, you can grab it directly from RT too.
I don't think it ever showed up on the mailing list, so I re-sent it
directly there myself, and the patch has been applied, so I think it's
all taken care of now.
Thanks,
JEff
Re: nci
On Jan 10, 2004, at 6:50 AM, Harry Jackson wrote: # New in libpq.so.3.1 t pt p ptit33i i ptit33i i ptiit33i c pi I have jsut added the above signatures to my call_list due to an upgrade to postgres and was wondering what plans are there for managing the call_list. If every time there is a minor update to a lib and several new signatures get added this file is going to get quite large. I assume the plan is to get on-the-fly building of NCI stubs working "everywhere". Platforms where that works don't need the functions generated by build_nativecall.pl, but right now that's only i386; it's a JIT-like and pretty difficult piece of code to write, but it should eventually work on every platform which supports JIT, at least. JEff
Re: [PATCH] Fix for remaining PPC JIT failures
Yeah, I inquired about that ("Patch submission gone missing?" of
1/1/2004), and Robert Spier indicated that it was in the RT moderation
queue. If it doesn't show up in a bit, I'll re-send that patch
submission directly to the list.
It was in the -list- submission queue. I'm pretty sure I saw it show
up.. but since I don't have full archives on my notebook, and I'm
somewhere over Arizona, I can't be of much use right now.
Leo, you can grab it directly from RT too.
-R
Re: [PATCH] The Return of the Priority DOD
On Sat, Jan 10, 2004 at 02:28:38PM +0100, Leopold Toetsch wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch writes:
> >> It seems, that in that case we still need to walk the PMC arenas and
> >> reset all live bits. OTOH when ARENA_DOD_FLAGS is on, this isn't too
> >> expensive because it can be done my masking a full word worth of 8 PMCs
> >> at once. So its still a lot faster then the eager case - hopefully.
> >>
> >> Or am I missing something?
>
> > I don't think you are. I would have thought that GC be the one to reset
> > the live bits, but there was a lot of DOD that I didn't completely
> > understand.
>
> GC is mostly independent of DOD and it doesn't look at PMCs. GC compacts
> variable sized memory pools.
>
> I have applied now your patch with some minor cleanup. Funnily clearing
> the live bits after an aborted lazy DOD run seems not to be necessary.
> Either the test (t/pmc/timer_7) is bogus or I'm still missing something.
I'm seeing compile failures on FreeBSD now:
src/dod.c: In function `clear_live_bits':
src/dod.c:755: `cur_arena' undeclared (first use in this function)
src/dod.c:755: (Each undeclared identifier is reported only once
src/dod.c:755: for each function it appears in.)
src/dod.c
*** Error code 1
The appended patch cures it (and all tests pass) but I'm not sure if it
is correct.
Nicholas Clark
Index: src/dod.c
===
RCS file: /cvs/public/parrot/src/dod.c,v
retrieving revision 1.80
diff -p -u -r1.80 dod.c
--- src/dod.c 10 Jan 2004 13:47:50 - 1.80
+++ src/dod.c 10 Jan 2004 16:05:52 -
@@ -752,7 +752,7 @@ clear_live_bits(Parrot_Interp interprete
}
#else
Buffer *b = arena->start_objects;
-for (i = 0; i < cur_arena->used; i++) {
+for (i = 0; i < arena->used; i++) {
PObj_live_CLEAR(b);
b = (Buffer *)((char *)b + object_size);
}
Re: nci
Harry Jackson wrote: I have tested the patches below now. Could someone have a look at them and see if they can get commited especially the patch to the call_list.txt file. # New in libpq.so.3.1 t pt p ptit33i i ptit33i i ptiit33i c pi I have jsut added the above signatures to my call_list due to an upgrade to postgres and was wondering what plans are there for managing the call_list. If every time there is a minor update to a lib and several new signatures get added this file is going to get quite large. I am sure someone has already thought of this and I have just missed the thread. Harry
Re: [PATCH] The Return of the Priority DOD
Luke Palmer <[EMAIL PROTECTED]> wrote: > Leopold Toetsch writes: >> It seems, that in that case we still need to walk the PMC arenas and >> reset all live bits. OTOH when ARENA_DOD_FLAGS is on, this isn't too >> expensive because it can be done my masking a full word worth of 8 PMCs >> at once. So its still a lot faster then the eager case - hopefully. >> >> Or am I missing something? > I don't think you are. I would have thought that GC be the one to reset > the live bits, but there was a lot of DOD that I didn't completely > understand. GC is mostly independent of DOD and it doesn't look at PMCs. GC compacts variable sized memory pools. I have applied now your patch with some minor cleanup. Funnily clearing the live bits after an aborted lazy DOD run seems not to be necessary. Either the test (t/pmc/timer_7) is bogus or I'm still missing something. > Luke Thanks again for your patch, leo
Re: nci
I have tested the patches below now. Could someone have a look at them
and see if they can get commited especially the patch to the
call_list.txt file.
Harry
Harry Jackson wrote:
Some questions
Please note:
I have been unable to test these patches with "make test" due to the
problems I mentioned in an earler post. I have managed to get the
postgres lib working again and I am hoping this is the only thing I have
affected with these patches although if someone would like to apply and
try them I would appreciate it.
I am getting errors when trying to load the libpq library. I added a few
lines to the /parrot/build_tools/build_nativecall.pl script to see what
was going on when I got the core dump. I have attached a patch to add
these. There may be some problems with it. I was also thinking that it
would be handy to have the facility to print out variables in the
message, what do people think?
I noticed that there are several signatures missing from call_list.txt
so I added these as well. Patch attached. There where quite a few which
probably means I am barking up the wrong tree.
On side note: I was reading the docs on strings and noticed that we
should always be using "STRING" but I have noticed a few references to
"String" while rummaging around. From what I can gather they are one and
the same and "String" is redundant. Is this the case?
On another side note I noticed a reference to "TWEAKS", purely by
chance. For those not in the know
From the summarizer:
TWEAKS
(Takers Wanted -- Effort And Knowledge Sought).
http://xrl.us/o2g
From what I can gather this is a list of tasks compiled by leo that
need to be carried out and help is required. I think it would be a good
idea to have a well kept todo list particularly for tasks that are
fairly easy to complete. I am sure there are people on this list like
myself who do not mind doing the smaller stuff (including documention
;-) in order to get to know the guts. Although some of the stuff leo is
asking for is not that small.
On another side note I noticed the string.pod documentations asks at the
bottom
"Should the following functions be mentioned? string_append,
string_from_cstring, string_from_int, string_from_num, string_index,
string_replace, string_set, string_str_index, string_to_cstring,
string_to_int, string_to_num, string_transcode."
Yes they should, it is things like this that would be good to
put on the TWEAKS along with where or how to start[1]. The
strings doc has been one of the handiest I have found to date.
Harry (on a side note) Jackson
1. If anyone wants to take it on and is unsure where to start. Use the
folowing file.
/parrot/include/parrot/string_funcs.h
file to see what each of the functions do and try some of them and
document what you do in strings.pod and submit your results. I will
probably make some entries on it myself if no one else does.
--- build_nativecall.pl Tue Dec 30 15:54:20 2003
+++ build_nativecall.pl.new Tue Dec 30 15:53:09 2003
@@ -143,7 +143,6 @@
* Notes:
* References:
*/
-
#include "parrot/parrot.h"
#if defined(HAS_JIT) && defined(I386) && defined(threaded_NCI_is_ok)
@@ -207,8 +206,13 @@
to a function that can call it. */
void *
build_call_func(struct Parrot_Interp *interpreter, PMC *pmc_nci,
-String *signature)
+STRING *signature)
{
+
+STRING *ns;
+STRING *message;
+char *c;
+
#if defined(CAN_BUILD_CALL_FRAMES)
/* This would be a good place to put the code that builds the
frames. Undoubtedly painfully platform-dependent */
@@ -221,7 +225,20 @@
UNUSED(pmc_nci);
if (0 == string_length(signature)) return F2DPTR(pcf_v_v);
$icky_global_bit
-PANIC("Unknown signature type");
+
+
+/*
+ These three lines have been added to aid debugging. I want to be able to
+ see which signature has an unknown type. I am sure someone can come up
+ with a neater way to do this.
+ */
+ns = string_make(interpreter, " is an unknown signature type", 30, NULL, 0, NULL);
+message = string_concat(interpreter, signature, ns, 0);
+
+// I think there may be memory issues with this but if we get to here we are
+// aborting.
+c = string_to_cstring(interpreter, message);
+PANIC(c);
return NULL;
#endif
}
--- call_list.txt Tue Dec 30 15:54:20 2003
+++ call_list.txt.new Tue Dec 30 15:53:34 2003
@@ -181,6 +181,18 @@
# Oddball ones for postgres
p ptiLTLLi
+p t
+p ttt
+c p
+t p
+v pp
+t tl4
+t t4
+p pt
+p pi33ipi
+t pii
+p pi
+i pitl
# The following are used by library/pcre.imc
p tiB3P
[perl #24865] Parrot and Gentoo
# New Ticket Created by Adrian Lambeck # Please include the string: [perl #24865] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=24865 > Hi "raptor", I just read a posting of you on the P6i - Mailinglist concerning your ebuild for the .10 release of parrot. Why did you not publish that one on the bug tracking system - would be usefull - just compiled it myself. If you need help with that have a look at http://www.gentoo.org/doc/en/ebuild-submit.xml or mail m back if I can help you. hope to hear from you Adrian Lambeck -- Adrian Lambeck BasicsEdv Lornsenstr.70 25451 Quickborn Telefon: 04106-769388 Mobiltelefon: 0162-9831060
Re: Meaning of "restart" in *.ops files?
Jeff Clites <[EMAIL PROTECTED]> wrote: > What does "restart" mean in op files, as in "restart ADDRESS(resume);"? Restart opcodes set the resume_flag to 1, resume_offset to the next opcode address and then leave the inner run-loop. interpreter.c:runops_int() then restarts a possibly different run-loop on the resume offset again. This is done for changing run loops, e.g. to turn on tracing for some piece of code. > Also, why does the find_global op use it? I couldn't find it explained > anywhere. That's an left over experiment from early tests with throwing exceptions. It isn't necessary anymore. An opcode that may throw a restartable exception has to be a branch op though, so goto ADDRESS(next) would be correct. I'll fix that - thanks for pointing me at that. > Also, on a vaguely related topic, in "Parrot_jit_cpcf_op", what does > "cpcf" stand for? Change Program Control Flow or such. > JEff leo
