Development quote of the week
Development quote of the week
Posted Dec 1, 2022 17:38 UTC (Thu) by anton (subscriber, #25547)In reply to: Development quote of the week by mathstuf
Parent article: Development quote of the week
Reality check: Name an architecture from after 1970 that does not support two's-complement arithmetic. Even if there is one, then on that architecture the C unsigned types are at least inefficient: Many two's-complement operations are the same as unsigned operations, so if an architecture does not have the two's-complement operations, it does not have the unsigned operations, either. I have certainly never programmed on a binary machine that did not support two's-complement, and I have been programming since the early 1980s.
And GCC targets only two's-complement machines. While portability to dinosaurs probably was the original reason for undefining signed overflow, I have read from fans of undefined behaviour who deny this and claim that this undefined behaviour was introduced for performance.
supporting unaligned readsActually that has won (at least in general-purpose computers). If I want to test my programs on a machine that requires data alignment, I have to turn on our 2006-vintage Sparc T1000 or even older machines (most likely I would turn on a 1998-vintage Alpha). If I want to test on big-endian machines, I also have to turn on some old, normally turned-off machine; little-endian has won, too.
Posted Dec 1, 2022 18:57 UTC (Thu)
by khim (subscriber, #9252)
[Link] (4 responses)
You have a 1998-vintage Alpha but don't have a modern x86 device? That's crazy hard to believe. AC flag was added to it more than 30 years ago yet it's still supported. And IBM still makes new mainframes, Linux still supports them.
Posted Dec 1, 2022 22:41 UTC (Thu)
by anton (subscriber, #25547)
[Link]
Concerning movaps and friends, yes, they are useful to let fans of undefined behaviour miscompile previously working programs, but they are not useful for testing whether all memory accesses in a program are aligned. That's because they don't work for general-purpose registers, they don't work for scalars, they check for the wrong alignment (not the type alignment, but the container alignment; total brain damage), and there is no guaranteed way to get gcc to use it.
Concerning byte order: Unfortunately IBM has failed to make a mainframe available to me, so I still have to turn on a vintage machine for big-endian testing (I typically use a 2004-vintage iBook G4 for that). In the long run, few people will test software on big-endian machines, bit rot will lead to many programs not working on them, and that will be a problem for IBM's mainframe business; or maybe not: IBM's salesforce will undoubtedly convince the customers that it's a sign of their elite status that not every old program works on their mainframe.
Meanwhile, the OpenPower part of IBM has seen the signs of the time and has switched the architecture to little-endian.
Posted Dec 1, 2022 23:11 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
That's not what he said. Or are you saying that x86 REQUIRES data alignment? (I don't know x86 architecture - I really don't know.)
Cheers,
Posted Dec 2, 2022 0:09 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Yes. Starting from 80486 you have a bit in EFLAGS register which you can use to switch between two modes. ARM got such switch a bit later (only it was getting to it from the opposite direction: old versions required data alignment while it's optional on latest CPUs).
Posted Dec 2, 2022 18:59 UTC (Fri)
by ejr (subscriber, #51652)
[Link]
It's fun, really.
Posted Dec 1, 2022 19:36 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
I can't. However, C still thought it important enough to not specify until the standard due next year.
> I have read from fans of undefined behaviour who deny this and claim that this undefined behaviour was introduced for performance.
I'm not a *fan* of UB. I dislike it as much as anyone here. But I'm also not saying that *my* thoughts on what any given UB should mean should be enshrined either. Note that some optimizations allowed by UB can improve performance. That doesn't justify UB's existence, but should serve as a reminder for some of the reasons UB continues to persist.
> If I want to test on big-endian machines, I also have to turn on some old, normally turned-off machine; little-endian has won, too.
We deploy to (new) machines that are big-endian, so that is certainly not universal.
> If I want to test my programs on a machine that requires data alignment, I have to turn on our 2006-vintage Sparc T1000 or even older machines (most likely I would turn on a 1998-vintage Alpha).
Development quote of the week
vmovapsstill fails even without it in a brand-spanking new AVX512 (which AMD have only just added to their CPUs this year).
I have tried several times to use the AC flag for testing that everything is aligned, but failed: On IA-32 Intel's own ABI results in code that produces an exception if AC is set. On AMD64 the ABI is ok, but gcc produces code with unaligned accesses from code where all pointers are correctly aligned for their data types.
Development quote of the week
Development quote of the week
Wol
> Or are you saying that x86 REQUIRES data alignment?
Development quote of the week
Development quote of the week
Development quote of the week