This is the mail archive of the
mailing list for the GCC project.
Two suggestions for gcc C compiler to extend C language (by WD Smith)
- From: Warren D Smith <warren dot wds at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 26 Jul 2016 09:31:51 -0400
- Subject: Two suggestions for gcc C compiler to extend C language (by WD Smith)
- Authentication-results: sourceware.org; auth=none
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
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
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)