In article <jslld2-545.ln1@lnews.kuehne.cn>, Thomas Kuehne says...
>> Or do you think we'll have 128 bit CPUs, by the time D is out ?
>
>mmmhhhhhh.....
>
>Thomas

We already have 'em, if you employ Screamin' SIMD :)

How much do they cost?

> We already have 'em, if you employ Screamin' SIMD :)

In article <cu9i35$2geu$1@digitaldaemon.com>, Gold Dragon says...
>
>How much do they cost?

What? The Two Cents?

Seriously though: SIMD is 'free' with most recent x86 devices. You just have to poke them with assembly, or hope your compiler can vectorize (as Norbert describes).

Thomas Kuehne wrote:

>>>They should at least remain as "reserved" keywords. Otherwise any
>>>- - still distand - improvements would be hampered by missing keywords.
>>
>>You mean they should be added as keywords ? (for the first time)
>>(along with TOKint128, TOKuns128 and some kind of format char...)
> 
> They are "Basic Data Types" but no kewords right now ...
> 
> ?format char?

As in std.format, for writef and friends ? %d would do, I guess.

--anders

Kris wrote:

> Seriously though: SIMD is 'free' with most recent x86 devices. You just have to
> poke them with assembly, or hope your compiler can vectorize (as Norbert
> describes).

The PowerPC G4 and G5 have SIMD too, without the need for assembler.
There are AltiVec vector extensions for C that are perfectly good...

In fact, you could even use them to make decent MP int libraries:
http://developer.apple.com/samplecode/VelEng_Multiprecision/VelEng_Multiprecision.html


But it's somewhat different from having a CPU with 128-bit integers ?
Though very neat indeed - http://developer.apple.com/hardware/ve/

Just thought they were outside the scope of the D language, since it
is not that hard to write them in C, or assembler, and import them ?


So leave "cent" and "ucent" in then. Maybe they'll even get implemented?
(I'll offer two workarounds: alias long[2] cent; or alias int[4] cent;)

--anders

Matthew wrote:

>>But what good are they ? Isn't long "emulated" often enough ?
>>(the whole idea was to take pure fantasy stuff out of the spec)
> 
> Ok, you've persuaded me.
> 
> I'm the one who always insists on adding some unused fields in communications packet headers, "just in case".

http://c2.com/cgi/wiki?YouArentGonnaNeedIt

But it seems like people want them anyway,
and they could interfact with vector types.

So I guess they stay in. Hopefully they'll
get added to the keyword list proper, too.

--anders

Anders F Björklund wrote:
> Kris wrote:
> 
>> Seriously though: SIMD is 'free' with most recent x86 devices. You just have to
>> poke them with assembly, or hope your compiler can vectorize (as Norbert
>> describes).
> 
> 
> The PowerPC G4 and G5 have SIMD too, without the need for assembler.
> There are AltiVec vector extensions for C that are perfectly good...
> 
> In fact, you could even use them to make decent MP int libraries:
> http://developer.apple.com/samplecode/VelEng_Multiprecision/VelEng_Multiprecision.html 
> 
> 
> 
> But it's somewhat different from having a CPU with 128-bit integers ?
> Though very neat indeed - http://developer.apple.com/hardware/ve/
> 
> Just thought they were outside the scope of the D language, since it
> is not that hard to write them in C, or assembler, and import them ?
> 
> 
> So leave "cent" and "ucent" in then. Maybe they'll even get implemented?
> (I'll offer two workarounds: alias long[2] cent; or alias int[4] cent;)
> 
> --anders

Nice one! That MP-int lib is certainly the 'real McCoy'. Forgive me for ommiting the PPC family, Anders; I was being a bit vague and tongue-in-cheek.

This does prompt a question though: what would people do with 128-bit integers? And for those particular areas, would a struct with the appropriate op-overloads suffice? Would the D compiler inline the ASM bodies of said op-overloads?

Another question: when is Anders gonna' wrap that MP-Int lib with a D struct? :-)

Even better -- who's gonna write the parallel vector library for that little 8-SIMD-core Cell processor? Do you suppose IBM will have something lying around?

http://arstechnica.com/articles/paedia/cpu/cell-1.ars

Can I get a WooHoo! ?

kris wrote:

> Nice one! That MP-int lib is certainly the 'real McCoy'. Forgive me for ommiting the PPC family, Anders; I was being a bit vague and tongue-in-cheek.

That is just some sample code, *vecLib.framework* is the real McCoy
(seems like the Apple marketing guys who brought us "Velocity Engine"
have now renamed it to "Accelerate.framework", but same difference...)

> This does prompt a question though: what would people do with 128-bit integers? And for those particular areas, would a struct with the appropriate op-overloads suffice? Would the D compiler inline the ASM bodies of said op-overloads?

There are two huge pains about these: vector registers need
16-byte alignment to load, and they don't work everywhere -
so they need regular C code for SIMD-challenged environments

> Another question: when is Anders gonna' wrap that MP-Int lib with a D struct? :-)

There is some five-year old code for a vBigNum library with
support for 128, 256, 512 and 1024 bit integers (yet another
reason why there is no particular reason for just a "cent"?)

> typedef union {
> 	vector unsigned long v;
> 	struct
> 	{
> 		unsigned long MSW;
> 		unsigned long d2;
> 		unsigned long d3;
> 		unsigned long LSW;
> 	} s;
> } vU128;
> 
> typedef union
> {
> 	vector unsigned long v;
> 	struct
> 	{
> 		signed   long MSW;
> 		unsigned long d2;
> 		unsigned long d3;
> 		unsigned long LSW;
> 	} s;
> } vS128;

I can write a wrapper for that library, by omitting the "vector".
(and you could still use the struct to get at all the bits of it?)

These days, one just has to link in -faltivec -framework Accelerate
and then from C/C++ "#include <vecLib/vBigNum.h>" which brings in:
/System/Library/Frameworks/vecLib.framework/Headers/vBigNum.h

If on Darwin, that is. (believe it even has a SSE version for i386?)
The rest of you would get the: static assert(0); // bring your own MP
implementation that is oh-so-common for the rest of D library code ;-)

Wonder if one could even overload the regular math operators ? Hmmm...

--anders

I agree almost completely. But I can guarantee you that a little forethought on comms protocols is worth the effort, even if it's a single byte that's zero in the current version of the protocol. :-)

"Anders F Björklund" <afb@algonet.se> wrote in message news:cu9r4i$9m9$1@digitaldaemon.com...
> Matthew wrote:
>
>>>But what good are they ? Isn't long "emulated" often enough ? (the whole idea was to take pure fantasy stuff out of the spec)
>>
>> Ok, you've persuaded me.
>>
>> I'm the one who always insists on adding some unused fields in communications packet headers, "just in case".
>
> http://c2.com/cgi/wiki?YouArentGonnaNeedIt
>
> But it seems like people want them anyway,
> and they could interfact with vector types.
>
> So I guess they stay in. Hopefully they'll
> get added to the keyword list proper, too.
>
> --anders

I wrote, in response to Kris:

>> Another question: when is Anders gonna' wrap that MP-Int lib with a D struct? :-)
> 
> There is some five-year old code for a vBigNum library with
> support for 128, 256, 512 and 1024 bit integers (yet another
> reason why there is no particular reason for just a "cent"?)
> 
> I can write a wrapper for that library, by omitting the "vector".
> (and you could still use the struct to get at all the bits of it?)
> 
> These days, one just has to link in -faltivec -framework Accelerate
> and then from C/C++ "#include <vecLib/vBigNum.h>" which brings in:
> /System/Library/Frameworks/vecLib.framework/Headers/vBigNum.h

Well, it was indeed possible to do. Just that without the
128-bit registers, then everything has to be passed on the
stack. And that tends to suck, at least for just 128-bit...
(especially with saving the VR state, and the checking if
AltiVec is present, and the rest of the overhead involved)
Might be more of a great idea with 256/512/1024 bit integers ?


But it can be done, with a C wrapper file: (-faltivec)

> #include <vecLib/vecLib.h>

> //typedef vector unsigned int             vUInt32;

> void vU128AddP(
>   vU128 *  a,
>   vU128 *  b,
>   vU128 *        result)
> {
>         *((vUInt32 *) result) =
>                 vU128Add( *((vUInt32 *) a), *((vUInt32 *) b) );
> }

And a D class that does operator overloading:

> import vecLib.vecLib;

> class ucent
> {
>         vU128 v;

>         ucent opAdd(ucent other)
>         {
>                 vU128 a = this.v;
>                 vU128 b = other.v;
>                 vU128 r;
>                 vU128AddP( &a, &b, &r );
>                 return new ucent(r);            }

Probably not at all worth it, though... Might as well
write the whole function that needs big integers in C
(be it crypto or whatever), and *then* call it from D ?

cent and ucent are useless, unless they are in registers.
(might as well use a full-featured MP library, otherwise,
and that is best done wrapped as a regular class anyway ?)

But it could be left in the spec, for another 5 years or so.

--anders

PS. The full vU128 became, with the endian worries:

> version(PPC) // must have __VEC__ too
> {
> 
> struct vU128
> {
>     uint       MSW;
>     uint       d2;
>     uint       d3;
>     uint       LSW;
> }
>
> else version (X86) // must have __SSE__ too
> {
> 
> struct vU128
> {
>     uint       LSW;                  /*MSW;*/
>     uint       d3;                   /*d2;*/
>     uint       d2;                   /*d3;*/
>     uint       MSW;                  /*LSW;*/
> }
>
> }

Darwin is not supported on other platforms than those.