www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - My two cents

reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Speaking of axing things from the spec before 1.0,
what will happen to the "cent" and "ucent" types ?

As in: they're not even in the DMD keyword list...
Sounds like good candidates for termination to me.


They don't seem to be just buggy and/or problematic
like "bit" and "real" are, but fully unimplemented ?

And one could just use etc.bigint* or even ulong[] instead ?
http://www.digitalmars.com/d/archives/digitalmars/D/8959.html


Or is it somehow remotely connected to "vector" types ?
(those are OTOH very useful already, and all 128 bits)

Adding SIMD support to D does sound like a lot more work
than a 128-bit integer type, even if a lot more useful...


Or is there any other possible reason for keeping the 2¢ ?
--anders


* http://svn.dsource.org/svn/projects/deimos/trunk/docs/bigint.html
   (Arcane Jill's code does come with one of the weirdest licenses,
    making it unsuitable for any library, but there are others too;
    such as "GNU MP Bignum": http://www.swox.com/gmp, written in C++)
Feb 07 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:cu7v1j$2c11$1 digitaldaemon.com...

 Speaking of axing things from the spec before 1.0,
 what will happen to the "cent" and "ucent" types ?


If they're 128-bit integers, then I say: let's have 'em. Or at least 
lets leave them in the spec, so we can have 'em later.

JMO
Feb 07 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


Speaking of axing things from the spec before 1.0,
what will happen to the "cent" and "ucent" types ?


 
 If they're 128-bit integers, then I say: let's have 'em. Or at
 least lets leave them in the spec, so we can have 'em later.


But what good are they ? Isn't long "emulated" often enough ?
(the whole idea was to take pure fantasy stuff out of the spec)

--anders
Feb 07 2005
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders F Björklund schrieb am Tue, 08 Feb 2005 00:38:04 +0100:

 Matthew wrote:


Speaking of axing things from the spec before 1.0,
what will happen to the "cent" and "ucent" types ?


 
 If they're 128-bit integers, then I say: let's have 'em. Or at
 least lets leave them in the spec, so we can have 'em later.


 But what good are they ? Isn't long "emulated" often enough ?
 (the whole idea was to take pure fantasy stuff out of the spec)


They should at least remain as "reserved" keywords. Otherwise any
 - still distand - improvements would be hampered by missing keywords.

Meanwhile the compiler should check that those keywords aren't used
and don't later cause some of the "length" problems.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCCAO53w+/yD4P9tIRAim5AKCjuzbIWexWIklgEOBglPVY2mWuggCgrNvn
2pEK/KQ7kg5Bx1qdn0YlFjw=
=+E33
-----END PGP SIGNATURE-----
Feb 07 2005
parent reply John Demme <me teqdruid.com> writes:
Thomas Kuehne wrote:

 Anders F Björklund schrieb am Tue, 08 Feb 2005 00:38:04 +0100:
 

Matthew wrote:



Speaking of axing things from the spec before 1.0,
what will happen to the "cent" and "ucent" types ?


If they're 128-bit integers, then I say: let's have 'em. Or at
least lets leave them in the spec, so we can have 'em later.


But what good are they ? Isn't long "emulated" often enough ?
(the whole idea was to take pure fantasy stuff out of the spec)




 
 
 They should at least remain as "reserved" keywords. Otherwise any
  - still distand - improvements would be hampered by missing keywords.
 
 Meanwhile the compiler should check that those keywords aren't used
 and don't later cause some of the "length" problems.
 
 Thomas
 
 



We don't want to have to use "long long" for cent once it's implemented.
Feb 07 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Demme 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)




 They should at least remain as "reserved" keywords. Otherwise any
  - still distand - improvements would be hampered by missing keywords.


 We don't want to have to use "long long" for cent once it's implemented.


You could use of course also use four "long" integers, instead :-)
(which is what the computer will end up with on 32-bit CPUs anyway)

--anders
Feb 07 2005
parent John Demme <me teqdruid.com> writes:
Anders F Björklund wrote:

 John Demme 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)





 They should at least remain as "reserved" keywords. Otherwise any
  - still distand - improvements would be hampered by missing keywords.


 We don't want to have to use "long long" for cent once it's implemented.


 
 
 You could use of course also use four "long" integers, instead :-)
 (which is what the computer will end up with on 32-bit CPUs anyway)
 
 --anders


I think we've got something here...

int int int int myBigInt = ...;// Some huge number

The four int specifiers tell the compiler to create a 128-bit variable 
using four 32-bit ints, whereas

long long myBigInt = ...;//Some huge number
Tells it to use two 64-bit integers.

This way, the former would only use half of each register on 64-bit chips.


Heh... Too bad I can't think of a single good reason for anyone to use 
such a frivilous feature.
Feb 07 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:cu8u4s$18m3$1 digitaldaemon.com...

 Matthew wrote:


Speaking of axing things from the spec before 1.0,
what will happen to the "cent" and "ucent" types ?


 If they're 128-bit integers, then I say: let's have 'em. Or at
 least lets leave them in the spec, so we can have 'em later.


 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".

:-)
Feb 07 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 07 2005
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
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
Feb 08 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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...)
	

 Meanwhile the compiler should check that those keywords aren't used
 and don't later cause the some of the "length" problems.


But length was not a keyword, but a dirty hack that affected Kris...
"bool" on the other hand, could be made into a proper D keyword ?


But I guess if we can support "real" with two doubles for
platforms that don't have any built-in 80-bit FPU registers*
(such as PPC and Sparc), then we can support "cent" by using
two long longs on platforms with 64-bit support (or 4 longs ?)

Just thought it was easier to have that in a library instead...
(and if needed, could be adding back in as 2.0 feature along
with the array operations and array/function literals and so)
Or do you think we'll have 128 bit CPUs, by the time D is out ?

--anders

* this is done by the C compiler, just as it is for long longs
Feb 07 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders F Björklund schrieb am Tue, 08 Feb 2005 01:30:45 +0100:

 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?


 Meanwhile the compiler should check that those keywords aren't used
 and don't later cause some of the "length" problems.


 But length was not a keyword, but a dirty hack that affected Kris...
 "bool" on the other hand, could be made into a proper D keyword ?


<snip>


 Just thought it was easier to have that in a library instead...
 (and if needed, could be adding back in as 2.0 feature along
 with the array operations and array/function literals and so)


If defined in object.d, then the library hack should do it right now.


 Or do you think we'll have 128 bit CPUs, by the time D is out ?


mmmhhhhhh.....

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFCCChz3w+/yD4P9tIRArywAKCnCChU7dE74KfCc8VOLXuc4cI31ACffaSL
pedf1N3iobN68A3bAMGkIt4=
=C6mW
-----END PGP SIGNATURE-----
Feb 07 2005
next sibling parent reply kris <kris_member pathlink.com> writes:
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 :)
Feb 07 2005
parent reply Gold Dragon <dragonwing dragonu.net> writes:
How much do they cost?


 We already have 'em, if you employ Screamin' SIMD :)
Feb 07 2005
parent reply Kris <Kris_member pathlink.com> writes:
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).
Feb 07 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 07 2005
parent reply kris <fu bar.org> writes:
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! ?
Feb 08 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 08 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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.
Feb 08 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 07 2005