SSE, AVX, and beyond

[Mattias Holm]

Robert Fraser wrote:
> Eljay wrote:
> Is there ANY use case where you'd need a 256-bit integer instead of a 
> BigInteger? Even 128 is a bit dodgy. UUIDs and what not are identifiers, 
> not numbers, so have no problem being stored in a struct wrapping a 
> ubyte[].

Fixed point arithmetic!!!

Seriously, 256 bit fixed point numbers (roughly an integer, but with 
renormalization after multiplication and division) can represent the 
position of anything in the visible universe at a smaller scale than the 
plank length (which physically does not make any sense). I would find 
that pretty nice to work with, actually, it would be a lot nicer than 
doubles.

> I agree compilers should support 256+ bit _data_... But doing so with an 
> entirely new numeric data-type is probably a bad idea. Special treatment 
> for certain constructs and library support is a much better idea.

I don't get this, I am doing research in compiler optimizations, and I 
can say that library supported value types are just painful to reason 
about since they are not part of the language, they end up as being not 
properly formalized, and the compiler will lose optimization opportunities.

It makes more sense to declare some growth opportunity for the future, 
and then add new types (with new keywords) in future language revisions 
(which should be enabled by flags, this does complicate the parser a 
little bit, but it does not have to overly complicated in a handwritten 
parser.


/ Mattias