Re: Butt-ugliness reduction
Dave Mitchell wrote:
> * Is there ever any need to for a PMC type which holds both an int and a
> num? In the Perl 5 case we were constrained by code that expected to always
> find an int (or a num) in a fixed slot in the SV; with PMCs, all access
> to these slots is via methods, so an int-num or num-int conversion can
> be done on the fly.
There is. You can't necessarily convert on the fly - perl5 allows
dual-typed SVs where the string and number aren't necessarily
interchangable versions of each other. I use this ability, for example, to
map C #define constants to perl SVs that behave like the symbolic value in
a string context and the numeric value in a numeric constant. e.g. given
this in a header file:
#define FOO 2
#define BAR 4
and mapping those to similarly named perl variables
my $fb = $foo | $bar;
assigns 6 to $fb, but
print("$foo | $bar\n");
prints out "FOO | BAR"
This is a really useful feature because it means that you don't need huge
lookup tables to convert from the numeric to the string version of a
constant - it is both at the same time.
--
Alan Burlison
--
$ head -1 /dev/bollocks
immutably engage omnipresent server-centric drivers
Re: Butt-ugliness reduction
Alan Burlison <[EMAIL PROTECTED]> wrote: > Dave Mitchell wrote: > > * Is there ever any need to for a PMC type which holds both an int and > > a > > num? In the Perl 5 case we were constrained by code that expected to > > always > > find an int (or a num) in a fixed slot in the SV; with PMCs, all > > access > > to these slots is via methods, so an int-num or num-int conversion can > > be done on the fly. > > There is. You can't necessarily convert on the fly - perl5 allows > dual-typed SVs where the string and number aren't necessarily > interchangable versions of each other. Ahem, I was asking about int and num, not num and string :-) Dave M
Re: Butt-ugliness reduction
On Sat, Nov 17, 2001 at 02:22:44PM +, [EMAIL PROTECTED] wrote: > Alan Burlison <[EMAIL PROTECTED]> wrote: > > Dave Mitchell wrote: > > > * Is there ever any need to for a PMC type which holds both an int and > > > a > > > num? In the Perl 5 case we were constrained by code that expected to > > > always > > > find an int (or a num) in a fixed slot in the SV; with PMCs, all > > > access > > > to these slots is via methods, so an int-num or num-int conversion can > > > be done on the fly. If you use the same value enough times in places where you need an integral value, (an array index, an argument to substr etc), it is faster to cache the int value than converting from double (or BIGFLOAT) every time. -- Jason
Size of integer register vs sizeof(void *)
Are there any cases where a void * cannot be placed into an integer register? It seems like it shouldn't happen, especially since jump and jsr are supposed to take an integer register and they point to a host-machine-address... Brian
Re: Size of integer register vs sizeof(void *)
brian wheeler wrote: > > Are there any cases where a void * cannot be placed into an integer > register? It seems like it shouldn't happen, especially since jump and > jsr are supposed to take an integer register and they point to a > host-machine-address... > > Brian Some Alpha's are 32 bit int / 64 bit pointer. Segher
Re: memory assumptions
[Sorry this has taken so long (as has the rest of my replies to the list).
Between work and the LL1 workshop it's been busy]
At 11:59 PM 11/12/2001 -0500, Michael L Maraist wrote:
>1)
>Are we allowing _any_ dynamic memory to be non-GC-managed?
Yes. We'll have the case where some memory must be pinned essentially
permanently, generally for external use. (Either extensions need it, or
we've handed it off to the system and it'll have to pin. (Think I/O buffers))
Also if someone does a:
$foo = " " x 1000;
I think we'd like to grab a single chunk of pinned memory for $foo so it
doesn't get collected and potentially copied around. Yech.
>2)
>Can we assume that a "buffer object" is ONLY accessible by a single
>reverse-path-to-PMC?
No. Multiple PMCs can point to a single PMC or buffer object.
>3)
>I believe Dan said that we _could_ assume that PMC's were unmovable, but are
>we requiring this? This is related to the next question.
At the moment we're requiring PMCs be unmoveable. I think we should relax
that so that only PMCs that are used by extensions are unmoveable. It'll
make generational collection easier, I think.
We can't necessarily move a PMC that an extension has, since we don't know
all the places that the pointer to it live, and we'd need to update them
all when we moved them. (We can't even force the extension to tell us the
address a PMC pointer is stored at, since we can't then know if a
third-party extension's made a copy of the PMC pointer somewhere)
>4)
>Are _all_ handles (PMC's, Strings, or whatever) that serve as root-set
>elements dynamically allocated?
Yes.
>Or can c-code declare PMC-structs instead of
>PMC-structs-pointers?
No. That's not going to be allowed. We can't change the PMC structure and
maintain binary compatibility if we do that.
>a heterogenous pool of handles would complicate things (and
>disqualify many desirable algorithms).
Welcome to the fun of the world. :)
We have a heterogenous pool of handles. You have, as root set, at least:
*) The main package hash
*) The register set
*) The foreign access registry
*) The savestack
If it helps, the arena structure (which we don't have defined yet) will
look like:
struct PMCArena {
struct PMC PMCs[ARENA_SIZE];
void *PMC_gc_bit[ARENA_SIZE];
}
which is to say that an arena will have at least a void pointer handy per
PMC in an arena. If you need more we can do that, though I'd like to keep
the overhead as low as feasable. It's separate from the main PMC structure
because we only need it for a DOD run. (If its separate, it won't take up
space in a cache line we could otherwise make use of)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Lexical implementation work
At 10:10 PM 11/13/2001 -0500, Ken Fox wrote: >QUESTIONS! > >Who owns the bytecode format? How do I propose changes? Nobody in particular at the moment, and note your change proposals to the list. >I need >a "scope definition" section. Each scope is assigned a per-module >id. I'm not sure what info is needed yet, but certainly a size >and a code ref (opcode address) for the DESTROY sub. For scopes you'll probably also need a template lexical scratchpad ID. >The control stack isn't used for much yet. :) >and it would simplify my >code a lot if we combine the frame stack with the control stack. The control stack is for things the interpreter needs to track. More will go on it--local() restore information, scope markers (for scope cleanup), scoped locks, possibly exception handler markers (though I'm not sure about that yet)--a fair amount of stuff. It would seem appropriate for your frame information to go on it. >The only down-side I think will be with hand-coded assembler. I wouldn't worry too much about the hand-coded stuff. >Anybody care if I subsume the control stack? No. Or, rather, use the control stack for what you're doing. >Lastly, does anybody care if I change how assembler directives >are registered? No. I like the leading period directives. It's either that or ALL-UPPERCASE directives, and that's kind of ugly. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Lexical implementation work
At 03:03 PM 11/12/2001 -0500, Michael L Maraist wrote: > From the above, the only uses I can see for declaring "my $foo as int" is to >set flags (or utilize different vtables) to enforce integerness, and to say >to the optimizer that it's ok to use a primitive integer if the block >contained a divide. Yes. Declaring simple-typed scalars won't buy much. The big win in terms of size will be for: my int @foo; my float %bar; which is where we generally chew up all our memory anyway. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Butt-ugliness reduction
At 08:10 PM 11/15/2001 +, Simon Cozens wrote: >On Thu, Nov 15, 2001 at 02:58:58PM -0500, Michael L Maraist wrote: > > Why are you storing flags for PerlScalarData inside the pmc-flags? > >I'm saying that classes can have user-defined flags, to save a >dereference. Or at least, I'm saying that until Dan wanders over >here and persuades me it's a bad idea. :) Dan thinks its a very good idea. :) Almost anything that potentially saves a dereference's good by me. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Map and Batch Operations on Arrays
At 01:09 AM 11/15/2001 +0200, Shlomi Fish wrote: >Those who read Apocalypse 3 (and everybody here should because the >Apocalypses describe what we plan to implement) would know that Larry Wall >decided to implement batch operations on arrays. Hence it would be >possible to add two arrays in order to get a third array whose members >equal to the sums of the two other arrays. Likewise for multiplication, >division, etc. The way it'll work is if you have: @foo = @bar ^+ @baz; that'll boil down to a single interpreter op: add foo, bar, baz When the add vtable method for the array bar is handed a whole array as its second parameter, it does a piecewise add, as it needs. Non-default behaviour will require list decomposition and mapping and stuff, but that'll be just a few ops too. (map will be a single op, for example) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Proper Tail Recursion
At 01:03 AM 11/15/2001 +0200, Shlomi Fish wrote: >What is the current stance on implementing proper tail recursion in perl6? In perl it's unlikely. (unless you consider redone blocks tail recursion, which they sort of are) In Parrot we can do it. I'll think about it to make sure it's easily doable, though we might not have to do much. Which would be good. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Butt-ugliness reduction
At 01:24 PM 11/16/2001 +, Dave Mitchell wrote:
>* I think that the cache of a PMC ought to be more flexible, eg replace
>
> DPOINTER *data;
> union {
> INTVAL int_val;
> FLOATVAL num_val;
> DPOINTER *struct_val;
> } cache;
>
>with something like
>
> union {
> INTVAL int_val;
> FLOATVAL num_val;
> DPOINTER *struct_val;
> } cache[2];
>
>(note the '[2]')
>
>and where the 2 may become 3 or whatever depending on later profiling.
The problem with that is we have two entries that are as big as the biggest
member when we're probably not going to have two of anything. Floats can be
pretty big.
>There shopuld be a pair of flag bits for each cache entry to tell the
>GC whether that cache entry holds a GC-able ptr, and if so, whether it
>is to a PMC or a buffer.
I was going to toss the string pointer entirely for GC reasons and just
hang 'em off the data pointer.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: JIT compilation
At 03:32 PM 11/16/2001 +0100, Paolo Molaro wrote: >On 11/08/01 Benoit Cerrina wrote: > > I heard that, I was thinking that it would be great to run ruby on mono but > > ruby is very dynamic (like perl but since its so much easier to use and > > program > > it is also easier to redefine the methods and done more often) > >There is an effort to compile ruby to the CLR, I don't know more, >because I can't read japanese :-) And there is someone working on python >support in the mono compiler, too. Keen. We'll do so at some point too, I expect. >BTW: we just got our compiler running on linux and compiling a simple >program, hopefully by next week it can be used for some more real code >generation. Yahoo! Congrats. Are we still slower than you are? :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
