Re: Butt-ugliness reduction
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 19, 2001 at 03:29:00PM +, Dave Mitchell wrote:
> > I'd prefer the "you have 8 private bits, the rest is Parrot's" approach
> > rather than the "Parrot has 8 bits and the rest is yours for now, we'll
> > let you know when we want to grab some more back off you" approach. I think
> > that way, we'll have less backwards compatibility issues for 3rd party code.
>
> You are right, of course. Thankfully, you're right sufficiently early
> that all you need to send me a patch for is the documentation and
> include/parrot/pmc.h :)
My bluff has been called!
Okay, here's a stab at it. I'm keen that we use enums to define constants,
rather than using #define.
--- ./docs/vtables.pod Mon Nov 19 23:44:15 2001
+++ ./docs/vtables.pod Tue Nov 20 00:29:34 2001
@@ -100,17 +100,23 @@
is to define a structure that will hook onto the C, if your data
type needs to use that, and then also define some user-defined flags.
-Flags are accessed by C<< pmc->flags >>, but a number of these flags
-are reserved by Parrot internally. Hence, you should start your
-user-defined flags from offset C, like this:
+Flags are accessed by C<< pmc->flags >>. Most of the bits in the flag word
+are reserved for use by parrot itself, but a number of them have been
+assigned for general use by individual classes. These are referred to as
+C .. C. (The '7' may change during the
+early development of parrot, but will become pretty fixed at some point.)
-#define FOOBYNUMBER_IS_BIGNUM (1<<(PMC_USER_FLAG))
-#define FOOBYNUMBER_IS_BIGINT (1<<(PMC_USER_FLAG+1))
-...
+Normally, you will want to alias these generic bit names to something
+more meaningful within your class:
-You're quite at liberty to make these two definitions in a separate
-header file, but I find it more convenient to keep everything together
-in F.
+enum {
+ Foobynumber_is_bignum = PMC_private0_FLAG,
+ Foobynumber_is_bigint = PMC_private1_FLAG,
+
+};
+
+You're quite at liberty to declare these in a separate header file, but I
+find it more convenient to keep everything together in F.
You may also use the C union in the PMC structure to remove
some extraneous dereferences in your code if that would help.
--- ./include/parrot/pmc.h Mon Nov 19 23:44:15 2001
+++ ./include/parrot/pmc.h Tue Nov 20 00:29:37 2001
@@ -33,7 +33,29 @@
SYNC *synchronize;
};
-#define PMC_USER_FLAG 9 /* Unreserved flags start here */
+/* PMC flag bits */
+
+typedef enum {
+/* the first 8 bits are for private use by individual vtable
+ * classes. It is suggested that you alias these within an individual
+ * class's header file
+ */
+PMC_private0_FLAG = 2 << 0,
+PMC_private1_FLAG = 2 << 1,
+PMC_private2_FLAG = 2 << 2,
+PMC_private3_FLAG = 2 << 3,
+PMC_private4_FLAG = 2 << 4,
+PMC_private5_FLAG = 2 << 5,
+PMC_private6_FLAG = 2 << 6,
+PMC_private7_FLAG = 2 << 7,
+
+/* The rest of the flags are for use by Parrot */
+
+PMC_tba_FLAG= 2 << 8, /* XXX none yet, just an example... */
+} PMC_flags;
+
+/* XXX add various bit test macros once we have need of them */
+
#endif
Re: Butt-ugliness reduction
On Tue, Nov 20, 2001 at 03:56:15PM +, Dave Mitchell wrote: > My bluff has been called! > Okay, here's a stab at it. I'm keen that we use enums to define constants, > rather than using #define. Nice work. Thanks, applied. -- teco < /dev/audio - Ignatios Souvatzis
Psyco - Python specializing compiler
Hi, I have found a reference for a very interesting project related to accelerating Python with some nice ideas, that maybe could be applied to Parrot too. It's called Psyco (standing for Python Specializing Compiler) and works (if I understood it right) by creating specialized versions of python functions which optimize a particular type of parameters. The specialization can happen both at compile-time, run-time, or (most of times) will start at compile-time, stop until some run-time value is known, compile a bit more, and so on. It is a quite general trick, and could be used to implement some of the optimizing strategies that have been discussed here (like PMC opcodes inlining, constant folding, etc..) without requiring Parrot to know on advance things that it simply cannot know. They have some problems that are very similar to the ones discussed in this mailing list in a previous thread (users can redefine bultins, globals can get rebound somewhere in the wild, etc..); they have not addressed this yet, but suggest having a signal system on the globals lexical hash that fires a backtrack when anyone is playing dangerous games with it). The URL is http://homepages.ulb.ac.be/~arigo/psyco/ ; they have some very nice documents that explain all with a great detail. I wonder whether Parrot could stole some ideas of this.. Just mi half a cent. -Angel Faus [EMAIL PROTECTED]
Re: sizeof(INTVAL), sizeof(void*), sizeof(opcode_t)
James Mastros wrote: > In byteswapping the bytecode ... > > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed > to be able to hold a void*. It sounds like you want portable byte code. Is that a goal? It seems like we can have either mmap'able byte code or portable byte code, but not both. Personally, I'd rather have portable byte code because memory is cheap and self-modifiying byte code opens up a lot of optimization potential. I know others disagree. Are we looking at two different byte code formats? Dan? - Ken
Re: sizeof(INTVAL), sizeof(void*), sizeof(opcode_t)
On Tue, 2001-11-20 at 12:19, Ken Fox wrote: > James Mastros wrote: > > In byteswapping the bytecode ... > > > > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed > > to be able to hold a void*. > > It sounds like you want portable byte code. Is that a goal? It seems like > we can have either mmap'able byte code or portable byte code, but not both. > Personally, I'd rather have portable byte code because memory is cheap > and self-modifiying byte code opens up a lot of optimization potential. I > know others disagree. Hmm. It wouldn't necessarily be portable, though it probably would be on machines with the same size & endianness. So, on an alpha, you'd have: sizeof(INTVAL)=sizeof(opcode_t)=sizeof(void *)=64 bits whereas on x86 (and other 32 bit machines) sizeof(INTVAL)=sizeof(opcode_t)=sizeof(void *)=32 bits and on the Parrot/C-64 VM you'd have sizeof(INTVAL)=sizeof(opcode_t)=sizeof(void *)=16 bits Is that right? Brian > > Are we looking at two different byte code formats? Dan? > > - Ken
Re: sizeof(INTVAL), sizeof(void*), sizeof(opcode_t)
On Tue, 20 Nov 2001, Ken Fox wrote: > It sounds like you want portable byte code. Is that a goal? I do indeed want portable packfiles, and I thought that was more then a "goal", I thought that was a "requirement". In an ideal world, I want a PVM to be intergrated in a webbrowser the same way a JVM is now. > It seems like > we can have either mmap'able byte code or portable byte code, but not both. > Personally, I'd rather have portable byte code because memory is cheap > and self-modifiying byte code opens up a lot of optimization potential. I > know others disagree. I think we can get the best of both worlds. We, I think, should be able to get the bytecode format such that it is mmapable on platforms with the same endiannes and sizeof(INTVAL), and nonmmapable otherwise. -=- James Mastros -- Put bin Laden out like a bad cigar: http://www.fieler.com/terror "You know what happens when you bomb Afghanastan? Thats right, you knock over the rubble." -=- SLM
RE: sizeof(INTVAL), sizeof(void*), sizeof(opcode_t)
> On Tue, 20 Nov 2001, Ken Fox wrote: > > It sounds like you want portable byte code. Is that a goal? > I do indeed want portable packfiles, and I thought that was more then a > "goal", I thought that was a "requirement". In an ideal world, I want a > PVM to be intergrated in a webbrowser the same way a JVM is now. I think we should separate packfile from runtime image file. If we want the runtime can run a mmapped (pack)file, the file can not be portable. We have to deal with endianness, alignment, floating point format etc. > I think we can get the best of both worlds. We, I think, should be able > to get the bytecode format such that it is mmapable on platforms with the > same endiannes and sizeof(INTVAL), and nonmmapable otherwise. There is not much problem on the bytecode side. As we discussed before, the bytecode is a stream of (aligned) 32-bit values. Most platforms can handle 32-bit value efficiently. Other platforms can do simple conversion. I think what you really need to worry about is the file format, such as constant area, linkage table, etc. There is no need to make sizeof(opcode) == sizeof(INTVAL), since constant area can hold anything you need. All you need to do is one more indirection. Hong
ruby perl performance
Hi, as Michael G Schwern showed me I posted a wrong information about ruby in this list, after testing I found that ruby and perl performance are roughly equivalent in very simple tests such as a fibonacci's series computation. My misconception came from an older benchmark I did and it did not involve ruby but python which was slower than perl. So I'd say that ruby's problem are no CPAN and bad windows support and both can hopefully be corrected if it can adopt parrot, therefore the conclusion stays the same. once more sorry for the disinformation and thanks to Michael for pointing to me that ruby is even better than I thought. Long live parrot Benoit
[PATCH] Makefile cleans out .pasm, .pbc, .out files from t/op directory
Presence of old .pasm &c files can cause tests to fail because they blindly attempt to write to string17.pasm or whatever. -Jeff <[EMAIL PROTECTED]>
