Author: Matt Taylor
Date: 00:51:55 01/13/03
Go up one level in this thread
On January 13, 2003 at 03:16:32, Miguel A. Ballicora wrote: >On January 12, 2003 at 13:43:00, Matt Taylor wrote: > >>I have further argued that special recognition of the suffix would allow the >>compiler to be extensible. The only operations that are more difficult to >>emulate at larger lengths are multiply and divide. All your basic bitwise >>operations are easy because each bit is seperate. For brevity I will ignore >>arithmatic operations (add/sub/mul/div), though there are techniques for >>implementing them in straight C, and most general-purpose machines have >>facilities to emulate. >> >>C99 has addressed current issues, but C99 -still- lacks foresight to address >>future issues. A 128-bit encryption algorithm is easier to implement using > >I think that this is not really related to the origin of the debate, which is >about strict types. This is more related to the size of them in the future, not >if they exist well defined (int32) or not (int). >IMHO, I do not think that it is practical to _force_ compilers to deal with such >numbers when still common machines do not support that at all. I guess that it >is more efficient for people in this area to use their own libraries and >algorithms. I guess that they would do it anyway in search for efficiency if the >machines does not support them, but I here I might be wrong. Since I am not an >expert on this, it is just a guess. You argue that int32 is not efficient on a 36-bit machine and I rebut with a means to make it efficient -- how is this not relevant? You are right that it is a guess. It is trivial to implement in the compiler. It is quite annoying to implement in software because you have no guarantees about the sizes of types (whereas the compiler does). It can also easily be implemented as a precompiler-like stage if efficiency is not required. >>128-bits. On machines that support it, it is also optimal. Current standards >>make no guarantees that such a type is available. Therefore it cannot be taken >>advantage of unless the programmer adds #ifdef glue to support platforms where >>no such type is available. This is resolved easily and gracefully if you accept >>that the standard is not perfect. The underlying problem has -NOT- been >>addressed by the long long type. It has merely been postponed. >> >>You said something in another post about C not being high-level. So? Do you > >I never said that. "...C is not a super high level language and never intended to be..." http://www.talkchess.com/forums/1/message.html?276354 Ok, not high-level, but super high-level. Either way, the idea of bitfields is not a super high-level concept. The concept of a type that is exactly x number of bits wide is also not a super high-level concept. >>think this idea is any more abstract than short/int/long? Should we code loops >>using conditional gotos? The level of abstraction that C supports is well beyond >>the level of abstraction required for types of explicit size. >> >>The argument that they are difficult to implement is likewise fatally flawed. > >It is not that it is difficult, the point was to make compilers as simple as >possible. That was one of the keys for success as Ritchie thinks. I should correct myself. Rather than just saying it's not difficult, I'm going to say that it doesn't require a lot of code. -Matt
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.