21–30 of 60 posts
Earlier quoted context omitted.
Is this cause (ie. people downvote greens out of prejudice) or effect (greens are often created to shitpost? And to concentrate all my meta in one place... Is shadow banning a thing at HN? I thought they just, well, banned you.
OT - new user here, what does green mean? I assumed it was staff/moderators.
Earlier quoted context omitted.
Why in god's name did they make it 14?!
Ethernet was invented in 1973 and the first 32-bit processors were available in 1979. While you've got the time machine, can you fix it so that "network byte order" and Intel endianness are the same too?
Come to think of it, the Vax was little endian (like Intel).
Earlier quoted context omitted.
Why in god's name did they make it 14?!
They didn't feel like they needed those 2 bytes and, hey, why waste space? Also, was a "byte" standardized at the time? Didn't they still have systems working in not-8-bit "byte", nibbles, byte, and 2-byte boundaries?
There is a funny mode on ARM processors (turned on in some images, by default) which causes unaligned reads to silently return bogus data (just increasing a kernel counter). PowerPC, and really, most non-x86 architectures, do this one way or another.
ARM v6-A and later (except for some microcontrollers, like Cortex M0/R0, that don't support hardware unaligned access at all, triggering a exception) is similar to the Intel x86 case (reference in transparent unaligned memory access -except for SIMD, where x86 can raise exceptions, too, in the case of unaligned load/store opcodes-), where there is hardware support for unaligned memory access.
For software that uses intensive non-aligned data access, e.g. data compression algorithms doing string search, PowerPC, ARM v6-A (and later ARM Application processors), new MIPS with HW support for unaligned memory access, and Intel are pretty much the same (i.e. b = * (uint32_t * )(a + 23) will take 1-2 cycles, not requiring doing a memcpy(&b, a + 23, sizeof(uint32_t))).
For SIMD, though, there is no transparent fix, although there are specific opcodes for aligned and unaligned memory access (e.g. load/store, unaligned load/store).
I never deal with such low level issues, so I don't have to read this, but... reading these posts by antirez is such a joy. He makes this topic so clear and understandable, he doesn't assume much, he doesn't use overly complex explanations, he just "says it like it is" :-) Thanks!
There is a funny mode on ARM processors (turned on in some images, by default) which causes unaligned reads to silently return bogus data (just increasing a kernel counter). PowerPC, and really, most non-x86 architectures, do this one way or another.
PowerPC (and POWER) has reasonable hardware support for unaligned memory access, at least for 32-bit data, and if the data is in the data cache. Depending on the processor, the exceptions that reach the OS can be more or less frequent. ARM v6-A and later (except for some microcontrollers, like Cortex M0/R0, that don't support hardware unaligned access at all, triggering a exception) is similar to the Intel x86 case (…
Earlier quoted context omitted.
OT - new user here, what does green mean? I assumed it was staff/moderators.
It means new user (hence green color).
I'd venture to guess green users could use this ambiguity to play subtle rhetorical tricks on users with a moderate number of points here.