Handling non-standard integer types

[Jonathan "Duke" Leto]

Howdy,

3) sounds the most reasonable to get something done in the near future.
whiteknight++ is right in that a PMC will be slower, but let's cross
that optimization bridge when we get there.

These kind of needs are the kind of thing that will influence the design
of M0 (no, I haven't given up on that), so I would also like to hear a
detailed explanation from Rakudo folk about *exactly* what they want and
need.

Duke

On Sun, Feb 12, 2012 at 7:46 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev



-- 
Jonathan "Duke" Leto <jonathan at leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.