Hacker News

I'm literally giving a talk next week who's first slide is essentially "Why IEEE 754 is not a sufficient description of floating-point semantics" and I'm sitting here trying to figure out what needs to be thrown out of the talk to make it fit the time slot.

One of the most surprising things about floating-point is that very little is actually IEEE 754; most things are merely IEEE 754-ish, and there's a long tail of fiddly things that are different that make it only -ish.

Hi! I'm JF. I half-jokingly threatened to do IEEE float in 2018 https://youtu.be/JhUxIVf1qok?si=QxZN_fIU2Th8vhxv&t=3250

I wouldn't want to lose the Linux humor tho!

That 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_...

Whether 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.

I was curious about float16, and TIL that the 2008 revision of the standard includes it as an interchange format:

https://en.wikipedia.org/wiki/IEEE_754-2008_revision

Permalink (press 'y' anywhere on GitHub): https://github.com/torvalds/linux/blob/4d939780b70592e0f4bc6....

Which one? Remember the decimal IEEE 754 floating point formats exist too. Do folks in banking use IEEE decimal formats? I remember we used to have different math libs to link against depending, but this was like 40 years ago.

At the very least, division by zero should not be undefined for floats.

Love it

That is so strange. If it were 9-bit bytes, that would make sense: 8bits+parity. Then a word is just 32bits+4 parity.

Hah. Why did they do that?

The Nintendo64 had 9-bit RAM. But, C viewed it as 8 bit. The 9th bit was only there for the RSP (GPU).

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.

How so? Arithmetic on FPGA usually use the minimum size that works, because any size over that will use more resources than needed.

9-bit bytes are pretty common in block RAM though, with the extra bit being used for either for ECC or user storage.

10-bit C might be close to non-existent, but I've heard that quite a few DSP are word addressed. In practice this means their "bytes" are 32 bits.

  sizeof(uint32_t) == 1

B was developed on the PDP-7. C was developed on the PDP-11.

Zig allows any uX and iX in the range of 1 - 65,535, as well as u0

Same deal with Rust.

This is the way.

LLVM has:

i1 is 1 bit

i2 is 2 bits

i3 is 3 bits

…

i8388608 is 2^23 bits

(https://llvm.org/docs/LangRef.html#integer-type)

On the other hand, it doesn’t make a distinction between signed and unsigned integers. Users must take care to use special signed versions of operations where needed.

How does 5 work in practice? Surely no one is actually checking if their arithmetic overflows, especially from user-supplied or otherwise external values. Is there any use for the normal +?

Eh I like the nice names. Byte=8, short=16, int=32, long=64 is my preferred scheme when implementing languages. But either is better than C and C++.

> Type names with explicit sizes (u8, i32, etc) are way better in every way

Until one realizes that the entire namespace of innn, unnn, fnnn, etc., is reserved.

This doesn't feel like a serious question, but in case this is still a mystery to you… the name bit is a portmanteau of binary digit, and as indicated by the word "binary", there are only two possible digits that can be used as values for a bit: 0 and 1.

A bit is a measure of information theoretical entropy. Specifically, one bit has been defined as the uncertainty of the outcome of a single fair coin flip. A single less than fair coin would have less than one bit of entropy; a coin that always lands heads up has zero bits, n fair coins have n bits of entropy and so on.

https://en.m.wikipedia.org/wiki/Information_theory

https://en.m.wikipedia.org/wiki/Entropy_(information_theory)

How philosophical do you want to get? Technically, voltage is a continuous signal, but we sample only at clock cycle intervals, and if the sample at some cycle is below a threshold, we call that 0. Above, we call it 1. Our ability to measure whether a signal is above or below a threshold is uncertain, though, so for values where the actual difference is less than our ability to measure, we have to conclude that a bit can actually take three values: 0, 1, and we can't tell but we have no choice but to pick one.

The latter value is clearly less common than 0 and 1, but how much less? I don't know, but we have to conclude that the true size of a bit is probably something more like 1.00000000000000001 bits rather than 1 bit.

> How big is a bit?

A quarter nybble.

A bit is either a 0 or 1. A byte is the smallest addressable piece of memory in your architecture.

If your detector is sensitive enough, it could be just a single electron that's either present or absent.

At least 2 or 3

Depends on your physical media.

Of course!

Over the years I've known some engineers who, as a side project, wrote some great software. Nobody was interested in it. They'd come to me and ask why that is? I suggest writing articles about their project, and being active on the forums. Otherwise, who would ever know about it?

They said that was unseemly, and wouldn't do it.

They wound up sad and bitter.

The "build it and they will come" is a stupid Hollywood fraud.

BTW, the income I receive from D is $0. It's my gift. You'll also note that I've suggested many times improvements that could be made to C, copying proven ideas in D. Such as this one:

https://www.digitalmars.com/articles/C-biggest-mistake.html

C++ has already adopted many ideas from D.

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.

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).

While I don't agree with not having unsigned as part of the primitive times, and look forward to Valhala fixing that, it was based on the experience most devs don't get unsigned arithmetic right.

"For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that, for instance, Java isn't -- and in fact a lot of these languages end up with a lot of corner cases, things that nobody really understands. Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up."

http://www.gotw.ca/publications/c_family_interview.htm

I work every day with real-life systems where int can be 32 or 64 bits, long long can be 64 or 128 bits, long double can be 64 or 80 or 128 bits, some systems do not have IEEE 754 floating point (no denormals!) some are big endian and some are little endian. These things are not in the language standard because they are not standard in the real world.

Practically speaking, the language is the way it is, and has succeeded so well for so long, because it meets the requirements of its application.

> (it just hasn't made it to the standard)

That's the problem

> and would benefit from C23’s _BigInt

s/_BigInt/_BitInt/

TI 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.

> For the damn accountants who care about the cost of bytes.

Finally! A language that can calculate my S3 bill

RAND_MAX is only guaranteed to be at least 32767. So if you use `rand() % 10000` you'll have real biased towards 0-2767, even `rand() % 1000` is already not uniform (biased towards 0-767). And that assumes rand() is good uniform from 0-RAND_MAX in the first place.

> The function rand() is not reentrant or thread-safe, since it uses hidden state that is modified on each call.

It cannot be called safely from a multi-threaded application for one

This is such an odd thing to read & compare to how eager my colleagues are to upgrade the compiler to take advantage of new features. There's so much less need to specify types in situations where the information is implicitly available after C++ 20/17. So many boost libraries have been replaced by superior std versions.

And this has happened again and again on this enormous codebase that started before it was even called 'C++'.

It is one of my favourite languages, but I think it has already crossed over the complexity threshold PL/I was known for.

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.

https://lscs-software.com/LsCs-Manifesto.html

https://news.ycombinator.com/item?id=41614949

Edit: Fixed typo pointed out by child.

Which was quite controversial. Imagine that.

Hahaha, you're including Bjarne in that sweeping generalization? C++ has long had a culture problem revolving around arrogance an belittling others, maybe it is growing out of it?

I would point out that for any language, if one has to follow the standards committee closely to be an effective programmer in that language, complexity is likely to be an issue. Fortunately in this case it probably isn't required.

I see garbage collection came in c++11 and has now gone. Would following that debacle make many or most c++ programmers more effective?

That'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

1979 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

That's interesting because maybe a byte will not be 8-bit in 45 years from now on.

I'm mostly discussing from the sake of it because I don't really mind as a C/C++ user. We could just use "octet" and call it a day, but now there is an ambiguity with the past definition and potential in the future definition (in which case I hope the term "byte" will just disappear).

Now you can also enjoy the fact that you can't even compile:

  std::cout << (std::byte)32 << std::endl;

Steins;byte

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.

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.

[1] https://www.unisys.com/siteassets/collateral/info-sheets/inf...

> 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.

Huh, that’s clever!

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:

I added a mention of TI's hardware in my latest draft: https://isocpp.org/files/papers/D3477R1.html

Yes, but you're already in specialized territory if you're using that

Don’t you mean 2,4, and 8?

You're right. To be consistent with bytes we should call it a snack.

It's very useful on hardware that is not an x86 CPU.

Appeasing that attitude is what prevented Microsoft from migrating to LP64. Would have been an easier task if their 32-bit LONG type never existed, they stuck with DWORD, and told the RISC platforms to live with it.

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 ?

Can you explain how that's helpful? I'm not being obtuse, I just don't follow

Buckets of 10 seem more regular to beings with 10 fingers that can be up or down?

>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.

Supposedly, "bit" is short for "binary digit", so we'd need a separate term for "ternary digit", but I don't wanna go there.

Ternary computers have 8 tits to a byte.

Oh, 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.