Author: Robert Hyatt
Date: 08:40:00 01/11/03
Go up one level in this thread
On January 11, 2003 at 02:00:38, Miguel A. Ballicora wrote: >On January 10, 2003 at 21:34:38, Robert Hyatt wrote: > >[snip] > >>>>I need a 32 bit counter. I need a 64 bit bitboard. I need a 16 bit index. >>> >>>Use int, long (or long long) and int, respectively. I fail to see the the >>>problem. >> >>You pointed out the problem. I want a 64 bit value. Do I use long or long >>long? Impossible to answer unless I know the machine I am running on, which >>is a real _problem_. > >As I said in another part of the thread, do you want portability or specificity? >If you want portability, use long long. That's it. What do you suppose will happen when we have 64 bit machines with 128 bit integers? Care to guess what that will do to portability when you try to send binary files around between a 32 bit and a 64 bit architecture? Then you might begin to see _the_ problem with the data types as they exist. > If you want to be very >specific, you don't care, you choose the one that the compiler provides for that >machine. That is the point. There is _no_ way I can say "I want 64 bits, period." It doesn't exist. There is no way I can say "I want 32 bits, period." It also doesn't exist. > >>btw, "int" won't work for a 16 bit index. IE I expect that to have values >>between 0 and 65535. And wrap around as any 16 bit counter would do. Dropping >>that into an int won't fly unless I am running on a 286. > >Then you do not need a "mathematical" number but a "set of bits". You already >know the solution, you 'and' a proper mask and that's it. Do not tell me that it >hurts performance because a similar operation must be done by the compiler in >your scheme. Here, you have to do it by yourself. C is not a super high level >language and never intended to be, but it gives you the flexibility to do really >whatever you want. I can do _anything_ using your approach. But that is ridiculous. What would you do if your assembler had ambiguous things, so that "word" might be 16 or 32 bits depending on the particular processor you are coding for? That is the case we have in C today. And it means that porting from 32 bit to 64 bit machines requires hand-tuning to make it work. Been there. Done that. Got the T-shirt... > >Now, what would you do in your scheme if you need a fast integer to process very >simple arithmetic and be used in loop counters that won't reach high numbers >(i.e. 2^15)? at the same time you need to write portable code. >This is the most typical case in integer arithmetic. In C is very easy, you just >use int and you got portability and performance. That is _the_ point. For counters I like the concept of "int". That is fine. IE in fortran, the variables starting with i,j,k,l,m and n are integers by default. But I _also_ want specific types as well. I want 8 bit, 16 bit, 30 bit, 32 bit, 36 bit, 48 bit, 60 bit and 64 bit values, so that I _can_ be specific for any architecture I might run into. And I want the compiler to support 16, 32 and 64 for _any_ architecture so that I can port easily. You mention long long. It has not been in the C standard very long. It isn't supported by _all_ compilers either since it is pretty new. That points out the fact that an error was made and long long was a kludge to try to fix one aspect of the error. There are others hanging, such as specifying 32 bits, _period_. > >Even if you want something very specific you can use unsigned bitfields so they >will wrap after 12, 17 or whatever bits you want. Generally using the 'and' is >so simple that it doesn't justify to be bothered. > Sorry but that is wrong. Bitfields are not well-defined in the standard. Which end do they start from? You instantly see the problem with using them. And trying to put them into a structure adds a random amount of padding, the random amount being the unused bits in a native "thing" the compiler has to use, which is yet another problem. > >>>>What works on the Cray will fail on the PC, because "long" works for the >>>>Cray/Alpha but not for the PC if I want a 64 bit integer... >>> >>>If you want portable code, use long long for both. If it is a very important >>>variable use typedef. >> >>By that logic, all that would be safe to use is "long long" which is, in itself, >>a problem. If I only need values that fit in 32 bits, I want to be able to use >>32 bits, and the same for 64 bits... I want to be able to say what I need, >>and then let the compiler complain if it can't deliver that. Which will let >>me know I have a problem, rather than the present scheme of the compiler >>assuming something that very well could be wrong... > >You did not refer to the above 'if'. You want portable code or not? that is the >key. > >Miguel I want portable code _first_. Right now we can not do that with 100% reliability as I can in FORTRAN or ADA.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.