16 ms·
C++ proposal: There are exactly 8 bits in a byte
- JamesStuff 2y agoNot sure about that, seems pretty controversial to me. Are we forgetting about the UNIVACs?
- trebligdivad 2y agoHopefully we are; it's been a long time, but as I remember indexing in strings on them is a disaster.
- Animats 2y agoThey 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. [1] https://www.unisys.com/siteassets/collateral/info-sheets/info-clearpath-forward-dorado-8690.pdf https://www.unisys.com/siteassets/collateral/info-sheets/inf...
- dathinab 2y agoidk. 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 2y 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 2y agoDo 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 2y agoThe 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.
- forrestthewoods 2y agoThat would be a resounding no then. Nice. So why are we talking about an obscure and irrelevant-to-the-discussion platform? Internet comments I swear.
- pjmlp 2y agoI got curious, there is a Wikipedia page describing what languages are currently available, https://en.wikipedia.org/wiki/Unisys_OS_2200_programming_languages https://en.wikipedia.org/wiki/Unisys_OS_2200_programming_lan...
- omoikane 2y agoThis 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.
- oasisaimlessly 2y agoSteins;byte
- TrueDuality 2y agoThis is both uncontroversial and incredibly spicy. I love it.
- electricdreams 2y ago[dead]
- Quekid5 2y agoJF 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.)
- shawn_w 2y agoDSP 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 2y agoYes, but you're already in specialized territory if you're using that
- nullc 2y agoThe 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 2y agoI 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:
- throwaway889900 2y agoBut how many bytes are there in a word?
- o11c 2y agoIf you're on x86, the answer can be simultaneously 16, 32, and 64.
- wvenable 2y ago"Word" is an outdated concept we should try to get rid of.
- pclmulqdq 2y agoIt's very useful on hardware that is not an x86 CPU.
- wvenable 2y agoAs an abstraction on the size of a CPU register, it really turned out to be more confusing than useful.
- o11c 2y agoFortunately we have `register_t` these days.
- bobmcnamara 2y agoIs it 32 or 64 bits on ARM64? Why not both?
- cyberax 2y agoBut think of ternary computers!
- dathinab 2y agoDoesn't matter ternary computers just have ternary bits, 8 of them ;)
- AStonesThrow 2y agoSupposedly, "bit" is short for "binary digit", so we'd need a separate term for "ternary digit", but I don't wanna go there.
- bryanlarsen 2y agoThe standard term is "trit" because they didn't want to go there.
- epcoa 2y agoThe prefix is tri-, not ti- so I don’t think there was any concern of going anywhere. It’s tricycle and tripod, not ticycle.
- mathgenius 2y agoTernary computers have 8 tits to a byte.
- Iwan-Zotow 2y agoIn a char, not in a byte. Byte != char
- AStonesThrow 2y agoA common programming error in C is reading input as char rather than int. https://man7.org/linux/man-pages/man3/fgetc.3.html 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.
- znkr 2y agoNope: https://isocpp.org/wiki/faq/intrinsic-types#bytes-review https://isocpp.org/wiki/faq/intrinsic-types#bytes-review
- gpderetta 2y agoIn C and C++ a byte and a char are the same size by definition. Don't confuse a byte with an octet.
- pjdesno 2y agoDuring 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.
- csours 2y agoSomehow this machine found its way onto The Heart of Gold in a highly improbable chain of events.
- WalterBright 2y agoI programmed the Intel Intellivision cpu which had a 10 bit "decl". A wacky machine. It wasn't powerful enough for C.
- Taniwha 2y agoI'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 2y agoI 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.
- larsbrinkhoff 2y agoPDP-10 byte size is not fixed. Bytes can be 0 to 36 bits wide. (Sure, 0 is not very useful; still legal.) I don't think there is a C++ compiler for the PDP-10. One of the C compiler does have a 36-bit char type.
- eqvinox 2y agoDo you have any links/info on how that 0-bit byte worked? It sounds like just the right thing for a Friday afternoon read ;D
- 38 2y agothe 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: https://pkg.go.dev/builtin@go1#byte https://pkg.go.dev/builtin@go1#byte
- deleted 2y ago[deleted]
- AlexandrB 2y agoDon't worry, 20 years from now Go will also be struggling to change assumptions baked into the language in 2012.
- CephalopodMD 2y agoObviously
- AlienRobot 2y agoI 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 https://rabbit.eng.miami.edu/info/ascii.html
- Animats 2y agoA 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 2y 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.
- Animats 2y agoA word is the unit of addressing. A 36-bit machine has 36 bits of data stored at address 1, and another 36 bits at address 2, and so forth. This is inconvenient for text processing. You have to do a lot of shifting and masking. There's a bit of hardware help on some machines. UNIVAC hardware allowed accessing one-sixth of a word (6 bits), or one-quarter of a word (8 bits), or one-third of a word (12 bits), or a half of a word (18 bits). You had to select sixth-word mode (old) or quarter-word mode (new) as a machine state. Such machines are not byte-addressable. They have partial word accesses, instead. Machines have been built with 4, 8, 12, 16, 24, 32, 36, 48, 56, 60, and 64 bit word lengths. Many "scientific" computers were built with 36-bit words and a 36-bit arithmetic unit. This started with the IBM 701 (1952), although an FPU came later, and continued through the IBM 7094. The byte-oriented IBM System/360 machines replaced those, and made byte-addressable architecture the standard. UNIVAC followed along with the UNIVAC 1103 (1953), which continued through the 1103A and 1105 vacuum tube machines, the later transistorized machines 1107 and 1108, and well into the 21st century. Unisys will still sell you a 36-bit machine, although it's really an emulator running on Intel Xeon CPUs. The main argument for 36 bits was that 36-bit floats have four more bits of precision, or one more decimal digit, than 32-bit floats. 1 bit of sign, 8 bits of exponent and 27 bits of mantissa gives you a full 8 decimal digits of precision, while standard 32-bit floats with an 1 bit sign, 7-bit exponent and a 24 bit mantissa only give you 7 full decimal digits. Double precision floating point came years later; it takes 4x as much hardware.
- harry8 2y agoIs 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 2y agoSigned 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.
- nialv7 2y agowell they managed to get two's complement requirement into C++20. there is always hope.
- oefrha 2y agoWell 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. https://lscs-software.com/LsCs-Manifesto.html https://lscs-software.com/LsCs-Manifesto.html https://news.ycombinator.com/item?id=41614949 https://news.ycombinator.com/item?id=41614949 Edit: Fixed typo pointed out by child.
- aj7 2y agoAnd then we lose communication with Europa Clipper.
- starik36 2y agoThere are FOUR bits. Jean-Luc Picard
- bmitc 2y agoIgnoring 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.
- kreco 2y agoI'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]. [1] https://en.cppreference.com/w/cpp/types/byte https://en.cppreference.com/w/cpp/types/byte
- bobmcnamara 2y agoI, for one, hate that int8 == signed char. std::cout << (int8_t)32 << std::endl; //should print 32 dang it
- kreco 2y agoNow you can also enjoy the fact that you can't even compile: std::cout << (std::byte)32 << std::endl; because there is no default operator<< defined.
- PaulDavisThe1st 2y agoVery enjoyable. It will a constant reminder that I need to decide how I want std::byte to print - character or integer ...
- spc476 2y agoMy first experience with computers was 45 years ago, and a "byte" back then was defined as an 8-bit quantity. And in the intervening 45 years, I've never come across a different meaning for "byte". I'll ask for a citation for a definition of "byte" that isn't 8-bits.
- larsbrinkhoff 2y ago1979 is quite recent as computer history goes, and many conventions had settled by then. The Wikipedia article discusses the etymology of "byte" and how the definition evolved from loosely "a group of bits less than a word" to "precisely 8 bits". https://en.wikipedia.org/wiki/Byte https://en.wikipedia.org/wiki/Byte
- hexo 2y agoWhy? 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?
- MaulingMonkey 2y agoSome people are still dealing with DSPs. https://thephd.dev/conformance-should-mean-something-fputc-and-freestanding#we-cannot-program-on--vibes- 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.
- jeffbee 2y agoThey 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 2y agono doubt you've got your brainfuck compiler hard at work on this ...
- defrost 2y agoTI DSP Assembler is pretty high level, it's "almost C" already. Writing geophysical | military signal and image processing applications on custom DSP clusters is suprisingly straightforward and doesn't need C++. It's a RISC architecture optimised for DSP | FFT | Array processing with the basic simplification that char text is for hosts, integers and floats are at least 32 bit and 32 bits (or 64) is the smallest addressable unit. Fantastic architecture to work with for numerics, deep computational pipelines, once "primed" you push in raw aquisition samples in chunks every clock cycle and extract processed moving window data chunks every clock cycle. A single ASM instruction in a cycle can accumulate totals from vector multiplication and modulo update indexes on three vectors (two inputs and and out). Not your mama's brainfuck.
- jfbastien 2y agoYes, I'm trying to figure out which are still relevant and whether they target a modern C++, or intend to. I've been asking for a few years and haven't gotten positive answers. The only one that been brought up is TI, I added info in the updated draft: https://isocpp.org/files/papers/D3477R1.html https://isocpp.org/files/papers/D3477R1.html
- scosman 2y agoBold leadership
- favorited 2y agoPreviously, in JF's "Can we acknowledge that every real computer works this way?" series: "Signed Integers are Two’s Complement" <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...>
- jsheard 2y agoMaybe specifying that floats are always IEEE floats should be next? Though that would obsolete this Linux kernel classic so maybe not. https://github.com/torvalds/linux/blob/master/include/math-emu/double.h#L29 https://github.com/torvalds/linux/blob/master/include/math-e...
- NL807 2y agoLove it
- AnimalMuppet 2y agoThat line is actually from a famous Dilbert cartoon. 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_wars_png/ https://www.reddit.com/r/linux/comments/73in9/computer_holy_...
- Jerrrrrrry 2y ago[flagged]
- FooBarBizBazz 2y agoWhether double floats can silently have 80 bit accumulators is a controversial thing. Numerical analysis people like it. Computer science types seem not to because it's unpredictable. I lean towards, "we should have it, but it should be explicit", but this is not the most considered opinion. I think there's a legitimate reason why Intel included it in x87, and why DSPs include it.
- deleted 2y ago
- bobmcnamara 2y agoI just put static_assert(CHAR_BITS==8); in one place and move on. Haven't had it fire since it was #if equivalent
- donatj 2y agoSo 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?
- dplavery92 2y agoEight is a nice power of two.
- donatj 2y agoCan you explain how that's helpful? I'm not being obtuse, I just don't follow
- bonzini 2y agoIt's easier to go from a bit number to (byte, bit) if you don't have to divide by 10.
- spongebobstoes 2y agoOne 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 2y agoThis 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.
- gafferongames 2y agoAmazing stuff guys. Bravo.
- adamnemecek 2y agoIncredible things are happening in the C++ community.
- masfuerte 2y agoThis 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?
- userbinator 2y agoI know some DSPs have 24-bit "bytes", and there are C compilers available for them.
- bryanlarsen 2y agoThere 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.
- DowsingSpoon 2y agoAs a person who designed and built a hobby CPU with a sixteen-bit byte, I’m not sure how I feel about this proposal.
- WalterBright 2y agoD 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.
- gerdesj 2y ago"1. bytes are 8 bits" How big is a bit?
- poincaredisk 2y agoA bit is either a 0 or 1. A byte is the smallest addressable piece of memory in your architecture.
- elromulous 2y agoTechnically the smallest addressable piece of memory is a word.
- asveikau 2y agoDepends on your definition of addressable. Lots of CISC architectures allow memory accesses in various units even if they call general-purpose-register-sized quantities "word". Iirc the C standard specifies that all memory can be accessed via char*.
- Maxatar 2y agoI don't think the term word has any consistent meaning. Certainly x86 doesn't use the term word to mean smallest addressable unit of memory. The x86 documentation defines a word as 16 bits, but x86 is byte addressable. ARM is similar, ARM processors define a word as 32-bits, even on 64-bit ARM processors, but they are also byte addressable. As best as I can tell, it seems like a word is whatever the size of the arithmetic or general purpose register is at the time that the processor was introduced, and even if later a new processor is introduced with larger registers, for backwards compatibility the size of a word remains the same.
- whatsakandr 2y agoHoesntly at thought this might be an onion headline. But then I stopped to think about it.
- pabs3 2y agoHmm, I wonder if any modern languages can work on computers that use trits instead of bits. https://en.wikipedia.org/wiki/Ternary_computer https://en.wikipedia.org/wiki/Ternary_computer
- cogman10 2y agoIt'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.
- cobbal 2y agoPossible, 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.
- bawolff 2y 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.
- MrLeap 2y agoHow many bytes is a devour?
- IAmLiterallyAB 2y agoI like the diversity of hardware and strange machines. So this saddens me. But I'm in the minority I think.
- kazinator 2y agoWhat will be the benefit? - CHAR_BIT cannot go away; reams of code references it. - You still need the constant 8. It's better if it has a name. - Neither the C nor C++ standard will be simplified if CHAR_BIT is declared to be 8. Only a few passages will change. Just, certain possible implementations will be rendered nonconforming. - There are specialized platforms with C compilers, such as DSP chips, that are not byte addressable machines. They are in current use; they are not museum pieces.
- jfbastien 2y agoHi! Thanks for the interest on my proposal. I have an updated draft based on feedback I've received so far: https://isocpp.org/files/papers/D3477R1.html https://isocpp.org/files/papers/D3477R1.html
- Miniminix 2y agoLove the snark in the proposal. Just one gem > The question isn’t whether there are still architectures where bytes aren’t 8-bits (there are!) but whether these care about modern C++... and whether modern C++ cares about them.
- kazinator 2y agoThere are DSP chips that have C compilers, and do not have 8 bit bytes; smallest addressable unit is 16 (or larger). Less than a decade ago I worked with something like that: the TeakLite III DSP from CEVA.
- lowbloodsugar 2y ago#define SCHAR_MIN -127 #define SCHAR_MAX 128 Is this two typos or am I missing the joke?
- jfbastien 2y agoTypo, I fixed it in the new draft: https://isocpp.org/files/papers/D3477R1.html https://isocpp.org/files/papers/D3477R1.html
- boulos 2y agoThe current proposal says: > A byte is 8 bits, which is at least large enough to contain the ordinary literal encoding of any element of the basic character set literal character set and the eight-bit code units of the Unicode UTF-8 encoding form and is composed of a contiguous sequence of bits, the number of which is bits in a byte. But instead of the "and is composed" ending, it feels like you'd change the intro to say that "A byte is 8 contiguous bits, which is". We can also remove the "at least", since that was there to imply a requirement on the number of bits being large enough for UTF-8. Personally, I'd make a "A byte is 8 contiguous bits." a standalone sentence. Then explain as follow up that "A byte is large enough to contain...".
- vitiral 2y agoI wish the types were all in bytes instead of bits too. u1 is unsigned 1 byte and u8 is 8 bytes. That's probably not going to fly anymore though
- bcoates 2y agoI have mixed feelings about this. On the one hand, it's obviously correct--there is no meaningful use for CHAR_BIT to be anything other than 8. On the other hand, it seems like some sort of concession to the idea that you are entitled to some sort of just world where things make sense and can be reasoned out given your own personal, deeply oversimplified model of what's going on inside the computer. This approach can take you pretty far, but it's a garden path that goes nowhere--eventually you must admit that you know nothing and the best you can do is a formal argument that conditional on the documentation being correct you have constructed a correct program. This is a huge intellectual leap, and in my personal experience the further you go without being forced to acknowledge it the harder it will be to make the jump. That said, there seems to be an increasing popularity of physical electronics projects among the novice set these days... hopefully read the damn spec sheet will become the new read the documentation
- joelignaatius 2y agoAs with any highly used language you end up running into what I call the COBOL problem. It will work for the vast majority of cases except where there's a system that forces an update and all of a sudden a traffic control system doesn't work or a plane falls out of the sky. You'd have to have some way of testing all previous code in the compilation (pardon my ignorance if this is somehow obvious) to make sure this macro isn't already used. You also risk forking the language with any kind of breaking changes like this. How difficult it would be to test if a previous code base uses a charbit macro and whether it can be updated to the new compiler sounds non obvious. What libraries would then be considered breaking? Would interacting with other compiled code (possibly stupid question) that used charbit also cause problems? Just off the top of my head. I agree that it sounds nonintuitive. I'd suggest creating a conversion tool first and demonstrating it was safe to use even in extreme cases and then make the conversion. But that's just my unenlightened opinion.
- bcoates 2y agoThat's not really the problem here--CHAR_BIT is already 8 everywhere in practice, and all real existing code[1] handles CHAR_BIT being 8. The question is "does any code need to care about CHAR_BIT > 8 platforms" and the answer of course is no, its just should we perform the occult standards ceremony to acknowledge this, or continue to ritually pretend to standards compliant 16 bit DSPs are a thing. [1] I'm sure artifacts of 7, 9, 16, 32, etc[2] bit code & platforms exist, but they aren't targeting or implementing anything resembling modern ISO C++ and can continue to exist without anyone's permission. [2] if we're going for unconventional bitness my money's on 53, which at least has practical uses in 2024
- js8 2y agoNothing to do with C++, but: I kinda like the idea of 6-bit byte retro-microcomputer (resp. 24-bit, that would be a word). Because microcomputers typically deal with small number of objects (and prefer arrays to pointers), it would save memory. VGA was 6-bit per color, you can have a readable alphabet in 6x4 bit matrix, you can stuff basic LISP or Forth language into 6-bit alphabet, and the original System/360 only had 24-bit addresses. What's there not to love? 12MiB of memory, with independently addressable 6-bits, should be enough for anyone. And if it's not enough, you can naturally extend FAT-12 to FAT-24 for external storage. Or you can use 48-bit pointers, which are pretty much as useful as 64-bit pointers.
- loup-vaillant 2y agoOr you can have 8 bit bytes, and 3 byte words. That’s still 24 bits.
- weinzierl 2y agoThis is an egoistical viewpoint, but if I want 8 bits in a byte I have plenty of choices anyway - Zig, Rust, D, you name it. Should the need for another byte width come up, either for past or future architectures C and C++ are my only practical choice. Sure, it is selfish to expect C and C++ do the dirty work, while more modern languages get away skimping on it. On the other hand I think especially C++ is doing itself a disservice trying to become a kind of half-baked Rust.
- RJIb8RBYxzAMX9u 2y agoWhile we're at it, perhaps we should also presume little-endian byte order. As much as I prefer big-endian, little-endian had won. As consolation, big-endian will likely live on forever as the network byte order.
- Uptrenda 2y agoC++ 'programmers' demonstrating their continued brilliance at bullshitting people they're being productive (Had to check if publishing date was April fools. It's not.) They should start a new committee next to formalize what direction electrons flow. If they do it now they'll be able to have it ready to bloat the next C++ standards no one reads or uses.
- rbanffy 2y agoDon't Unisys' Clearpath mainframes (still commercially available, IIRC) 36-bit word and 9-bit bytes? OTOH, I believe C and C++ are not recommended as languages on the platform.
- Suzuran 2y agoJust mandate that everything must be run on an Intel or ARM chip and be done with it. Stop pretending anything else is viable.
- AnimalMuppet 2y agoC++ is the second-most-widely-available language (behind C). Many other things are viable. Everything from a Z15 IBM mainframe to almost every embedded chip in existence. ("Viable" meaning "still being produced and used in volume, and still being used in new designs".) The next novel chip design is going to have a C++ compiler too. No, we don't yet know what its architecture will be.
- Suzuran 2y agoOh, but we do know - In order to be compatible with the existent languages, it's going to have to look similar to what we have now. It will have to keep 8 bit bytes instead of going wider that's what IBM came up with in the 1950s, and it will have to be a stack-oriented machine that looks like a VAX so it can run C programs. Unicode will always be a second-class character set behind ASCII because it has to look like it runs Unix, and we will always use IEEE floating point with all its inaccuracy because using scaling decimal data types just makes too much sense and we can't have that.
- akdev1l 2y agoRISC V is gaining ground.
- time4tea 2y agoformerly or formally?
- zombot 2y agoI'm appalled by the parochialism in these comments. Memory access sizes other than 8 bits being inconvenient doesn't make this a good idea.