On Wed, 23 Oct 2002, Rhys Weatherley wrote:
> Martin D Kealey wrote:
> > [Frank Farance's paper] "specification based extended integer range"
> > [at] http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/.
> Very interesting proposal. I wish they had adopted it. Would
> have saved me a lot of hassle with typedefs over the years. :-)
Ditto!
> This ... works well in a statically compiled language like C because the
> compiler can ... say "Oh! That's just int on this platform!" and then
> compile away the distinction.
>
> I'm not sure how well it would work in a dynamic environment like
> Parrot, where the compiler doesn't necessarily know the final actual
> type.
I think the equivalent for Parrot would be
(1) a requirement to include a module "MEDIUMINT" (smaller than BIGINT), so
that large (but not arbitrarily large) numbers could be supported
(2) mechanisms to swap between that and INTVAL transparently at runtime, or
at least, to allow the compiler to generate both sets of code without
too much pain, or much impact on performance when the numbers are small
enough to be INTVAL.
(3) an opcode along the lines of "truncate to N bits", where N is fixed
(4) an opcode along the lines of "throw exception if wider than N bits",
where N is fixed
> It is up to the runtime engine. e.g. how would the engine rearrange the
> code to do "signed int exact:64" with PMC's on 32-bit platforms and I
> registers on 64-bit? That way lies polymorphic instruction sets and other
> CLI madness ...
(BTW: one of the criticisms of SBEIR was that "exact" and "signed" should
have been mutually exclusive.)
Rather than going the whole hog with polymorphic instruction sets, what
about supporting what I'll call "minor classes", which don't do inheritance
or runtime polymorphism, specifically to support MEDIUMINT and other modules
that mimic-but-extend native datatypes and operations, and are used as
stand-ins by the compiler?
> P.S. I suspect one reason why it was rejected was because some programmer
> would ask for "signed int exact:23517" and expect it to work on every
> compiler. Implementing the intrinsics for something like that is *hard*.
I think there was agreement that it would be OK for the compiler to limit
requests to 128 bits. For Parrot I would suggest that MEDIUMINT implement
at least 2048 bit (256 byte), which would be useful for implementing
cryptographic functions.
-Martin
--
CAUTION: The information contained in this message is consequential and
subject to legacy provenance. If you are the intended recipient you are
hereby notified that reading this message is permitted. If you have not
received this message please notarise the sender and destroy the
originator.
