fasterthanlime 🌌
fasterthanlime@hachyderm.io
I feel like Apple Silicon is a notable enough exception that it ought to be mentioned but whatever.
https://avestura.dev/blog/problems-of-c-and-how-zig-addresses-them
5
0
0
fasterthanlime 🌌
fasterthanlime@hachyderm.ioI remember now! It _can_ crash if the compiler optimizes to SIMD instructions that disallow unaligned reads ("dqu" instructions)
2
0
0
@fasterthanlime as i'm sure you're aware though, that's still UB whatever the cpu says.
1
0
0
fasterthanlime 🌌
fasterthanlime@hachyderm.io
2
0
0
@fasterthanlime oh shit i didn't realise. go ahead and ship then
0
0
0
@fasterthanlime aren't misaligned reads just slightly slower on x86 too? 🤔
1
0
0
@elomatreb I think that hasn't been the case in a long while
have a 2012 article from lemire: https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
1
0
0
@fasterthanlime hence "slightly", but I don't think it ever *crashed*
0
0
0
@fasterthanlime it can also crash if the compiler feels like it.
1
0
0
@fasterthanlime if it is UB, the compiler can do anything. like mine bitcoin if it wants but probably just crash
1
0
0
fasterthanlime 🌌
fasterthanlime@hachyderm.io@dysfun oh, right, yeah. well most likely it'll eliminate a bunch of code? but yeah sure crashing is allowed.
0
0
0
[10] Meriel 
omni@elekk.xyz
@fasterthanlime my favourite is that on old ARM architectures, an unaligned read is forcibly aligned down AND the data you get ends up bit-rotated
2
0
0
Wasm also allows unaligned reads, and does not seem to even give any errors or anything, it is even okay with reading unaligned 64 bit values.
And const arrays in Rust are only aligned to in inner value (eg 8 bits if you have u8) And the only way to change alignment is to use some rather ugly workarounds. Had a test that started failing after a compiler upgrade because of it.
0
0
0
[17921] /bin/cat(girl) 
catgirl_so@tech.lgbt
@omni @fasterthanlime this unit forgets what console and what isa but some old game consoles did this on purrpose! iirc, the 4-byte load instruction interpreted its src argument as {usize::BITS - 2} bits of address and 2 bits of how many bytes to right-shift/rotate the value. that made it so that loading from xxxx5 did put the byte at xxxx5 into the accumulator without the memory controller needing to support unaligned loads.
...did it not learn that from ftl? 
the article was about alignment and undefined behavior, and the author used that as an example of why unaligned loads are ub. they cross-compiled and ran it in an emulator and it didn't display the weirdness, so they disassembled the program and realized gcc had optimized out the load entirely because it was a constant address that pointed to a constant. the author had a little creature like cool bear that snarked at them while they fiddled with the code to make the load happen at runtime. this could've sworn it was amos!
1
0
0
fasterthanlime 🌌
fasterthanlime@hachyderm.io@catgirl_so @omni are you trying to manifest a new article 🕯️
now I want to read it!
0
0
0
Charlotte 🦝 
charlotte
0
0
0
dusterthefirst
dusterthefirst@hachyderm.io@fasterthanlime @dysfun the alt text is just the letter w :(
0
0
0