Fwd: Handling non-standard integer types

Andrew Whitworth wknight8111 at gmail.com
Sun Feb 12 15:46:40 UTC 2012


It depends what you mean about "plans ... to support more than integer
type". There are a few ways we could support a 64-bit integer:

1) Add a new register set for consistently-sized large integer types
(i.e. $Ix is for system-sized integers, but $Lx would always be for
large 64-bit integers). This would be a hassle to implement.
2) Change configuration to always force the $I register set to be
64-bits wide. This would waste a lot of space where such large
integers weren't needed, and might be inefficient on platforms without
good 64-bit arithmetic support.
3) Keep the $I register set the same (platform/config-dependent) but
add in Int64 (and Int32, etc) PMC types. These might be a replacement
for or a supplement to our current Integer PMC type. (We would need to
work out all sorts of boxing and autoconversion rules, and PMC
operations are inherently less efficient than $I registers, etc)

There may be other ways that I can't think of right now. Suggestions welcomed.

I think what we need most on the parrot-side is for Rakudo people to
tell us exactly what is wanted and we will make it happen.

--Andrew Whitworth



On Sun, Feb 12, 2012 at 8:56 AM, Moritz Lenz <moritz at faui2k3.org> wrote:
> Hi all,
>
> the Perl 6 specification says we need to implement types such as UInt64,
> that is an unsigned 64 bit integer. And Rakudo is now at the point where
> it makes sense to support such types. For example a number type we use
> fairly often is 'Rat', a rational number that stores the denominator as
> such a uint64.
>
> Are there any plans from the Parrot side to support more than integer
> type? I'm pretty sure even 32bit machines support uint64 operation these
> days (or are easy-ish to do with the help of the carry flag), but it'd
> be quite hard to handle these types if they don't fit into Parrot's
> integer registers.
>
> On #perl6, Gerd R remarked that most arithmetic ops are the same for
> signed and unsigned integers (assuming 2s complement), so it might make
> sense to just always configure parrot to work with 64 bit ints, and
> provide additional ops for those that work differently depending on
> signedness (division, comparison).
>
> Any thoughts?
>
> Cheers,
> Moritz
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev


More information about the parrot-dev mailing list