Re: Synopsis 9 draft 1
Aaron Sherman
On Thu, 2004-09-02 at 19:47, Larry Wall wrote:
> =head1 Overview
>
> This synopsis summarizes the non-existent Apocalypse 9, which
> discussed in detail the design of Perl 6 data structures.
[...]
> =head1 Sized types
>
> Sized low-level types are named most generally by appending the number
> of bits to a generic low-level type name:
>
> int1
> int2
> int4
> int8
> int16
> int32 (aka int on 32-bit machines)
> int64 (aka int on 64-bit machines)
Ok, so Parrot doesn't have those. Parrot has "int". Presumably this
means that when the high-level language programmer (Perl 6 here, but
that's just an example) tries to get "lower level" by explicitly using a
sized type, they're going to have to be working in a PMC of some type
like PerlInt16, which (for reasons of overflow behavior and a few other
things) can almost never be optimized down into an integer register.
It seems to me that this causes a dilema for high-level languages where
providing to the user what appears to be finer grained control over
implementation actually makes them work at a higher level of
abstraction.
How would Parrot expect languages to implement such features? Should
there be a set of (highly JIT-optimizable) PMCs that present sized type
features, should the core register types be sizable somehow or should
languages just be left to roll their own PMCs that do whatever they
want?
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Michel Pelletier
> > int1
> > int2
> > int4
> > int8
> > int16
> > int32 (aka int on 32-bit machines)
> > int64 (aka int on 64-bit machines)
>
> Ok, so Parrot doesn't have those. Parrot has "int".
I think it should have those, but I'm not a Parrot developer, I've jused
used PIR.
But I have used a few other VMs in this application and have found
explicit integer sizes useful. For example JADE (an amazing
math/physics/units/sycro Java library):
http://jade.dautelle.com/api/overview-summary.html
Has real-time (do not cause Java new or free, removing GC) numerics
based on shared in context pools, that can be freed or reused. Its
numbers heirarchy is:
http://jade.dautelle.com/api/jade/math/numbers/package-summary.html
The Ficl VM also has specific interger sizes that at least made the
machine more easy to understand:
> How would Parrot expect languages to implement such features? Should
> there be a set of (highly JIT-optimizable) PMCs that present sized
> type
> features,
Yes, again, not a developer.
> should the core register types be sizable somehow or should
> languages just be left to roll their own PMCs that do whatever they
> want?
The second would definately put the burden on the language designer.
-Michel
mar...@kurahaupo.gen.nz
> > Sized low-level types are named most generally by appending the number
> > of bits to a generic low-level type name:
> >
> >
>
> Ok, so Parrot doesn't have those. Parrot has "int".
The above "generic low-level types" are specific instances of a more general
specification-based type system, with features grouped roughly as:
* what range of values _must_ be storable, and what range of values
_may_ be storable
* what do you want to do if an attempt is made to store values outside
the latter range
The possible specifications for "out of range" behaviour should include:
bound - force to nearest bound
ignore - don't store, keep the previous value
throw - "die" in perl-speak
use(CONSTANT) - for example, use(undef)
wrap - apply a modulus
fastest - do whichever of the above gives the best performance on the
current platform
Presumably the default would be :out_of_range(wrap,lax), subject to
modification by pragmata of course.
The range should be specifyable as a numeric range, with an optional
parameter:
strict - use exactly the limits specified
lax - use the natural limits of the underlying implementation (unless
some contrary pragma is in effect, for testing purposes)
Specification of signed and/or unsigned bitfields is problematic; usually
they're used because the author assumes they will only-just-fit-into a
specific implementation type, in which case the "lax" parameter would give
the same benefit for a more readable range specification.
Only in specific applications like CRC computation would an actual specific
binary modulus be appropriate.
Requirements of less expressive languages could be written in terms of
these; in perl6-ish terms, perhaps something like this:
my int $int1 :range( -1..0 ) :out_of_range(wrap);
my int $int2 :range( -2..1 ) :out_of_range(wrap);
my int $int4 :range( -16..15 ) :out_of_range(wrap);
my int $int8 :range( -128..127 ) :out_of_range(wrap);
my int $int16 :range( -32768..32767 ) :out_of_range(wrap);
my int $int32 :range(-2147483648..2147483647) :out_of_range(wrap);
my int $int64 :range(-9223372036854775808..9223372036854775807) :out_of_range(wrap);
my int $int128 :range(-170141183460469231731687303715884105728..170141183460469231731687303715884105727) :out_of_range(wrap);
my int $byte :range( 0..255 ) :out_of_range(wrap);
my int $bool :range( 0..1 ) :out_of_range(use(1));
In my opinion we should target this case: a language that lets you specify to
this level of detail, and automatically infers the most efficient low-level
type from the given specification.
To implement this, should we consider attaching a "store" (native) method to
each integer register, which could implement the required logic for each of
the above cases? Or would we need perhaps a vtable, with both "store" for
when we're interpreting, and "generate_jit_store" for when we're jitting?
-Martin
Aaron Sherman
> On Mon, 6 Sep 2004, Aaron Sherman wrote:
> > > Sized low-level types are named most generally by appending the number
> > > of bits to a generic low-level type name:
> > >
> > > [...] int1 int2 int4 int8 int16 int32 int64
> > >
> >
> > Ok, so Parrot doesn't have those. Parrot has "int".
>
> The above "generic low-level types" are specific instances of a more general
> specification-based type system, with features grouped roughly as:
Martin, I don't think you can reasonably have the integer registers
"typed" so as to allow for multiple storage representations. For one,
the very fact that they lack such baggage is what makes them useful.
It *may* make sense to provide an unsigned, 64-bit integer somewhere,
though (I hesitate to say as an alternate register type, since that
touches so much of Parrot).
The real question is this: is this just a Perl 6 thing (if so, then it's
fodder for the newly created p6c, and we should drop it), or will/should
other high level languages be defining sized integer types through
Parrot? If so, then I don't think the current idea of having an
"Integer" PMC is going to be as generic as suggested.
If you think that the limitation of not having a handy 64-bit type on a
32-bit system is no big deal, check out the convolutions one Python user
suggests under Windows just to store the time:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303344
Yeah, you're gonna want to not do that ;-)