uint64
Ben Clifford
I was musing about implementing Skein in stupid. Threefish in there uses
64-bit operations. I guess the right thing for implementing that is uint64
(c99 goes up to 64 bits in stdint.h it seems)
Ben Clifford
So in the UBI bit of skein, there's an integer field of 96 bits.
Which makes me start to wonder what big/arbitrary bit-length uints should
look like.
One approach is a 'biguint' type that can handle numbers of any (bounded
by implementation) size.
Another approach is to say that you can write uint followed by anything.
eg. uint96 will be the name of a 96-bit uint.
In generated code, those two approaches probably don't look too different
for the most part. But a uint96 knows that it overflows at 2^96, while a
biguint doesn't. So uint96 behaves like a biguint but with typechecking
and operators that can deal with overflows.
Of course, that blows away the parsing model of saying typenames are
keywords - suddenly anything that is ('uint' + a number) is a valid type
name (and correspondingly operators such as add96, addWHATEVER would need
to exist).
So I'm not sure what I think - if its useful to have the implementation be
detecting overflows then this preserves that in a similar looking syntax.
But it changes the language implementation some.
(a third option is to leave the programmer with uint32 and have them build
their own bigger numbers. but that puts a lot of boilerplate code that
belongs somewhere in the implementation (even if just in something like a
standard library))
Ben Laurie
>
> So in the UBI bit of skein, there's an integer field of 96 bits.
>
> Which makes me start to wonder what big/arbitrary bit-length uints should
> look like.
>
> One approach is a 'biguint' type that can handle numbers of any (bounded
> by implementation) size.
>
> Another approach is to say that you can write uint followed by anything.
> eg. uint96 will be the name of a 96-bit uint.
>
> In generated code, those two approaches probably don't look too different
> for the most part. But a uint96 knows that it overflows at 2^96, while a
> biguint doesn't. So uint96 behaves like a biguint but with typechecking
> and operators that can deal with overflows.
>
> Of course, that blows away the parsing model of saying typenames are
> keywords - suddenly anything that is ('uint' + a number) is a valid type
> name (and correspondingly operators such as add96, addWHATEVER would need
> to exist).
I've been thinking about this and one idea I've had is to have an _
operator, which says what size things are. So, 1_8 would be an 8 bit
one. add_32 would be a 32 bit add (or even, gasp, +_32?).
> So I'm not sure what I think - if its useful to have the implementation be
> detecting overflows then this preserves that in a similar looking syntax.
> But it changes the language implementation some.
>
> (a third option is to leave the programmer with uint32 and have them build
> their own bigger numbers. but that puts a lot of boilerplate code that
> belongs somewhere in the implementation (even if just in something like a
> standard library))
Yeah, what I've been thinking is that we should have a bignum
implementation in Stupid, but do it in such a way that individual
backends can swap it out for a native one.
Interesting question about arbitrary bit sizes with overflow detection,
required matching of size for operations, etc - once we have bignums it
is, of course, easy to build such a thing on top of it - we'd have to
require some native types, of course, or the bignum implementation would
be recursive :-)
--
http://www.apache-ssl.org/ben.html http://www.links.org/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Ben Clifford
When I say 'even more than 64' in this subject line, I think I'm also
talking about small-but-unusal - eg 7 bits.
Skein (for example) has a 7-bit field that is incremented by 1, for
example.