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)
