On 7/26/16, Jonathan Wakely <jwakely....@gmail.com> wrote: > On 26 July 2016 at 14:31, Warren D Smith wrote: >> 1. Gcc with stdint.h already >> provides such nice predefined types as uint8_t. >> Sizes provided are 8,16,32, and 64. >> In some sense uint1_t is available too (stdbool.h) >> but at least on my machine stdbool uses 8-bits to store a bool, > > Because that's the smallest addressable unit.
--look, I know there is a pascal front end for gcc, so I know gcc could provide packed bool arrays, because whoever wrote pascal-gcc already did provide it. Also, I know on some machines to access a byte you have to get a word (larger than 8 bits) from memory, do shifts and masks. So clearly you already do that inside gcc. It therefore is trivial for you to do uint4_t also, because it would be that exact same code you already have, just change some numbers. The reason C language originally went with 8,16,32 only, was an embarrassing historical accident because the first C compiler was developed on some obsolete DEC PDP machine from hell. DEC no longer exists, and PDP machines also no longer exist. To make things worse, they originally defined C *WITHOUT* actual unambiguous meanings, for example "int" might be who knows how many bits wide, language would not define that. This horrible nonportability again was done because the original developers of C foolishly acted like that one PDP machine was going to be the only machine ever to handle C, in which case their decisions made perfect sense. However, it is now the year 2016. Many other machines with many other word sizes have been developed. It is simply flat out wrong to say that a byte is the "smallest addressable unit" if we are on a machine with a different word size, for example I know 60-bit and 36-bit wide machines were sold at one point, note not divisible by 8. It is correct for some machines, false for other machines. The point of a high level language like C, as opposed to assembler, it to allow portable code to be safely written without the programmer having to worry about the specific peculiarities of just one machine. You, by saying "because 8 bits is the smallest addressable unit" have just said "I am not interested in that goal, I am only interested in my specific one machine." Mistake. And that mistake was exactly the error made when C was originally created. Later it was recognized by consensus that they had indeed made a design error, and stdint.h was brought to us to correct that error. But it failed to fully correct the error because, at least with gcc's implementation of stdint.h, only 8,16,32, and 64 are provided. The standard however allows other sizes also to be provided, like uint2_t. It is just the gcc did not implement other sizes. Nothing is stopping you. A different poster pointed out gcc has implemented 128, and that is fine, but: (a) not my gcc on my machine! (b) it did it with some horrible syntax, rather than the stdint.h syntax uint128_t, just in order to be nonuniform, just in order to annoy me. Now actually 128 really is harder to do, but 1,2,4 are totally trivial for you to do, in fact were already done by gcc-pascal. >> e.g. an array of 1000 bools takes 8000 bits, >> which is asinine and kind of defeats the point. > > If you want 1000 boolean values then don't use 1000 bool variables, do > something like std::bitset or std::vector<bool> in C++, i.e. create an > array of some integer type and write functions for accessing > individual bits. --If I did that, then I would need to program in C++. Gcc, however, is a C compiler, not a C++ compiler. Therefore, your answer is not an answer for anybody using C. Also, yes I can, and sometimes have, written my own functions in C to allow use of packed nybbles. Sure. But that totally misses my point, which is, programers should not have to keep on reinventing that wheel; It should be provided by the language so they do not have to. And even if they do, then they are forced to use different syntax for 4 versus for 8, which makes code much uglier and larger and buggier for no reason. >> I suggest adding uint1_t, uint2_t and uint4_t support >> to gcc, and packed. > > You can't have a variable of a single bit, because you can't address it. --You can have a variable of a single bit, because you can address it. > GCC already supports __int128 and __uint128 where possible. --false. It does not support it on my machine. And it is certainly "possible" to support it on my machine. It may be "inconvenient" but it certainly is possible. And note __int128 is a new syntax different from the stdint.h syntax int128_t. If you are going to provide a feature, why not provide it in the syntax you already chose to adopt, and the world already chose to standardize? >> It is obnoxious and arbitrary that only 8,16,32,64 are available, > > It's obviously not arbitrary, it's dictated by the hardware. --the point of a high level language like C, is to allow programmer not to worry about specific hardware quirks on specific machines. > Patches welcome. --the reason I am suggesting this to this forum, is I probably am not capable of recoding GCC myself. >> 2. Gcc already provides a way to produce quotient and remainder >> simultaneously, producing a struct with two fields as output: >> div_t x = div(a,b); causes x.quot = a/b, x.rem = a%b. >> Not a lot of people know gcc provides that, but it does, and that is >> good, because >> it provides access to the hardware capability. > > GCC doesn't provide that, the C library does, because it's defined by > standard C and has been for decades. --I found this on gcc documentation web pages, e.g: https://www.gnu.org/software/libc/manual/html_node/Integer-Division.html and some such page claimed gcc provides this as a builtin not as a library subroutine. So we know you can provide such things as builtins. I am simply suggesting superior, more useful, builtins than this particular one. I have explained why mul would be more useful and more needed than div and why div was actually not even necessary to provide at all, but you and/or stdlib, nevertheless did provide it. Given that you and /or stdlib have already decided to do something with usefulness 1, why not actually provide something that is as easy or easier to provide, and which has usefulness 7? I also point out that, historically, one reason gcc caught on was it provided good extensions of the C language, not available in competing compilers. Why not learn from your own history, and do that again, with these two extensions? (And in the case of uint4_t, it actually would not even BE an "extension" since as I said, the standard already allows providing other sizes.) -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)