Author: Miguel A. Ballicora
Date: 09:59:10 01/14/03
Go up one level in this thread
On January 13, 2003 at 22:55:11, Robert Hyatt wrote: >On January 13, 2003 at 03:16:32, Miguel A. Ballicora wrote: > >>On January 12, 2003 at 13:43:00, Matt Taylor wrote: >> >>>On January 12, 2003 at 02:26:25, Miguel A. Ballicora wrote: >>> >>>>On January 11, 2003 at 19:23:19, Robert Hyatt wrote: >>>> >>>>[snip] >>>> >>>>>>>But it is a headache that could be eliminated. IE on a PC you know that >>>>>>>short=16, int=32, long=32 and long long=64. But _only_ on a PC. It would >>>>>>>be nice to know something about specific types that applies to _all_ >>>>>>>architectures... >>>>>>>int8, int16, int32 and int64 would do just fine since the older architectures >>>>>>>with 36, 48 and 60 bits are pretty much history... >>>>>> >>>>>>You assume that those architectures are history, that might be true today but C >>>>>>was not born today. >>>>> >>>>>Standards were done _recently_ again. >>>>> >>>>>three years ago in fact.. >>>> >>>>Now I really don't know what this thread is about. It is about standard C in his >>>>whole history (1) or is it about stantard C today (2)? >>>> >>>>If it is 1, you cannot neglect the other architectures. >>>>It is is 2, C99 includes the types that you want, and I don't understand then >>>>your criticism to the standard. >>>> >>>>Miguel >>> >>>It is about both. Myself and others like David have argued that those >>>int16/int32 types could have been in from the start with no threat to >>>implementation on machines with 36-bit words or other oddities. >> >>Not at all, historically at that point it did not make sense. Moreover, it could >>have been int36 and not int32. Unix ran in 36 bit machines too. >>One of the several reasons why C had a tremendous success was because it has >>been linked to Unix, which was ported between machines of different word sizes. >>Another, citing Dennis Ritchie: >>"...C remains a simple and small language, translatable with simple >>and small compilers..." >> >>So the spirit was to make it fast, efficient, small and not giving too much. >>Very practical. Introducing int32 was probably the least of the things that D. >>Ritchie wanted at that time. >> >>Another reason for success: >>"...Although C was not originally designed with portability as a prime goal, >>it succeeded in expressing programs, even including operating systems, >>on machines ranging from the smallest personal computers through the mightiest >>supercomputers..." (Dennis Ritchie) >> >>>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. >>>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. >> >>>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. >> >>Miguel > > >I believe this is "wishful remembering" on his part. C was not developed >and used on a supercomputer, nor on a 36 bit machine, until _years_ after >it was originally written. It was originally written for a Digital PDP and According to Dennis Ritchie, C was developed in a PDP-11 but it was ported in the same period to a Honeywell 635 (36 bits). >nothing else. As was unix. years later it started to get ported to other Unix was developed originally in an 18 bits computer (PDP-7), written in B. Miguel
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.