Author: Robert Hyatt
Date: 19:55:11 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: > >>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 nothing else. As was unix. years later it started to get ported to other platforms. The first supercomputer was ported to was a Cray, and that didn't happen until the late 1980's. Until that point Cray used their own O/S. So when that was all done, the machine family it ran on fit the current model of int16 and int32 perfectly. I've never run on a unix variant that ran on a 36 bit machine, nor a 60 bit machine. That doesn't mean they didn't exist but I have never seen one running unix myself...
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.