This is the epitome, the climax, the crux, the ultimate, the holy grail, the crème de la crème of nerd sniping.
fuckin bravo
NL807 2 hours ago [-]
Love it
pjdesno 2 hours ago [-]
During an internship in 1986 I wrote C code for a machine with 10-bit bytes, the BBN C/70. It was a horrible experience, and the existence of the machine in the first place was due to a cosmic accident of the negative kind.
aldanor 43 seconds ago [-]
10-bit arithmetics are actually not uncommon on fpgas these days and are used in production in relatively modern applications.
10-bit C, however, ..........
csours 2 hours ago [-]
Somehow this machine found its way onto The Heart of Gold in a highly improbable chain of events.
Taniwha 1 hours ago [-]
I've worked on a machine with 9-bit bytes (and 81-bit instructions) and others with 6-bit ones - nether has a C compiler
asveikau 14 minutes ago [-]
I think the pdp-10 could have 9 bit bytes, depending on decisions you made in the compiler. I notice it's hard to Google information about this though. People say lots of confusing, conflicting things. When I google pdp-10 byte size it says a c++ compiler chose to represent char as 36 bits.
WalterBright 2 hours ago [-]
I programmed the Intel Intellivision cpu which had a 10 bit "decl". A wacky machine. It wasn't powerful enough for C.
WalterBright 1 hours ago [-]
D made a great leap forward with the following:
1. bytes are 8 bits
2. shorts are 16 bits
3. ints are 32 bits
4. longs are 64 bits
5. arithmetic is 2's complement
6. IEEE floating point
and a big chunk of wasted time trying to abstract these away and getting it wrong anyway was saved. Millions of people cried out in relief!
Oh, and Unicode was the character set. Not EBCDIC, RADIX-50, etc.
cogman10 38 minutes ago [-]
Yeah, this is something Java got right as well. It got "unsigned" wrong, but it got standardizing primitive bits correct
byte = 8 bits
short = 16
int = 32
long = 64
float = 32 bit IEEE
double = 64 bit IEEE
jltsiren 26 minutes ago [-]
I like the Rust approach more: usize/isize are the native integer types, and with every other numeric type, you have to mention the size explicitly.
On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the assumption is worth making.
Jerrrrrrry 6 minutes ago [-]
hindsight has its advantages
josephg 17 minutes ago [-]
Yep. Pity about getting chars / string encoding wrong though. (Java chars are 16 bits).
But it’s not alone in that mistake. All the languages invented in that era made the same mistake. (C#, JavaScript, etc).
paragraft 6 minutes ago [-]
What's the right way?
gerdesj 50 minutes ago [-]
"1. bytes are 8 bits"
How big is a bit?
CoastalCoder 5 minutes ago [-]
> How big is a bit?
A quarter nybble.
poincaredisk 20 minutes ago [-]
A bit is either a 0 or 1. A byte is the smallest addressable piece of memory in your architecture.
Nevermark 15 seconds ago [-]
Which … if your heap always returns N bit aligned values, for some N … is there a name for that? The smallest heap addressable segment?
elromulous 4 minutes ago [-]
Technically the smallest addressable piece of memory is a word.
Me? I just dabble with documenting an unimplemented "50% more bits per byte than the competition!" 12-bit fantasy console of my own invention - replete with inventions such as "UTF-12" - for shits and giggles.
jeffbee 2 hours ago [-]
They can just target C++23 or earlier, right? I have a small collection of SHARCs but I am not going to go crying to the committee if they make C++30 (or whatever) not support CHAR_BIT=32
PaulDavisThe1st 2 hours ago [-]
no doubt you've got your brainfuck compiler hard at work on this ...
harry8 2 hours ago [-]
Is C++ capable of deprecating or simplifying anything?
Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated.
Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"
epcoa 2 hours ago [-]
Signed integers did not have to be 2’s complement, there were 3 valid representations: signed mag, 1s and 2s complement. Modern C and C++ dropped this and mandate 2s complement (“as if” but that distinction is moot here, you can do the same for CHAR_BIT). So there is certainly precedence for this sort of thing.
hyperhello 1 hours ago [-]
C++ long ago crossed the line where making any change is more work than any benefit it could ever create.
mrpippy 41 minutes ago [-]
C++17 removed trigraphs
poincaredisk 18 minutes ago [-]
Which was quite controversial. Imagine that.
nialv7 2 hours ago [-]
well they managed to get two's complement requirement into C++20. there is always hope.
oefrha 49 minutes ago [-]
Well then someone somewhere with some mainframe got so angry they decided to write a manifesto to condemn kids these days and announced a fork of Qt because Qt committed the cardinal sin of adopting C++20. So don’t say “a problem literally nobody has”, someone always has a use case; although at some point it’s okay to make a decision to ignore them.
> because Qt committed the carnal sin of adopting C++20
I do believe you meant to write "cardinal sin," good sir. Unless Qt has not only become sentient but also corporeal when I wasn't looking and gotten close and personal with the C++ standard...
bawolff 15 minutes ago [-]
> We can find vestigial support, for example GCC dropped dsp16xx in 2004, and 1750a in 2002.
Honestly kind of surprised it was relavent as late as 2004. I thought the era of non 8-bit bytes was like 1970s or earlier.
TrueDuality 3 hours ago [-]
This is both uncontroversial and incredibly spicy. I love it.
kreco 2 hours ago [-]
I'm totally fine with enforcing that int8_t == char == 8-bits, however I'm not sure about spreading the misconception that a byte is 8-bits. A byte with 8-bits is called an octet.
At the same time, a `byte` is already an "alias" for `char` since C++17 anyway[1].
Possible, but likely slow. There's nothing in the "C abstract machine" that mandates specific hardware. But, the bitshift is only a fast operation when you have bits. Similarly with bitwise boolean operations.
cogman10 32 minutes ago [-]
It'd just be a translation/compiler problem. Most languages don't really have a "bit", instead it's usually a byte with the upper bits ignored.
bobmcnamara 2 hours ago [-]
I just put static_assert(CHAR_BITS==8); in one place and move on. Haven't had it fire since it was #if equivalent
donatj 2 hours ago [-]
So please do excuse my ignorance, but is there a "logic" related reason other than hardware cost limitations ala "8 was cheaper than 10 for the same number of memory addresses" that bytes are 8 bits instead of 10? Genuinely curious, as a high-level dev of twenty years, I don't know why 8 was selected.
To my naive eye, It seems like moving to 10 bits per byte would be both logical and make learning the trade just a little bit easier?
morio 2 hours ago [-]
One example from the software side: A common thing to do in data processing is to obtain bit offsets (compression, video decoding etc.). If a byte would be 10 bits you would need mod%10 operations everywhere which is slow and/or complex. In contrast mod%(2^N) is one logic processor instruction.
bryanlarsen 2 hours ago [-]
I'm fairly sure it's because the English character set fits nicely into a byte. 7 bits would have have worked as well, but 7 is a very odd width for something in a binary computer.
dplavery92 2 hours ago [-]
Eight is a nice power of two.
donatj 2 hours ago [-]
Can you explain how that's helpful? I'm not being obtuse, I just don't follow
spongebobstoes 2 hours ago [-]
One thought is that it's always a whole number of bits (3) to bit-address within a byte. It's 3.5 bits to bit address a 10 bit byte. Sorta just works out nicer in general to have powers of 2 when working on base 2.
cogman10 23 minutes ago [-]
This is basically the reason.
Another part of it is the fact that it's a lot easier to represent stuff with hex if the bytes line up.
I can represent "255" with "0xFF" which fits nice and neat in 1 byte. However, now if a byte is 10bits that hex no longer really works. You have 1024 values to represent. The max value would be 0x3FF which just looks funky.
Coming up with an alphanumeric system to represent 2^10 cleanly just ends up weird and unintuitive.
davemp 53 minutes ago [-]
Many circuits have ceil(log_2(N_bits)) scaling wrt to propagation delay/other dimensions so you’re just leaving efficiency on the table if you aren’t using a power of 2 for your bit size.
bonzini 2 hours ago [-]
It's easier to go from a bit number to (byte, bit) if you don't have to divide by 10.
inkyoto 1 hours ago [-]
Because modern computing has settled on the Boolean (binary) logic (0/1 or true/false) in the chip design, which has given us 8 bit bytes (a power of two). It is the easiest and most reliable to design and implement in the hardware.
On the other hand, if computing settled on a three-valued logic (e.g. 0/1/«something» where «something» has been proposed as -1, «undefined»/«unknown»/«undecided» or a «shade of grey»), we would have had 9 bit bytes (a power of three).
10 was tried numerous times at the dawn of computing and… it was found too unwieldy in the circuit design.
davemp 38 minutes ago [-]
> On the other hand, if computing settled on a three-valued logic (e.g. 0/1/«something» where «something» has been proposed as -1, «undefined»/«unknown/undecided» or a «shade of grey»), we would have had 9 bit bytes (a power of three).
Is this true? 4 ternary bits give you really convenient base 12 which has a lot of desirable properties for things like multiplication and fixed point. Though I have no idea what ternary building blocks would look like so it’s hard to visualize potential hardware.
inkyoto 4 minutes ago [-]
It is hard to say whether it would have been 9 or 12, now that people have stopped experimenting with alternative hardware designs. 9-bit byte designs certainly did exist (and maybe even the 12-bit designs), too, although they were still based on the Boolean logic.
I have certainly heard an argument that ternary logic would have been a better choice, if it won over, but it is history now, and we are left with the vestiges of the ternary logic in SQL (NULL values which are semantically «no value» / «undefined» values).
zamadatix 2 hours ago [-]
If you're ignoring what's efficient to use then just use a decimal data type and let the hardware figure out how to calculate that for you best. If what's efficient matters then address management, hardware operation implementations, and data packing are all simplest when the group size is a power of the base.
knome 2 hours ago [-]
likely mostly as a concession to ASCII in the end. you used a typewriter to write into and receive terminal output from machines back in the day. terminals would use ASCII. there were machines with all sorts of smallest-addressable-sizes, but eight bit bytes align nicely with ASCII. makes strings easier. making strings easier makes programming easier. easier programming makes a machine more popular. once machines started standardizing on eight bit bytes, others followed. when they went to add more data, they kept the byte since code was written for bytes, and made their new registeres two bytes. then two of those. then two of those. so we're sitting at 64 bit registers on the backs of all that that came before.
wvenable 2 hours ago [-]
I'm not sure why you think being able to store values from -512 to +511 is more logical than -128 to +127?
donatj 2 hours ago [-]
Buckets of 10 seem more regular to beings with 10 fingers that can be up or down?
wvenable 2 hours ago [-]
I think 8bits (really 7 bits) was chosen because it holds a value closest to +/- 100. What is regular just depends on how you look at it.
JamesStuff 3 hours ago [-]
Not sure about that, seems pretty controversial to me. Are we forgetting about the UNIVACs?
omoikane 1 hours ago [-]
This would be a great setup for a time travelling science fiction where there is some legacy UNIVAC software that needs to be debugged, and John Titor, instead of looking for an IBM 5100, came back to the year 2024 to find a pre-P3477R0 compiler.
trebligdivad 3 hours ago [-]
Hopefully we are; it's been a long time, but as I remember indexing in strings on them is a disaster.
Animats 2 hours ago [-]
They still exist. You can still run OS 2200 on a Clearpath Dorado.[1] Although it's actually Intel Xeon processors doing an emulation.
Yes, indexing strings of 6-bit FIELDATA characters was a huge headache. UNIVAC had the unfortunate problem of having to settle on a character code in the early 1960s, before ASCII was standardized. At the time, a military 6-bit character set looked like the next big thing. It was better than IBM's code, which mapped to punch card holes and the letters weren't all in one block.
idk. by today most software already assumes 8 bit == byte in subtle ways all over the place to a point you kinda have to use a fully custom or at least fully self reviewed and patched stack of C libraries
so delegating such by now very very edge cases to non standard C seems fine, i.e. seems to IMHO not change much at all in practice
and C/C++ compilers are anyway full of non standard extensions and it's not that CHAR_BIT go away or you as a non-standard extension assume it might not be 8
II2II 2 hours ago [-]
> most software already assumes 8 bit == byte in subtle ways all over the place
Which is the real reason why 8-bits should be adopted as the standard byte size.
I didn't even realize that the byte was defined as anything other than 8-bits until recently. I have known, for decades, that there were non-8-bit character encodings (including ASCII) and word sizes were all over the map (including some where word size % 8 != 0). Enough thought about that last point should have helped me realize that there were machines where the byte was not 8-bits, yet the rarity of encountering such systems left me with the incorrect notion that a byte was defined as 8-bits.
Now if someone with enough background to figure it out doesn't figure it out, how can someone without that background figure it out? Someone who has only experienced systems with 8-bit bytes. Someone who has only read books that make the explicit assumption of 8-bit bytes (which virtually every book does). Anything they write has the potential of breaking on systems with a different byte size. The idea of writing portable code because the compiler itself is "standards compliant" breaks down. You probably should modify the standard to ensure the code remains portable by either forcing the compiler for non-8-bit systems to handle the exceptions, or simply admitting that compiler does not portable code for non-8-bit systems.
forrestthewoods 2 hours ago [-]
Do UNIVACs care about modern C++ compilers? Do modern C++ compilers care about UNIVACs?
Given that Wikipedia says UNIVAC was discontinued in 1986 I’m pretty sure the answer is no and no!
skissane 2 hours ago [-]
The UNIVAC 1108 (and descendants) mainframe architecture was not discontinued in 1986. The company that owned it (Sperry) merged with Burroughs in that year to form Unisys. The platform still exists, but now runs as a software emulator under x86-64. The OS is still maintained and had a new release just last year. Around the time of the merger the old school name “UNIVAC” was retired in a rebranding, but the platform survived.
Its OS, OS 2200, does have a C compiler. Not sure if there ever was a C++ compiler, if there once was it is no longer around. But that C compiler is not being kept up to date with the latest standards, it only officially supports C89/C90 - this is a deeply legacy system, most application software is written in COBOL and the OS itself itself is mainly written in assembler and a proprietary Pascal-like language called “PLUS”. They might add some features from newer standards if particularly valuable, but formal compliance with C99/C11/C17/C23/etc is not a goal.
The OS does contain components written in C++, most notably the HotSpot JVM. However, from what I understand, the JVM actually runs in x86-64 Linux processes on the host system, outside of the emulated mainframe environment, but the mainframe emulator is integrated with those Linux processes so they can access mainframe files/data/apps.
MrLeap 12 minutes ago [-]
How many bytes is a devour?
throwaway889900 3 hours ago [-]
But how many bytes are there in a word?
o11c 3 hours ago [-]
If you're on x86, the answer can be simultaneously 16, 32, and 64.
wvenable 3 hours ago [-]
"Word" is an outdated concept we should try to get rid of.
anigbrowl 2 hours ago [-]
You're right. To be consistent with bytes we should call it a snack.
SCUSKU 2 hours ago [-]
Henceforth, it follows that a doublesnack is called a lunch. And a quadruplesnack a fourthmeal.
tetron 2 hours ago [-]
There's only one right answer:
Nybble - 4 bits
Byte - 8 bits
Snyack - 16 bits
Lyunch - 32 bits
Dynner - 64 bits
cozzyd 9 minutes ago [-]
And what about elevensies?
(Ok,. I guess there's a difference between bits and hob-bits)
iwaztomack 2 hours ago [-]
or an f-word
pclmulqdq 2 hours ago [-]
It's very useful on hardware that is not an x86 CPU.
wvenable 2 hours ago [-]
As an abstraction on the size of a CPU register, it really turned out to be more confusing than useful.
pclmulqdq 2 hours ago [-]
On RISC machines, it can be very useful to have the concept of "words," because that indicates things about how the computer loads and stores data, as well as the native instruction size. In DSPs and custom hardware, it can indicate the only available datatype.
The land of x86 goes to great pains to eliminate the concept of a word at a silicon cost.
o11c 2 hours ago [-]
Fortunately we have `register_t` these days.
bobmcnamara 2 hours ago [-]
Is it 32 or 64 bits on ARM64? Why not both?
iwaztomack 2 hours ago [-]
such as...?
BlueTemplar 2 hours ago [-]
How exactly ? How else do you suggest CPUs do addressing ?
Or are you suggesting to increase the size of a byte until it's the same size as a word, and merge both concepts ?
wvenable 2 hours ago [-]
I'm saying the term "Word" abstracting the number of bytes a CPU can process in a single operation is an outdated concept. We don't really talk about word-sized values anymore. Instead we mostly explicit on the size of value in bits. Even the idea of a CPU having just one relevant word size is a bit outdated.
I've seen 6 8-bit characters/word (Burroughs large systems, they also support 8 6-bit characters/word)
aj7 2 hours ago [-]
And then we lose communication with Europa Clipper.
masfuerte 2 hours ago [-]
This is entertaining and probably a good idea but the justification is very abstract.
Specifically, has there even been a C++ compiler on a system where bytes weren't 8 bits? If so, when was it last updated?
bryanlarsen 2 hours ago [-]
There were/are C++ compilers for PDP-10 (9 bit byte). Those haven't been maintained AFAICT, but there are C++ compilers for various DSP's where the smallest unit of access is 16 or 32 bits that are still being sold.
userbinator 2 hours ago [-]
I know some DSPs have 24-bit "bytes", and there are C compilers available for them.
whatsakandr 1 hours ago [-]
Hoesntly at thought this might be an onion headline. But then I stopped to think about it.
hexo 2 hours ago [-]
Why? Pls no. We've been told (in school!) that byte is byte. Its only sometimes 8bits long (ok, most of the time these days). Do not destroy the last bits of fun.
Is network order little endian too?
thfuran 11 minutes ago [-]
Heretic, do not defile the last remnants of true order!
bbkane 2 hours ago [-]
I think there's plenty of fun left in the standard if they remove this :)
DowsingSpoon 2 hours ago [-]
As a person who designed and built a hobby CPU with a sixteen-bit byte, I’m not sure how I feel about this proposal.
gafferongames 2 hours ago [-]
Amazing stuff guys. Bravo.
starik36 2 hours ago [-]
There are FOUR bits.
Jean-Luc Picard
scosman 2 hours ago [-]
Bold leadership
adamnemecek 2 hours ago [-]
Incredible things are happening in the C++ community.
cyberax 3 hours ago [-]
But think of ternary computers!
dathinab 3 hours ago [-]
Doesn't matter ternary computers just have ternary bits, 8 of them ;)
mathgenius 2 hours ago [-]
Ternary computers have 8 tits to a byte.
tbrownaw 2 hours ago [-]
Should be either 9 or 27 I'd think.
epcoa 2 hours ago [-]
Why can’t it be 8?, the fact that it’s a trit doesn’t put any constraint on the byte (tryte ? size). You could actually make it 5 or 6 trits (~9.5 bits) for similar information density. The Setun used 6 trit addressable units.
AStonesThrow 2 hours ago [-]
Supposedly, "bit" is short for "binary digit", so we'd need a separate term for "ternary digit", but I don't wanna go there.
epcoa 2 hours ago [-]
The prefix is tri-, not ti- so I don’t think there was any concern of going anywhere.
It’s tricycle and tripod, not ticycle.
bryanlarsen 2 hours ago [-]
The standard term is "trit" because they didn't want to go there.
Quekid5 3 hours ago [-]
JF Bastien is a legend for this, haha.
I would be amazed if there's any even remotely relevant code that deals meaningfully with CHAR_BIT != 8 these days.
(... and yes, it's about time.)
Animats 2 hours ago [-]
Here's a bit of 40 year old code I wrote which originally ran on 36-bit PDP-10 machines, but will work on non-36 bit machines.[1] It's a self-contained piece of code to check passwords for being obvious. This will detect any word in the UNIX dictionary, and most English words, using something that's vaguely like a Bloom filter.
This is so old it predates ANSI C; it's in K&R C. It used to show up on various academic sites. Now it's obsolete enough to have scrolled off Google.
I've seen copies of this on various academic sites over the years, but it seems to have finally scrolled off.
I think we can dispense with non 8-bit bytes at this point.
DSP chips are a common exception that people bring up. I think some TI made ones have 64 bit chars.
Edit: I see TFA mentions them but questions how relevant C++ is in that sort of embedded environment.
Quekid5 2 hours ago [-]
Yes, but you're already in specialized territory if you're using that
nullc 3 hours ago [-]
The tms320c28x DSPs have 16 bit char, so e.g. the Opus audio codec codebase works with 16-bit char (or at least it did at one point -- I wouldn't be shocked if it broke from time to time, since I don't think anyone runs regression tests on such a platform).
For some DSP-ish sort of processors I think it doesn't make sense to have addressability at char level, and the gates to support it would be better spent on better 16 and 32 bit multipliers. ::shrugs::
I feel kind of ambivalent about the standards proposal. We already have fixed size types. If you want/need an exact type, that already exists. The non-fixed size types set minimums and allow platforms to set larger sizes for performance reasons.
Having no fast 8-bit level access is a perfectly reasonable decision for a small DSP.
Might it be better instead to migrate many users of char to (u)int8_t?
The proposed alternative of CHAR_BIT congruent to 0 mod 8 also sounds pretty reasonable, in that it captures the existing non-8-bit char platforms and also the justification for non-8-bit char platforms (that if you're not doing much string processing but instead doing all math processing, the additional hardware for efficient 8 bit access is a total waste).
dathinab 2 hours ago [-]
I thinks it's fine to relegate non 8 bit chars to non-standard C given that a lot of software anyway assumes 8bit bytes already implicitly. Non standard extensions for certain use-cases isn't anything new for C compilers. Also it's a C++ proposal I'm not sure if you program DSPs with C++ :think:
bmitc 2 hours ago [-]
Ignoring this C++ proposal, especially because C and C++ seem like a complete nightmare when it comes to this stuff, I've almost gotten into the habit of treating a "byte" as a conceptual concept. Many serial protocols will often define a "byte", and it might be 7, 8, 9, 11, 12, or whatever bits long.
AlienRobot 2 hours ago [-]
I wish I knew what a 9 bit byte means.
One fun fact I found the other day: ASCII is 7 bits, but when it was used with punch cards there was an 8th bit to make sure you didn't punch the wrong number of holes. https://rabbit.eng.miami.edu/info/ascii.html
Animats 2 hours ago [-]
A 9-bit byte is found on 36-bit machines in quarter-word mode.
Parity is for paper tape, not punched cards. Paper tape parity was never standardized. Nor was parity for 8-bit ASCII communications. Which is why there were devices with settings for EVEN, ODD, ZERO, and ONE for the 8th bit.
Punched cards have their very own encodings, only of historical interest.
AlienRobot 42 minutes ago [-]
>A 9-bit byte is found on 36-bit machines in quarter-word mode.
I've only programmed in high level programming languages in 8-bit-byte machines. I can't understand what you mean by this sentence.
So in a 36-bit CPU a word is 36 bits. And a byte isn't a word. But what is a word and how does it differ from a byte?
If you asked me what 32-bit/64-bit means in a CPU, I'd say it's how large memory addresses can be. Is that true for 36-bit CPUs or does it mean something else? If it's something else, then that means 64-bit isn't the "word" of a 64-bit CPU, so what would the word be?
This is all very confusing.
CephalopodMD 2 hours ago [-]
Obviously
38 2 hours ago [-]
the fact that this isn't already done after all these years is one of the reasons why I no longer use C/C++. it takes years and years to get anything done, even the tiniest, most obvious drama free changes. contrast with Go, which has had this since version 1, in 2012:
fgetc(3) and its companions always return character-by-character input as an int, and the reason is that EOF is represented as -1. An unsigned char is unable to represent EOF. If you're using the wrong return value, you'll never detect this condition.
However, if you don't receive an EOF, then it should be perfectly fine to cast the value to unsigned char without loss of precision.
electricdreams 3 hours ago [-]
[dead]
Rendered at 02:00:42 GMT+0000 (Coordinated Universal Time) with Vercel.
https://github.com/torvalds/linux/blob/master/include/math-e...
I found this snapshot of it, though it's not on the real Dilbert site: https://www.reddit.com/r/linux/comments/73in9/computer_holy_...
fuckin bravo
10-bit C, however, ..........
1. bytes are 8 bits
2. shorts are 16 bits
3. ints are 32 bits
4. longs are 64 bits
5. arithmetic is 2's complement
6. IEEE floating point
and a big chunk of wasted time trying to abstract these away and getting it wrong anyway was saved. Millions of people cried out in relief!
Oh, and Unicode was the character set. Not EBCDIC, RADIX-50, etc.
byte = 8 bits
short = 16
int = 32
long = 64
float = 32 bit IEEE
double = 64 bit IEEE
On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the assumption is worth making.
But it’s not alone in that mistake. All the languages invented in that era made the same mistake. (C#, JavaScript, etc).
How big is a bit?
A quarter nybble.
https://thephd.dev/conformance-should-mean-something-fputc-a...
Me? I just dabble with documenting an unimplemented "50% more bits per byte than the competition!" 12-bit fantasy console of my own invention - replete with inventions such as "UTF-12" - for shits and giggles.
Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated.
Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"
https://lscs-software.com/LsCs-Manifesto.html
https://news.ycombinator.com/item?id=41614949
Edit: Fixed typo pointed out by child.
I do believe you meant to write "cardinal sin," good sir. Unless Qt has not only become sentient but also corporeal when I wasn't looking and gotten close and personal with the C++ standard...
Honestly kind of surprised it was relavent as late as 2004. I thought the era of non 8-bit bytes was like 1970s or earlier.
At the same time, a `byte` is already an "alias" for `char` since C++17 anyway[1].
[1] https://en.cppreference.com/w/cpp/types/byte
std::cout << (int8_t)32 << std::endl; //should print 32 dang it
https://en.wikipedia.org/wiki/Ternary_computer
To my naive eye, It seems like moving to 10 bits per byte would be both logical and make learning the trade just a little bit easier?
Another part of it is the fact that it's a lot easier to represent stuff with hex if the bytes line up.
I can represent "255" with "0xFF" which fits nice and neat in 1 byte. However, now if a byte is 10bits that hex no longer really works. You have 1024 values to represent. The max value would be 0x3FF which just looks funky.
Coming up with an alphanumeric system to represent 2^10 cleanly just ends up weird and unintuitive.
On the other hand, if computing settled on a three-valued logic (e.g. 0/1/«something» where «something» has been proposed as -1, «undefined»/«unknown»/«undecided» or a «shade of grey»), we would have had 9 bit bytes (a power of three).
10 was tried numerous times at the dawn of computing and… it was found too unwieldy in the circuit design.
Is this true? 4 ternary bits give you really convenient base 12 which has a lot of desirable properties for things like multiplication and fixed point. Though I have no idea what ternary building blocks would look like so it’s hard to visualize potential hardware.
I have certainly heard an argument that ternary logic would have been a better choice, if it won over, but it is history now, and we are left with the vestiges of the ternary logic in SQL (NULL values which are semantically «no value» / «undefined» values).
Yes, indexing strings of 6-bit FIELDATA characters was a huge headache. UNIVAC had the unfortunate problem of having to settle on a character code in the early 1960s, before ASCII was standardized. At the time, a military 6-bit character set looked like the next big thing. It was better than IBM's code, which mapped to punch card holes and the letters weren't all in one block.
[1] https://www.unisys.com/siteassets/collateral/info-sheets/inf...
so delegating such by now very very edge cases to non standard C seems fine, i.e. seems to IMHO not change much at all in practice
and C/C++ compilers are anyway full of non standard extensions and it's not that CHAR_BIT go away or you as a non-standard extension assume it might not be 8
Which is the real reason why 8-bits should be adopted as the standard byte size.
I didn't even realize that the byte was defined as anything other than 8-bits until recently. I have known, for decades, that there were non-8-bit character encodings (including ASCII) and word sizes were all over the map (including some where word size % 8 != 0). Enough thought about that last point should have helped me realize that there were machines where the byte was not 8-bits, yet the rarity of encountering such systems left me with the incorrect notion that a byte was defined as 8-bits.
Now if someone with enough background to figure it out doesn't figure it out, how can someone without that background figure it out? Someone who has only experienced systems with 8-bit bytes. Someone who has only read books that make the explicit assumption of 8-bit bytes (which virtually every book does). Anything they write has the potential of breaking on systems with a different byte size. The idea of writing portable code because the compiler itself is "standards compliant" breaks down. You probably should modify the standard to ensure the code remains portable by either forcing the compiler for non-8-bit systems to handle the exceptions, or simply admitting that compiler does not portable code for non-8-bit systems.
Given that Wikipedia says UNIVAC was discontinued in 1986 I’m pretty sure the answer is no and no!
Its OS, OS 2200, does have a C compiler. Not sure if there ever was a C++ compiler, if there once was it is no longer around. But that C compiler is not being kept up to date with the latest standards, it only officially supports C89/C90 - this is a deeply legacy system, most application software is written in COBOL and the OS itself itself is mainly written in assembler and a proprietary Pascal-like language called “PLUS”. They might add some features from newer standards if particularly valuable, but formal compliance with C99/C11/C17/C23/etc is not a goal.
The OS does contain components written in C++, most notably the HotSpot JVM. However, from what I understand, the JVM actually runs in x86-64 Linux processes on the host system, outside of the emulated mainframe environment, but the mainframe emulator is integrated with those Linux processes so they can access mainframe files/data/apps.
Nybble - 4 bits
Byte - 8 bits
Snyack - 16 bits
Lyunch - 32 bits
Dynner - 64 bits
(Ok,. I guess there's a difference between bits and hob-bits)
The land of x86 goes to great pains to eliminate the concept of a word at a silicon cost.
Or are you suggesting to increase the size of a byte until it's the same size as a word, and merge both concepts ?
Specifically, has there even been a C++ compiler on a system where bytes weren't 8 bits? If so, when was it last updated?
Jean-Luc Picard
It’s tricycle and tripod, not ticycle.
I would be amazed if there's any even remotely relevant code that deals meaningfully with CHAR_BIT != 8 these days.
(... and yes, it's about time.)
This is so old it predates ANSI C; it's in K&R C. It used to show up on various academic sites. Now it's obsolete enough to have scrolled off Google. I've seen copies of this on various academic sites over the years, but it seems to have finally scrolled off.
I think we can dispense with non 8-bit bytes at this point.
[1] https://animats.com/source/obvious/obvious.c
Edit: I see TFA mentions them but questions how relevant C++ is in that sort of embedded environment.
For some DSP-ish sort of processors I think it doesn't make sense to have addressability at char level, and the gates to support it would be better spent on better 16 and 32 bit multipliers. ::shrugs::
I feel kind of ambivalent about the standards proposal. We already have fixed size types. If you want/need an exact type, that already exists. The non-fixed size types set minimums and allow platforms to set larger sizes for performance reasons.
Having no fast 8-bit level access is a perfectly reasonable decision for a small DSP.
Might it be better instead to migrate many users of char to (u)int8_t?
The proposed alternative of CHAR_BIT congruent to 0 mod 8 also sounds pretty reasonable, in that it captures the existing non-8-bit char platforms and also the justification for non-8-bit char platforms (that if you're not doing much string processing but instead doing all math processing, the additional hardware for efficient 8 bit access is a total waste).
One fun fact I found the other day: ASCII is 7 bits, but when it was used with punch cards there was an 8th bit to make sure you didn't punch the wrong number of holes. https://rabbit.eng.miami.edu/info/ascii.html
Parity is for paper tape, not punched cards. Paper tape parity was never standardized. Nor was parity for 8-bit ASCII communications. Which is why there were devices with settings for EVEN, ODD, ZERO, and ONE for the 8th bit.
Punched cards have their very own encodings, only of historical interest.
I've only programmed in high level programming languages in 8-bit-byte machines. I can't understand what you mean by this sentence.
So in a 36-bit CPU a word is 36 bits. And a byte isn't a word. But what is a word and how does it differ from a byte?
If you asked me what 32-bit/64-bit means in a CPU, I'd say it's how large memory addresses can be. Is that true for 36-bit CPUs or does it mean something else? If it's something else, then that means 64-bit isn't the "word" of a 64-bit CPU, so what would the word be?
This is all very confusing.
https://pkg.go.dev/builtin@go1#byte
https://man7.org/linux/man-pages/man3/fgetc.3.html
fgetc(3) and its companions always return character-by-character input as an int, and the reason is that EOF is represented as -1. An unsigned char is unable to represent EOF. If you're using the wrong return value, you'll never detect this condition.
However, if you don't receive an EOF, then it should be perfectly fine to cast the value to unsigned char without loss of precision.