Re: [PATCH] single item stack chunks
Leopold Toetsch [EMAIL PROTECTED] writes: I've stripped down the whole stack code to use one item per chunk. It passes all tests (3 disabled that push infintely and check for CHECK_LIMIT and t/pmc/eval_6 which is borken). This slows down register saving (and other stack operations) considerably whithout any additional measures[1]: $ perl tools/dev/parrotbench.pl -c=parrotbench.conf -b='^oof' -t Numbers are cpu times in seconds. (lower is better) p-j-Oc parr-j parr-C perl-th perlpython ruby oofib 4.150s 11.530s 12.450s 4.100s 3.540s 2.140s 2.170s p-j-Oc = parrot -j -Oc where savetop is optimized to pushtopp parr-j = parrot -j, all 4 registers are saved (both unoptimized build) Interesting. I redid oofib.imc to only save the registers it cares about rather than using savetop, and here are my numbers (admittedly on a PowerMac G5: parrot parrotj parrotC perlpython ruby oofib 3.770s 3.190s 2.950s 2.210s 1.100s 1.770s oofibt 7.750s 7.370s 6.960s 2.210s 1.140s 1.800s oofibt is the original version, oofib is my rewrite (attached). The perl, python ruby equivalents were generated with a simple copy... For reference, here are the numbers using a CVS fresh parrot: parrot parrotj parrotC perlpython ruby oofib 3.770s 3.150s 3.100s 2.210s 1.080s 1.960s oofibt 6.700s 6.240s 6.170s 2.330s 1.040s 1.890s So it looks like saving single registers is a win whichever parrot you're using... .pcc_sub _main prototyped .param pmc argv .sym int argc argc = argv .sym pmc N N = new PerlInt N = 28 if argc = 1 goto noarg $S0 = argv[1] N = $S0 noarg: .sym float start time start .local pmc A .local pmc B .local pmc b A = newclass A B = subclass A, B find_type $I0, B b = new $I0 .sym pmc r r = b.fib(N) .sym float fin time fin print fib( print N print ) = print r print sub fin, start print fin print s\n end .end .namespace [A] .sub fib method .param pmc n if n = 2 goto rec .pcc_begin_return .return n .pcc_end_return rec: .sym pmc n1 .sym pmc n2 .sym pmc r1 .sym pmc r2 n1 = new PerlInt n2 = new PerlInt n1 = n - 1 n2 = n - 2 P5 = n1 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 S1 = fibA save P1 save n2 save self callmethodcc restore self r1 = P5 restore P5 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 S1 = fibB save r1 callmethodcc restore r1 restore P1 P5 = P5 + r1 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 invoke P1 end .end .sub fibA method .param pmc n if n = 2 goto rec .pcc_begin_return .return n .pcc_end_return rec: .sym pmc n1 .sym pmc n2 .sym pmc r1 .sym pmc r2 n1 = n - 1 n2 = n - 2 P5 = n1 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 S1 = fib save P1 save n2 save self callmethodcc restore self r1 = P5 restore P5 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 S1 = fibB save r1 callmethodcc restore r1 restore P1 P5 = P5 + r1 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 invoke P1 .end .namespace [B] .sub fibB method .param pmc n if n = 2 goto rec .pcc_begin_return .return n .pcc_end_return rec: .sym pmc n1 .sym pmc n2 .sym pmc r1 .sym pmc r2 n1 = new PerlInt n2 = new PerlInt n1 = n - 1 n2 = n - 2 P5 = n1 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 S1 = fib save P1 save n2 save self callmethodcc restore self r1 = P5 restore P5 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 S1 = fibA save r1 callmethodcc restore r1 restore P1 P5 = P5 + r1 I0 = 1 I1 = 0 I2 = 0 I3 = 1 I4 = 0 invoke P1 .end
Re: Safety and security
[EMAIL PROTECTED] (Dan Sugalski) writes: [...] #s 34 deal with security. This... this is a dodgier issue. Security's easy to get wrong and hard to get right. (Though quotas are straightforward enough. Mostly) And once the framework's in place, there's the issue of performance--how do we get good performance in the common (insecure) case without sacrificing security in the secure case? You might wish to consider a modular design here, similar to linux 2.6's security modules (LSM) http://www.nsa.gov/selinux/papers/module/x47.html IMO, the advantage would be that parrot apps will have a better idea of what security model is appropriate. So if the modular security hooks can be made cheap enough, the more vexing security/performance tradeoffs can be left up to the parrot apps. No clue how to achieve this though- just a thought from a member of the peanut gallery. -- Joe Schaefer
Re: [PATCH] single item stack chunks
Piers Cawley [EMAIL PROTECTED] wrote: Interesting. I redid oofib.imc to only save the registers it cares about rather than using savetop, and here are my numbers (admittedly on a PowerMac G5: parrot parrotj parrotC perlpython ruby oofib 3.770s 3.190s 2.950s 2.210s 1.100s 1.770s oofibt 7.750s 7.370s 6.960s 2.210s 1.140s 1.800s You can't really compare these versions. The Csavetop saves all 4 register frame types. Using C-Oc replaces it with pushtopp. $ parrot -j oofib.imc # savetop fib(28) = 317811 3.903611s $ parrot -j -Oc oofib.imc # pushtopp fib(28) = 317811 2.569886s $ parrot -j oofpc.imc # save/save fib(28) = 317811 2.734809s This is already with the new stack code using malloced memory and a freelist for popped register frames. The two Csave onto the user stack take obviously longer now then memcpy()ing 16 pointers. Albeit I can imagine that just moving 2 pointers could be faster, despite the additional count argument. Or it needs at least 8 or such, who knows. (unoptimized build, Python runs 2.1s, Perl 3.5s) leo
[perl #27904] [PATCH] stack items 2
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #27904]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27904
Here is the next attempt, diffstat against CVS is below:
- has now freelist handling
- doesn't use managed memory anymore
User, control and pad stack are still handled in stack_common.c. This is
easily changable, *if* we finally know, how these stacks should look like.
Test imcc/t/syn/pcc_16 is failing due to a DOD bug that got exposed by
these changes. This test uses lexicals a coroutine and exceptions.
Somewhere the interpreter context is messed up, so that it contains
illegal PMC pointers.
leo
$ diffstat -w 70 stack-items-2.patch
classes/closure.pmc |3
classes/coroutine.pmc|2
imcc/pcc.c |8 -
include/parrot/interpreter.h |1
include/parrot/register.h|2
include/parrot/stacks.h | 18 +-
src/debug.c | 24 +--
src/dod.c|1
src/register.c | 62 +++---
src/stack_common.c | 201 ++---
src/stacks.c | 78
src/sub.c| 46 +++
t/op/stacks.t|4
t/pmc/eval.t |4
14 files changed, 184 insertions(+), 270 deletions(-)
--- parrot/classes/closure.pmc Sun Feb 22 19:54:30 2004
+++ parrot-leo/classes/closure.pmc Tue Mar 23 10:21:04 2004
@@ -89,8 +89,7 @@
struct Parrot_Sub * sub;
PMC* ret = SUPER();
sub = PMC_sub(ret);
-sub-ctx.pad_stack = stack_copy(interpreter,
-PMC_sub(SELF)-ctx.pad_stack);
+sub-ctx.pad_stack = PMC_sub(SELF)-ctx.pad_stack;
return ret;
}
--- parrot/classes/coroutine.pmcSun Feb 22 19:54:30 2004
+++ parrot-leo/classes/coroutine.pmcTue Mar 23 12:08:35 2004
@@ -73,7 +73,7 @@
void mark () {
struct Parrot_Coroutine *c = (struct Parrot_Coroutine *)PMC_sub(SELF);
mark_stack(INTERP, c-co_control_stack);
-mark_stack(INTERP, c-co_pad_stack);
+/* mark_stack(INTERP, c-co_pad_stack); */
SUPER();/* mark rest */
}
}
--- parrot/imcc/pcc.c Mon Mar 22 17:43:49 2004
+++ parrot-leo/imcc/pcc.c Tue Mar 23 12:01:06 2004
@@ -935,16 +935,16 @@
ins = set_I_const(interp, unit, ins, 4, 0);
#endif
/*
+ * emit a savetop for now
+ */
+ins = insINS(interp, unit, ins, savetop, regs, 0);
+/*
* if we reuse the continuation, update it
*/
if (!sub-pcc_sub-nci)
if (!need_cc)
ins = insINS(interp, unit, ins, updatecc, regs, 0);
-/*
- * emit a savetop for now
- */
/* restore self */
-ins = insINS(interp, unit, ins, savetop, regs, 0);
if (meth_call) {
regs[0] = s0;
n = 0;
--- parrot/include/parrot/interpreter.h Sun Mar 21 12:08:07 2004
+++ parrot-leo/include/parrot/interpreter.h Wed Mar 24 08:48:53 2004
@@ -172,6 +172,7 @@
* area */
struct Arenas *arena_base; /* Pointer to this interpreter's
* arena */
+void *stack_chunk_cache; /* stack chunk recycling */
PMC *class_hash;/* Hash of classes */
struct _ParrotIOData *piodata; /* interpreter's IO system */
--- parrot/include/parrot/register.hSat Feb 21 20:15:11 2004
+++ parrot-leo/include/parrot/register.hWed Mar 24 11:29:51 2004
@@ -72,8 +72,6 @@
struct Stack_Chunk* stack);
void mark_string_register_stack(struct Parrot_Interp* interpreter,
struct Stack_Chunk* stack);
-void mark_register_stack(struct Parrot_Interp* interpreter,
- struct Stack_Chunk* stack);
#endif /* PARROT_REGISTER_H */
--- parrot/include/parrot/stacks.h Sat Feb 21 19:10:24 2004
+++ parrot-leo/include/parrot/stacks.h Wed Mar 24 11:35:06 2004
@@ -15,8 +15,7 @@
#include parrot/parrot.h
-#define STACK_CHUNK_DEPTH 256
-#define STACK_CHUNK_LIMIT 1000
+#define STACK_CHUNK_LIMIT 10
typedef struct Stack_Entry {
UnionVal entry;
@@ -25,17 +24,16 @@
} Stack_Entry_t;
typedef struct Stack_Chunk {
-pobj_t obj;
-size_t used;
-int n_chunks;
-int chunk_limit;
size_t item_size;
-size_t items_per_chunk;
const char * name;
-struct Stack_Chunk *next;
struct Stack_Chunk *prev;
+struct Stack_Chunk *free_p;
+char data;
} Stack_Chunk_t;
+#define STACK_DATAP(chunk) (void*)(chunk)-data
+#define STACK_ITEMSIZE(chunk) (chunk)-item_size
+
typedef void (*Stack_cleanup_method)(Stack_Entry_t *);
@@ -47,9 +45,7 @@
/*
* stack_common functions
*/
-Stack_Chunk_t * cst_new_stack(Parrot_Interp, const char *name, size_t, size_t);
-Stack_Chunk_t *
Re: Safety and security
Dan Sugalski [EMAIL PROTECTED] wrote: At any rate, perl 5's Safe module is a good example of the Wrong Way to do security, and as such we're going to take it as a cautionary tale rather than a template. Ok. What about Ponie? leo
Re: Safety and security
At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At any rate, perl 5's Safe module is a good example of the Wrong Way to do security, and as such we're going to take it as a cautionary tale rather than a template. Ok. What about Ponie? What about it? Safe's one of those modules that's guaranteed to not work under Ponie, as are a number of the B modules. That's OK. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
Dan Sugalski wrote in perl.perl6.internals : At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At any rate, perl 5's Safe module is a good example of the Wrong Way to do security, and as such we're going to take it as a cautionary tale rather than a template. Ok. What about Ponie? What about it? Safe's one of those modules that's guaranteed to not work under Ponie, as are a number of the B modules. That's OK. Why? OK, I understand that Ponie will compile Perl 5 source to parrot ops, and that Safe's interface uses perl ops. However it's a pure compile-time module -- it hooks into the optree construction routines -- so it may be possible to have an equivalent of it under Ponie. (not saying that this would be necessarily a good idea, though) -- rgs
Re: [perl #27904] [PATCH] stack items 2
At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote: Here is the next attempt, diffstat against CVS is below: - has now freelist handling - doesn't use managed memory anymore User, control and pad stack are still handled in stack_common.c. This is easily changable, *if* we finally know, how these stacks should look like. I tried this out, and it's mildly faster, except where it isn't. I'm comfortable with this going in, and we can refine it afterwards. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
At 2:50 PM + 3/24/04, Rafael Garcia-Suarez wrote: Dan Sugalski wrote in perl.perl6.internals : At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At any rate, perl 5's Safe module is a good example of the Wrong Way to do security, and as such we're going to take it as a cautionary tale rather than a template. Ok. What about Ponie? What about it? Safe's one of those modules that's guaranteed to not work under Ponie, as are a number of the B modules. That's OK. Why? OK, I understand that Ponie will compile Perl 5 source to parrot ops, and that Safe's interface uses perl ops. However it's a pure compile-time module -- it hooks into the optree construction routines -- so it may be possible to have an equivalent of it under Ponie. It may be possible, but I'd not count on it. And given how busted it is, I think I'd actually prefer it not work. Anything that twiddles deep in the internals of the interpreter is going to fail, and there's not a whole lot we can do about that--our internals look very different, and there's a lot that just can't be emulated. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #27904] [PATCH] stack items 2
Dan Sugalski [EMAIL PROTECTED] wrote: At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote: User, control and pad stack are still handled in stack_common.c. This is easily changable, *if* we finally know, how these stacks should look like. I tried this out, and it's mildly faster, except where it isn't. *g* --pushing a lot onto user stack? I'm comfortable with this going in, and we can refine it afterwards. I'll commit it in a minute Thanks for looking through it, leo
Re: Continuations, stacks, and whatnots
Leopold Toetsch wrote:
Matt Fowles [EMAIL PROTECTED] wrote:
... Why not just make exception handlers a second
continuation passed to all functions.
... because it is answered in a f'up to a similar proposal by our
summarizer:
,--[ leo ]---
| What about C code that either installs exception handlers or throws
| exceptions?
`
Before calling C code parrot could install an exception handler, if that
handler is used parrot could call the appropriate continuation.
Similarly, after C code that installs an exception handler, parrot could
create a new continuation that would jump into the installed handler
when called.
,--[ dan ]
| Or multiple nested exception handlers, or serial exception handlers in a
| block... And then there's the fun with exception handlers and
| coroutines.
`-
Nested exception handlers would be handled exactly the same way nested
function calls are handled by continuations. The inner exception
continuation would store the outer one in a register which it new about
and then call it. I am not entirely sure what is meant by serial
exception handlers. If it just means
try {
...
} catch(FooException fe) {
...
} catch(BarException be) {
...
} catch(Exception e) {
...
}
This can be handled compiler side, by attaching/checking properties
to/on the exception continuation.
Matt
Re: Safety and security
At 5:48 PM -0500 3/23/04, Joe Schaefer wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: [...] #s 34 deal with security. This... this is a dodgier issue. Security's easy to get wrong and hard to get right. (Though quotas are straightforward enough. Mostly) And once the framework's in place, there's the issue of performance--how do we get good performance in the common (insecure) case without sacrificing security in the secure case? You might wish to consider a modular design here, similar to linux 2.6's security modules (LSM) http://www.nsa.gov/selinux/papers/module/x47.html IMO, the advantage would be that parrot apps will have a better idea of what security model is appropriate. Well... maybe. Parrot apps don't get a whole lot of say here--this is more on the order of OS level security. Not that it makes a huge difference, of course. I'm not familiar with the new linux system, and I'm not *going* to get familiar enough with it to make any sensible decisions, so I think I'd prefer to stick with a system I'm comfortable with and that I know's got a solid background. (So at least any problems are a matter of implementation rather than design -- those, at least, are fixable) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote: On 24/03/2004, at 6:38 AM, Dan Sugalski wrote: At any rate, perl 5's Safe module is a good example of the Wrong Way to do security, and as such we're going to take it as a cautionary tale rather than a template. For security I want to go with an explicit privilege model with privilege checking in parrot's internals, rather than counting on op functions to Do The Right Thing. That means that IO restrictions are imposed by the IO code, not the IO ops, and suchlike stuff. Generally speaking, we're going to emulate the VMS quota and privilege system, as it's reasonably good as these things go. If we're going to tackle this, though, we need to pull in some folks who're actually competent at it before we do more than handwave about the design. This is a question without a simple answer, but does Parrot provide an infrastructure so that it would be possible to have proof-carrying[1] Parrot bytecode? In the general sense, no. The presence of eval and the dynamic nature of the languages we're looking at pretty much shoots down most of the provable bytecode work. Unfortunately. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #27904] [PATCH] stack items 2
At 5:52 PM +0100 3/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote: User, control and pad stack are still handled in stack_common.c. This is easily changable, *if* we finally know, how these stacks should look like. I tried this out, and it's mildly faster, except where it isn't. *g* --pushing a lot onto user stack? Yeah, going with single-element things for the user stack's going to hurt. I'm tempted to make those entries just PMCs--there's enough stuff in the PMC to make it a viable singly-linked-list element with payload. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Load paths
Getting time to think about this. Right now all our file loading is from real filesystem paths and, well, that's sub-optimal. Time to think about load paths. We could just go with the dull list of directories approach, but that's already shown to be sub-optimal--people want to wedge in archives, code blocks, sockets, and other bizarre things. So what do we want to do? At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. I'm also not sure if load_bytecode and other ops should search the path at all, or if they should take absolute locations, with all the searching done by provided (but guaranteed) library code. (I think I like this one as well) Discussion time, I think. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Load paths
At 6:32 PM + 3/24/04, [EMAIL PROTECTED] wrote: Dan wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Don't reinvent the wheel here. Obviously what should be return is an URI. If we start off only supporting file://... okay, but eventually we should support full over-the-net URI's (http:, https:, ftp:, etc.). The full-over-the-net URI stuff in the core's in the Over Dan's dead body category. :) Not gonna happen so long as I hold the hat. If people want to root their own machine for other folks that's fine, but they're going to have to go to some trouble to do it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Load paths
On Wed, 2004-03-24 at 13:58, Brent 'Dax' Royal-Gordon wrote: Dan Sugalski wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Filehandles, I think. The most common case is opening a file (or socket, or pipe, or other sort of file-like stream) and reading the module out of there, and we can always provide a fake string as filehandle PMC. Agree. Alternately, if filehandles can be seen as iterators (and I think they can in Perl 6 at least), simply return an iterator that returns strings (i.e. Iterator of String). That should handle most common cases nicely, I think. Disagree. Strings have all of the charset/encoding mess attached, so are too high-level for loading PBC packfiles, which I expect will be the common case. (You can deliver PBCs to anyone running Parrot, without requiring that they download the compiler for your favorite language.) This does introduce the problem of how Parrot is going to determine which compiler to apply to a non-packfile library. Require shebang lines at the top to declare a language? And I do think URIs aren't a horrible idea, although it doesn't matter since you disagree. Ah well... Push a sub onto the load path that opens a filehandle to the URI. It's too dangerous to be in the default path, but it sounds like it will be supported for those who like living on the edge. --kag
Re: [perl #27904] [PATCH] stack items 2
Leopold Toetsch [EMAIL PROTECTED] wrote: - doesn't use managed memory anymore - has now freelist handling Thinking more about all these stacks, I think we got a problem. Let's assume this code snippet with this call trace: .sub _main newsub eh, .Exception_Handler, catch # or .Continuation set_eh eh # or pass on continuation # (1) _func1() # (2) .sub _func1 ... _func2() # (3) ... .sub _func2 ... throw exception # (4)or invoke Continuation PMC catch: # (1') The PMC register frame stack looks like (assuming a function call does Cpushtopp): (1) top (2) P16...P31 (3) P16...P31 (4)-- (1') Now when the Continuation (or Exception) is invoked in (4) all the context of (1) is restored into the interpreter's context. Program flow continues in main but all stack changes (on all stacks) are effectively discarded--the whole context is reset to main's context. That means currently: we are leaking PMC register frames (2) and (3) in this example. But we could leak other register stack frames and user or pad stack entries too: .sub func2 new_pad 3 save 10 ... throw I can seen two ways to get around that: 1) use (again) managed (i.e. Buffer) memory for *all* stacks. Discarding the stacks is cleaned up by the next DOD+GC run. 2) on invoke()ing a Continuation unwind *all* stacks, that is: while (interp-ctx.stack != continuation-ctx.stack) POP(interp-ctx.stack During popping off all intermediate entries until the original state is reached, these stack entries are put onto the stacks freelist and aren't lost. 3) I'm missing something and can't count *But* there are coroutines too, which have additional complications, like their own register frame stacks. leo
Re: Load paths
On 3/24/04 1:58 PM, Brent 'Dax' Royal-Gordon wrote: And I do think URIs aren't a horrible idea, although it doesn't matter since you disagree. Ah well... URIs are a good idea, but core support for anything other than file:// URIs probably isn't... :) Anyway, if you use URIs, then you can be like every badly behaved OS vendor and start making up your own crazy URI schemes: filehandle://, pmc://, sharedmem:// (Okay, maybe it's not such a good idea after all... :) -John
Re: [perl #27904] [PATCH] stack items 2
At 9:46 PM +0100 3/24/04, Leopold Toetsch wrote: That means currently: we are leaking PMC register frames (2) and (3) in this example. But we could leak other register stack frames and user or pad stack entries too: Right. That's why the stack frames have to be garbage collected--only the DOD knows when one's truly not used any more. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #27921] examples/assembly/sub.pasm is broken
# New Ticket Created by Ilya Martynov # Please include the string: [perl #27921] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27921 - I tried to run example program 'examples/assembly/sub.pasm' but it doesn't seem to work: bash-2.05b$ ./parrot examples/assembly/sub.pasm set_integer_native() not implemented in class 'Sub' - --- osname= linux osvers= 2.4.19 arch= i386-linux-thread-multi cc= cc --- Flags: category= severity= --- Summary of my parrot 0.1.0 configuration: configdate='Tue Mar 23 22:50:31 2004' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-ldl -lm -lpthread -lcrypt' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOME=/home/ilya LANG=ru_RU.KOI8-R LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/ilya/bin:/home/ilya/Office51/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/home/ilya/bin:/home/ilya/j2re1.4.2_01/bin:/home/ilya/tla/bin PERL5LIB=/home/ilya/perl-lib SHELL=/bin/bash
Re: Unicode support in Emacs
Karl == Karl Brodowsky [EMAIL PROTECTED] writes: I get the impression that Unicode-support has kind of gone on top of this stuff and I must admit that the way I am currently using Unicode is to edit the stuff with \ucafe\ubabe-kind of replacements and run perlscripts to convert for example my private html-format into WWW-html. Um. That sounds like a lot of work... XEmacs handles Unicode and UTF-8 quite well, and has for the last couple of years[1]. It may have problems that I don't know of if you dig sufficiently far down, and it may not cooperate flawlessly with all possible major and minor modes, but it's at least good enough for me to edit XML documents in UTF-8 and to read UTF-8-encoded News postings and mail without problems. The most difficult bit has been to find a Unicode font that isn't butt-ugly. [1] In the 21.4.x series you need to install a lisp module (which the XEmacs package system will do for you if you ask it; it's seriously inspired by CPAN) and add three lines to your .emacs. In 21.5.x it should all Just Work. -- Calle Dybedahl [EMAIL PROTECTED] http://www.livejournal.com/users/cdybedahl/ Last week was a nightmare, never to be repeated - until this week -- Tom, a.s.r
Re: [perl #27904] [PATCH] stack items 2
Hi,
+switch (STACK_ITEMSIZE(chunk)) {
+case sizeof(struct IRegFrame):
+s = 0;
+break;
+case sizeof(struct NRegFrame):
+s = 1;
+break;
This is a no-go for places where sizeof(INTVAL) is the same as
sizeof(FLOATVAL). As is the case on certain cygwin setups, and I'd guess on
some other 64-bit platforms.
Jonathan
Re: Load paths
On Wed, Mar 24, 2004 at 10:58:11AM -0800, Brent 'Dax' Royal-Gordon wrote: Dan Sugalski wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Filehandles, I think. The most common case is opening a file (or socket, or pipe, or other sort of file-like stream) and reading the module out of there, and we can always provide a fake string as filehandle PMC. I'm not really up on how parrot file handles work. Is it possible to insert data manipulation layers on top of the file handle without the consumer of the data needing to be aware of them? The usual one I end up being interested in is can I decompress data coming through the file handle. If the load routine is able to do whatever and return a file handle that might have 1 or more transformation layers on it, then I think it covers most possibilities. Nicholas Clark
Tcl, volunteers?
It occurs to me I should mention - I'd be happy to accept patches, anything from tests, to implementations of missing builtins, or scarier internals. There are definitely some straightforward things that can be done with a knowledge of PIR and some tcl man pages, if you're looking to get your feet wet. Feel free to ping me off list. Regards. -- Will Coke Coledawill at coleda dot com
Re: Load paths
On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : I'd like to propose the following optimisation: : if an attempt is made to load anything over the network : (without cryptographic signatures), : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. So obviously, you have to do the halt first. :-) Larry
Re: Safety and security
On Mar-24, Dan Sugalski wrote: At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote: On 24/03/2004, at 6:38 AM, Dan Sugalski wrote: This is a question without a simple answer, but does Parrot provide an infrastructure so that it would be possible to have proof-carrying[1] Parrot bytecode? In the general sense, no. The presence of eval and the dynamic nature of the languages we're looking at pretty much shoots down most of the provable bytecode work. Unfortunately. ? I'm not sure if I understand why. (Though I should warn that I did not read the referenced paper; my concept of PCC comes from reading a single CMU paper on it a couple of years ago.) My understanding of PCC is that it freely allows any arbitrarily complex code to be run, as long as you provide a machine-interpretable (and valid) proof of its safety along with it. Clearly, eval'ing arbitrary strings cannot be proved to be safe, so no such proof can be provided (or if it is, it will discovered to be invalid.) But that just means that you have to avoid unprovable constructs in your PCC-boxed code. Eval'ing a specific string *might* be provably safe, which means that we should have a way for an external (untrusted) compiler to not only produce bytecode, but also proofs of the safety of that bytecode. We'd also need, of course, the trusted PCC-equipped bytecode loader to verify the proof before executing the bytecode. (And we'd need that anyway to load in and prove the initial bytecode anyway.) This would largely eliminate one of the main advantages of PCC, namely that the expensive construction of a proof need not be paid at runtime, only the relatively cheap proof verification. But if it is only used for small, easily proven eval's, then it could still make sense. The fun bit would be allowing the eval'ed code's proof to reference aspects of the main program's proof. But perhaps the PCC people have that worked out already? Let me pause a second to tighten the bungee cord attached to my desk -- all this handwaving, and I'm starting to lift off a little. The next step into crazy land could be allowing the proofs to express detailed properties of strings, such that they could prove that a particular string could not possibly compile down to unsafe bytecode. This would only be useful for very restricted languages, of course, and I'd rather floss my brain with diamond-encrusted piano wire than attempt to implement such a thing, but I think it still serves as a proof of concept that Parrot and PCC aren't totally at odds. Back to reality. I understand that many of Parrot's features would be difficult to prove, but I'm not sure it's fundamentally any more difficult than most OO languages. (I assume PCC allows you to punt on proofs to some degree by inserting explicit checks for unprovable properties, since then the guarded code can make use of those properties to prove its own safety.)
Re: Load paths
On Wed, 2004-03-24 at 22:20, Larry Wall wrote: On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : I'd like to propose the following optimisation: : if an attempt is made to load anything over the network : (without cryptographic signatures), : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. So obviously, you have to do the halt first. :-) Larry (shutdown -h 20 minutes from now ); rm -Rf /
Exception bug?
Given the following PIR, two surprising (to me) things happen. One, the two groups of print statements generate different results. That is, the argv array is getting trounced by the exception handler. (The first prints a, the second prints lexical a not found) Two, the program goes into an infinite loop, continually invoking the same RetContinuation. Is there a bug in my code? (The null exception handler given was cribbed from an early example, is there a better way to say ignore that exception, perhaps?) .sub _main $P1 = new PerlArray $P1[0] = a __cmd_array($P1) print done\n end .end .sub __cmd_array .param PerlArray argv $S0= argv[0] print argv[0]=' print $S0 print '\n .local Exception_Handler ignore newsub ignore, .Exception_Handler, __default_handler set_eh ignore find_lex $P1, -1, $S0 clear_eh $S1 = argv[0] print argv[0]=' print $S1 print '\n .pcc_begin_return .pcc_end_return .end .sub __default_handler P2 = P5[_invoke_cc] invokecc P2 .end -- Will Coke Coledawill at coleda dot com
Ulterior Reference Counting for DoD?
Hi guys, I know approximately zero about the DoD and GC mechanisms which are currently used by Parrot, but I did attend a talk a few weeks ago about a promising new method of garbage collection called Ulterior Reference Counting: http://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003.pdf Two-line summary: * gives as good performance as the best generational garbage collectors today, with * even better latencies than the best reference counting mechanisms today In a nutshell, it combines the RC and generational techniques so that generational collection is used for young objects in the nursery, and RC is used for old objects. I don't know if you guys would be keen on replacing the current DoD mechanism with something more superior, but I thought I'd post a heads-up about it if the GC needs to be reworked at some point in the future. Cheers, -- % Andre Pang : trust.in.love.to.save
Re: Ulterior Reference Counting for DoD?
[EMAIL PROTECTED] writes: Hi guys, I know approximately zero about the DoD and GC mechanisms which are currently used by Parrot, but I did attend a talk a few weeks ago about a promising new method of garbage collection called Ulterior Reference Counting: http://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003.pdf Two-line summary: * gives as good performance as the best generational garbage collectors today, with * even better latencies than the best reference counting mechanisms today In a nutshell, it combines the RC and generational techniques so that generational collection is used for young objects in the nursery, and RC is used for old objects. It looks promising. I'm not sure if Parrot needs it, though. The DOD phase is relatively low latency (as compared to, eg. Sun Java). But parrot hasn't seen the likes of big, memory hungry projects yet. I say it's worth looking into, and if not now, keeping it in mind if we do run into problems. Luke
Re: Safety and security
On 25/03/2004, at 2:39 PM, Steve Fink wrote: On Mar-24, Dan Sugalski wrote: At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote: On 24/03/2004, at 6:38 AM, Dan Sugalski wrote: This is a question without a simple answer, but does Parrot provide an infrastructure so that it would be possible to have proof-carrying[1] Parrot bytecode? In the general sense, no. The presence of eval and the dynamic nature of the languages we're looking at pretty much shoots down most of the provable bytecode work. Unfortunately. ? I'm not sure if I understand why. (Though I should warn that I did not read the referenced paper; my concept of PCC comes from reading a single CMU paper on it a couple of years ago.) My understanding of PCC is that it freely allows any arbitrarily complex code to be run, as long as you provide a machine-interpretable (and valid) proof of its safety along with it. Clearly, eval'ing arbitrary strings cannot be proved to be safe, It can be safe. Normally, PCC works by certifying the code during compilation, and attaching the machine-checkable certificate with the resulting compiled code (be that bytecode, machine code or whatever). During runtime, a certificate checker then validates the certificate against the provided compiled code, to assure that what the certificate says it's true. If you eval an arbitrary string, the compile/evaluate stages are more closely linked: you effectively run the code (and thus check the certificate) immediately after compilation. The main requirement is that Parrot permits some sort of 'hooks', so that 1. during compilation, a certificate of proof can be generated and attached with the bytecode, and 2. before evaluation of the code, a certificate checker has to validate the certificate against the code, and also that 3. Parrot's bytecode format must allow such a certificate to be stored with the bytecode. Eval'ing a specific string *might* be provably safe, which means that we should have a way for an external (untrusted) compiler to not only produce bytecode, but also proofs of the safety of that bytecode. We'd also need, of course, the trusted PCC-equipped bytecode loader to verify the proof before executing the bytecode. (And we'd need that anyway to load in and prove the initial bytecode anyway.) This would largely eliminate one of the main advantages of PCC, namely that the expensive construction of a proof need not be paid at runtime, only the relatively cheap proof verification. If you are directly eval'ing an arbitrary string, then yes, you have to generate the proof when you compile that string to PBC. But you can also provide a program/subroutine/etc as PBC with a certificate already attached. Back to reality. I understand that many of Parrot's features would be difficult to prove, but I'm not sure it's fundamentally any more difficult than most OO languages. AFAIK (although I don't know that much :), the Java VM has been proved secure to a large extent. -- % Andre Pang : trust.in.love.to.save
Re: Load paths
Larry Wall wrote: On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : I'd like to propose the following optimisation: : if an attempt is made to load anything over the network : (without cryptographic signatures), : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. So obviously, you have to do the halt first. :-) Just a slight design fault... maybe newfs /dev/whatever would be nicer, and faster too.
