Re: Idea: extend gcc to save C from the hell of intel vector instructions
On 2/18/19, Andrew Pinski wrote: > GCC already has most of this support. See > https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html#Vector-Extensions > > The dot in the typenames are not going to supported though. > > Thanks, > Andrew --what #include files and/or compiler flags are needed to enable this stuff? (Be nice if that doc page said.) My gcc allows me to use, e.g. c = _mm_shuffle_epi8(a, b); (and my code worked!) provided I have done #include #include but if I try to replace that with the nicer (since more portable) c = __builtin_shuffle(a, b); then error: use of unknown builtin '__builtin_shuffle' [-Wimplicit-function-declaration] -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Idea: extend gcc to save C from the hell of intel vector instructions
There are a lot of weird intel vector instructions like
#include
__m128i alignas(16) A, B, C, D, X, Y;
A = _mm_shuffle_epi8(D, Y);
C = _mm_unpackhi_epi16(A, B);
where my gcc seems to know about the latter but not the former
(I have no idea why, and it is very annoying to arbitrarily support the second
and not the first).
Anyhow. If you write code like that, it is horrible to read.
But here is a simple idea for improving the C language which would make
lots of such code easy to read. And write.
First of all, there should be (and pretty much are, see stdint.h, inttypes.h)
int and uint types of various power of 2 bit sizes, e.g.
int16 a;
uint64 b;
uint128 c;
uint256 d;
uint512 e;
uint4 f;
where again my gcc supports the first 3 (after appropriate renamings)
but not the last 3. (Again, very annoying arbitrariness.)
But more importantly, we should add new types like this:
uint128.16 a, b;
meaning a is 128 bits wide, and consists of 16 chunks, each 8 bits wide,
each regarded as an 8-bit-wide unsigned int.
uint256.8 y, z;
and so on.
Note the use of DOTS inside the type name. You could consider other notations,
I am not fixated on this one. Another might be uint128{16}.
OK, now we could do
uint128.16 a, b, c;
c = a+b; //adds the 16-element vectors a and b elementwise
c = a-b; //subtracts vectors
etc.
Life is SO much nicer now. It's practically sane again.
Don't have to keep coming up with all the horrible
names for each possible kind of vector operation, the compiler does it for you.
Compiler can check type compatibility and complain if try to
add incompatible types. etc etc.
And for stuff that really should have funny names,
b = shuffle(c, d)
will have meaning pretty obvious from the types of b,c,d,
and again can complain about type mismatches.
And the type names will no longer be horrible unreadable strings of
nonsense characters.
They will be perfectly readable and logical simple names like uint128.16.
The present hellish situation is partly intel's fault and partly gcc's fault,
but it is absurd, that is for sure, and this hell is entirely
unnecessary, that is
what really rubs your face in it over and over.
--
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
Re: "const"-related gcc warnings with pointers around, annoying
On 1/25/19, Jonathan Wakely wrote:
> On Fri, 25 Jan 2019 at 13:48, Warren D Smith wrote:
>>
>> "foo" is a type that is a struct containing a uint64_t field x[4]
>> (among other things).
>>
>> bool Proc( const foo *dog ){
>>uint64_t *a, *b;
>>a = dog->x; // pointer a now points to dog->x[0]
>>b = something else;
>>if( *a == *b ) return(TRUE);
>>return(FALSE);
>> }
>>
>> Now gcc complains
>> warning: assigning to 'uint64_t *' (aka 'unsigned long long *') from
>> 'uint64_t const[4]' discards qualifiers
>> [-Wincompatible-pointer-types-discards-qualifiers]
>>
>> but the thing is, those pointers a and b, never got used to alter
>> anything. They merely
>> were used to read harmlessly from memory. So dog still clearly was never
>> altered, and hence genuinely was const.
>>
>> The problem here seems to me to be a lack of intelligence inside gcc's
>> thinking on the subject of "const"s.Sure assigning to a pointer
>> could be harmful to const-hood because
>> that pointer could get used someplace else to write to the "const" part
>> of
>> memory. BUT, if we know that pointer never can be used to write
>> to memory anywhere, because it lives only inside the restricted scope of
>> Proc(){}, and never is used to write to memory anywhere, and never is
>> copied to any
>> other variable (because we examine the code inside Proc to verify
>> this), then it was
>> ok and gcc should not warn.
>
> This belongs on the gcc-help list, not here. If you want changes to
> GCC's diagnostics please file a bug report in Bugzilla.
>
> Basically you're asking for GCC to do escape analysis on the converted
> pointer, and suppress the warnings if it doesn't escape and no stores
> are done through the pointer.
>
> I think it would have to be an optional behaviour for the warning,
> because some people *do* want that warning. Maybe the pointer doesn't
> escape today, but the code could change tomorrow, and they'd want to
> be warned about the discarded qualifiers today.
>
> Also, if the pointer's scope is strictly limited to that function, and
> you never write through it, why not just make it const?
--good idea. I thought I wasn't allowed to do that... but tried it
and I am allowed
and it worked. Thanks.
--
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
"const"-related gcc warnings with pointers around, annoying
"foo" is a type that is a struct containing a uint64_t field x[4]
(among other things).
bool Proc( const foo *dog ){
uint64_t *a, *b;
a = dog->x; // pointer a now points to dog->x[0]
b = something else;
if( *a == *b ) return(TRUE);
return(FALSE);
}
Now gcc complains
warning: assigning to 'uint64_t *' (aka 'unsigned long long *') from
'uint64_t const[4]' discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
but the thing is, those pointers a and b, never got used to alter
anything. They merely
were used to read harmlessly from memory. So dog still clearly was never
altered, and hence genuinely was const.
The problem here seems to me to be a lack of intelligence inside gcc's
thinking on the subject of "const"s.Sure assigning to a pointer
could be harmful to const-hood because
that pointer could get used someplace else to write to the "const" part of
memory. BUT, if we know that pointer never can be used to write
to memory anywhere, because it lives only inside the restricted scope of
Proc(){}, and never is used to write to memory anywhere, and never is
copied to any
other variable (because we examine the code inside Proc to verify
this), then it was
ok and gcc should not warn.
--
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
Re: Annoying silly warning emitted by gcc?
The x=x "initialization" idea by paulkon...@comcast.net failed to turn off the warning for me. Joe Buck may be right that gcc "already does the right thing" but actually I was dealing with not a 64-bit wide, but actually a 128-bit-wide type, which might later become 256-wide or even 512; and to load it with 0s actually needs a lot of loading of constants from the instruction stream. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Annoying silly warning emitted by gcc?
x = x^x; The purpose of the above is to load "x" with zero. For very wide types, say 256 bits wide, explicitly loading 0 is deprecated by Intel since taking too much memory. XORing x with itself always yields 0 and is allegedly a better thing to do. But the problem is, gcc complains: variable 'x' is uninitialized when used here [-Wuninitialized] note: initialize the variable 'x' to silence this warning Well, the thing is, it DOES NOT MATTER that x is not initialized, or initialized with wrong data. No matter what was in x, it becomes 0. So, how to get Gcc to shut up and quit whining about this? I do not want to actually load 0. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
> Given a pointer to an array of nibbles and a length, how do I iterate > through the array? for(i=0; ihttp://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
al to add this to ISO C, then if it gets > standardised GCC will support it. We don't just as non-standard > extensions because of one pushy person sending incredibly long emails. The way ISO C seems to happen, is some compilers implement the idea as C extensions, then they see the light that it was a good idea and is popular; then hence make it a standard with a few names changed. The reason my emails are so incredibly long is, I keep on having utterly obvious truths disputed by people who ought to know better, and have to go back to basics to demonstrate their validity. It would be simpler if the utterly obvious truths I state, were just accepted as utterly obvious truths. Then there would have been a short single email. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
efore that you /can/ do function specific
> optimisation, but it is rare that you /should/ do it. And you /can/ do
> it with pragmas (for people who like pragmas), but it is better to use
> function attributes. It is better to either let the compiler figure out
> which functions need extra speed (it's getting quite good at it), or use
> more generic function attributes like "hot" and "cold".
--sounds sensible.
>> Incidentally, another annoyance in C which it'd be nice to fix, and
>> not hard to fix at
>> all, would be this:
>>int foo( int a, int b, int c, int d, double e ){
>> code
>>}
>> is silly. It would be better if we could write it as
>> int foo( int a,b,c,d; double e ){
>>}
>> getting rid of the extra type names which just waste space and serve
>> no useful function.
>
> I can't say that this bothers me at all. And it just opens new ways to
> cause confusion like:
>
> int foo(char* p, q);
>
> Is "q" a "char" or a "char*" ?
--a char* (or rather, it should be, in my view).
Anyhow I think this particular ambiguity is already present in C
for variable declarations, no?
I mean, my gripe is that variable declarations can be concise, but
in function argument lists they cannot be, which is annoyingly inconsistent
and also hits you where it hurts.
And I think conciseness is important. Not so much for saving
keystrokes but rather for reading + comprehending + checking code
faster.
> One feature of function declaration or calling that could be added to C
> to improve it (i.e., help people write clear, correct, safe, robust code
> - rather than helping people save a keystroke or two) it would be
> designated parameters. i.e., after the declaration:
>
> int foo(int a, int b, int c, int d, double e);
>
> you could call foo like this:
>
> foo(1, 2, 3, .d = 5, .e = 2.5);
> foo(.d = 5, .a = 1, .c = 3, .e = 2.5, .b = 2);
>
> // Alternative syntax
> foo(d: 5, a: 1, c: 3, e: 2.5, b: 2);
>
>
>
> and get the same effect.
--yes, that sort of feature would be nice, ada has some stuff like that.
>> --well, I have some understanding of these things.
>
> Every object in C needs to have a unique address. It is impossible to
> have the unique address of an object smaller than a "char", and the
> minimum size of a char is 8 bits. (A "_Bool" typically has 8 bits too -
> 1 value bit, and 7 padding bits.) This is fundamental to C.
--if a char has an address, then the address of a bit inside that char would be
got by appending 3 more bits.
Also, even if C were to implement packed bools but refused to allow
pointers to them, that still would be a big improvement.
--
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
>> 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. >These cover the needs of virtually everyone in virtually all cases. --a bold claim, made with zero evidence presented. But since we know that even 40 years ago, PASCAL felt the need to provide packed boolean arrays, we know that 8-64 failed to cover the needs of "virtually everyone in virtually all cases." Looks to me like you just make stuff up. My claim is: if you build it, they will come. People will like the fact that gcc provides a little more than the bare minimum it is allowed to provide. Also, I'm somewhat amazed how it is argued to me that a 9-bit machine the PDP-10 is covered by C fine, but yet, C insists on having everything a multiple of 8 bits with padding bits disallowed, and that too is fine, and both these facts refute me. Oh. I've tried to make my critics argue against themselves by giving examples where their statements contradict decisions they already made to put X into GCC, but those examples just appears to be ignored by you all. Obviously you feel that you yourselves back when you made the decision to add X, were being an idiot. Which is strange, but makes it clear it ultimately is not I who it criticizing you, it is you who are criticizing you. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
And hell, GCC already includes a lot of really really obscure builtin functions which are one hell of a lot less common & useful than multiply-hi&lo. I merely cited div(a,b) because it was one of the least obscure among them. How about freaking "isgraph" and "_mm_set1_epi32"? I mean how can you justify building them in, but not this? You cannot. And that isn't because I failed to "learn basic principles about language design." -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
It *isn't* "putting every possible feature into every language." Did I ever advocate that? It's "putting a feature that you already put there, into the language, just no longer arbitrarily selecting certain integer sizes and excluding others." Am I making syntax more complicated? No. I am if anything suggesting making it simpler by removing arbitrary rules that only complicated situation. Am I making compiler more complicated? No, the code to do this was already written (just with different numbers), and by doing what I say the compiler could actually be simplified in some ways. And no, I do not think "saving a life" worth of time is "completely meaningless." And also, it is actually C's explicit mission to be close to the machine, trying basically to provide a user-friendly portable machine-model. Given that is its design mission, it is rather absurd to disallow access to various common machine primitives like multiply-hi&lo, shift with carry, etc. Adding those would in no way complicate the overall language design, it'd just be another builtin function just like the ones you already have put in. If I told you to remove div(a,b) from GCC because it was a fairly silly complication and unnecessary feature, that'd be true, and yet you would tell me I was an idiot. If I tell you to put in mul(a,b): then it is a less-silly, more-useful, thing, which you just (see previous sentence) agreed with me was worthwhile. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
OK, you just said you've used packed nybble arrays a couple of times. Multiplying you by 100,000 that proves if you put it in GCC, you'd save 200,000 programmer hours, which is equivalent to saving over 2 lives. You just said you've written your own double-length multiply. Same proof. Thank you for proving my point. How many deaths does it take before it is worth putting into GCC? And it isn't like I'm suggesting something hard, or which would be unattractive to users. And thanks for the tip on how to do add-with-carry. That's nice. Now I have to ask, now you've helpfully demonstrated how nice it can be, why not put that niceness inside GCC? I mean, if GCC already is going to provide div(a,b) -- it was not me who asked for that, it was GCC that decided to provide it -- which I could have just got in plain C using q=a/b; r=a%b; and depended on optimizer, zero thought required -- then how can just justify GCC *not* providing addc(a,b) when it is trickier for the programmer, so you are clearly providing something more helpful since was more tricky? Why am I bothering? You prove my point then act as though you proved opposite. Concrete examples? Hell, I suggested stdint.h years and years before it came along, and I was told I was an idiot. I suggested making a lot of library functions be builtins, told I was an idiot, and now lo and behold, years and years later, gcc makes many library functions be builtins. I complained the stdio library was a disaster waiting to happen with buffer overflows, told I was an idiot, and lo and behold, years and years later people keep trying to work around that, with at least two people having written nonstandard replacement libraries to try for safety, and huge billions of dollars estimated to be lost due to this bad design. Concerning suggestions I've made that never were adopted, I would like C to have array-bounds checking available as a compiler option. Also profiling. I'd like elsif. I'd like more sophisticated compile time stuff, like right now they have #if, #elsif, #endif. Ok, why not #for? That way we could unroll loops by "doing the loop at compile time" not runtime. (Need to make a language subset intentionally weakened to not be turing complete, i.e. we want to know for sure the compile always will terminate, but still precompiler language could be a good deal more powerful than now.) I could discuss that. I'd like a compile-time language giving you a fair amount of power, but below turing-power, and acting as though it were sensibly designed in from start with similar syntax (within reason) to the actual runtime language -- not intentionally different syntax for no reason aside from trying to annoy people, and not an obvious crude add-on. I'd like different parts of my program to be optimized for space, or for speed -- I get to say for which parts I want which using pragmas. I'd like addons to support multiple entry points for routines easy, so I can make coroutines and "iterators." (This can be done with present C, but it seems a much bigger pain than it needs to be.) Pointer arithmetic is a well known disaster-waiting-to-happen in C, but of course there are compensating performance benefits... but you could get the best of both worlds with ability to declare "safe" pointers e.g. with bounds checking of them added by compiler and the bounds created when the pointer is. Such safety could be turned off with a compiler option for more speed. Point is, C arrays and pointers are very unsafe for a few reasons, but by adding some compiler options and/or language extensions to allow adding safe versions of that stuff, GCC could make it a lot easier on programmers to get a lot safer with near zero effort. But hey, nearly all those ideas actually require work, meanwhile I think uint4_t is nearly trivial by comparison. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Two suggestions for gcc C compiler to extend C language (by WD Smith)
To the guy who falsely claimed MIPS fails to provide an add with carry instruction, a google search in 1 minute finds this: stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly I defy you to find any processor not providing add with carry, (And I'm not talking about semantic bullshit. MIPS provides add with carry, even if they do not call it that, as this answer shows.) Now it might be I'm wrong and some computers now not providing it. If so, that is world damage caused by GCC. How so? Simple. Code out there is written on C. Processor designers observe real world code. "Aha!" They say. "Real word code hardly ever seems to use add-with-carry! I guess we should eliminate it!" If and when that happens it is a disaster, and the direct cause of that disaster, was the laziness of writers of such things as GCC. They cripple the programmer, then the hardware guys say "aha! programmers are crippled! That proves they like being crippled!" OK? So it is not merely that you are providing a bad product, it is worse (if you are right about this) -- actually damaging the world. Now as my critic said (it is amazing the absurd lengths people will go to to pretend fossilized crud was a "good decision") a purpose of languages like C is to provide a nice set of portable abstractions. Well, add with carry IS a nice portable abstraction. So is multiply Nwide*Nwide --> 2Nwide. And as some other critic said, languages have different purposes, and PASCAL may have had different purposes than C. As usual for my critics, again this was confused, because it was an explicit goal of C to get close to the machine. That was not so much a goal of PASCAL. It was a goal of C. That means it is absurd for C to refuse to provide packed boolean arrays while PASCAL does, and also while C already has made uintN_t types for various N. Also, I believe the original machine was a PDP-9 not PDP-11, not that it matters. Look, I could go on. But this is getting silly. Basically, what happens is 1. compiler/language guys do a bad job. 2. others point it out. 3. CLGs then pretend it was a good decision made by very very wise minds for mysterious unknown reasons nobody can explain, or just make shit up, or complain anybody pointing it out is rude, or mumble about different goals of different languages, or invent ludicrous arguments to "justify" situation, or argue anybody could implement it themselves because language is Turing complete, so no need. 4. The real reason they are doing (3) is simple: they are lazy. 5. Pointing our their laziness and incompetence is "rude." But due to the always-response of type 3 made by the CLGs to any suggestion whatever, there is no other alternative, is there? You are forcing it upon me, aren't you? 6. Years and years later eventually the CLGs do the right thing, always pretending it was their own idea and that they'd never said it was idiotic to do it. I just wish this process could be shortcut. Now look. I'm actually willing to write you code to do the things I suggested, e.g. implement packed nybble arrays in C. It will do it with cruddy syntax, but it'll work and pretty efficiently. I'd also be willing to write some assembler patches to implement, e.g. double-length multiply. These will not be a compiler. They will rather, be the sort of annoying workarounds programmers like me have to do all the time, to get around the fact that the compiler and language try to prevent you from doing them. But the thing is, I'm not willing to write that stuff for you unless you promise to actually add these things to GCC. So, will anybody make that promise? -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
--mind-boggling. So they actually intentionally made the language worse in the C11 TC3 revision versus the C99 standard. Sigh. It's really hard to get compiler and language guys to do anything. I suggest the most stunningly obvious idea, they tell me I am an idiot. Then years and years later, they do what I suggested, forgetting entirely that I suggested it and forgetting that it was an idiotic idea. This has happened to me many times. If I were to suggest undoing my (later adopted) "idiotic" suggestion now, those exact same people would undoubtably again tell me I am an idiot. There is absolutely no good reason why things have to be *legislated* to be an integer number of bytes. They could be single bits. It would be fine. PASCAL already provided it 40 years ago. If you wanted to make a packed array of 63 bools, you could pad it up to 64 to fit it in an integer number of bytes. I'd be ok with that. I'm not ok with gratuitously wasting a factor of 8 in memory and/or forcing programmers to do lots more work and use cruddy syntax, merely because the compiler writers were too lazy to just change a few numbers in their code. They make bad decisions then fossilize them. And it is an absolute outrage that every processor in the universe provides "add with carry" but the C language insists on preventing you from accessing that, while providing a way to access combined divide & remainder instead. It is simply not a justifiable decision. You can lead a horse to water... -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 7/26/16, Joseph Myers wrote: > On Tue, 26 Jul 2016, Warren D Smith wrote: > >> (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.) > > Only sizes which are an integer number of bytes with no padding bits. wikipedia: "The C99 standard includes definitions of several new integer types to enhance the portability of programs.[2] The already available basic integer types were deemed insufficient, because their actual sizes are implementation defined and may vary across different systems... All new types are defined in header (cinttypes header in C++) and also are available at header (cstdint header in C++). The types can be grouped into the following categories: * Exact-width integer types which are guaranteed to have the same number N of bits across all implementations. Included only if it is available in the implementation..." This wikipedia page nowhere says it must be an integer number of bytes with no padding. And you will notice they *intentionally* chose to name them int8_t meaning 8 BITs wide, and *not* meaning 8 BYTEs wide, intentionally choosing those names presumably because they wanted to permit sizes not a multiple of 8. And they said "only if available in implementation" which gcc chose to interpret as "we're not going to make other sizes available, hahahaha." But gcc could choose to get ahead of the other compilers, leading not following, by making them available. If you were really ambitious you could provide int7_t etc (w.g. all integer sizes up to 64) but I am not asking for that level of ambition. I am asking merely for the easy sizes 1, 2 and 4 which you plainly have already written the code to do, just change some numbers. You are free to attack the standards bodies as being idiots. But they weren't being idiots in this decision.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 7/26/16, Jonathan Wakely 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 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 ava
Two suggestions for gcc C compiler to extend C language (by WD Smith)
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, e.g. an array of 1000 bools takes 8000 bits, which is asinine and kind of defeats the point. I suggest adding uint1_t, uint2_t and uint4_t support to gcc, and packed. 128 would be nice too. It is obnoxious and arbitrary that only 8,16,32,64 are available, and it is a pain to make programmers continually have to reinvent the wheel to implement packed nybbles, etc -- and even when I do so, then my implementation results in ugly code, different than the nice-looking code for packed bytes. Why not allow me to write uniform code? Why not catch up to freaking PASCAL from 40 years ago, which already provided packed arrays? This ought to be pretty trivial given that you already did 8,16,32,64 to do 1,2,4 also. 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. However, why not provide access to double-precision multiply and add-with-carry (subtract with borrow? shift-left?) in the same fashion? twofer x = mul(a,b); would cause x.hi and x.lo to be computed. twofer x = addwithcarry(a,b) ditto. It is frustrating and arbitrary that gcc only does this for division and not anything else. It also is just plain stupid! -- because the C language already provided % and / operators, and gcc's optimizer could presumably recognize whenever anybody was computing both a%b and a/b, and then combine them when generating code. Hence the div(a,b) really was not even necessary for gcc to provide at all, if it had a good enough optimizer+recognizer. But mul(a,b) and add_with_carry really ARE necessary because they are NOT available in C language already and CANNOT be recognized/optimized -- at least not without a rather ridiculous level of cleverness to recognize it whenever I implement double-length multiply in some slow ugly manner as a workaround to overcome this stupidity (there are many possible ways to implement it, so not much hope gcc could recognize them all). -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
