The more and more bit-hacks I see, the more convinced I am that they should be handled by a cleverer compiler. Some intrinsic(s) where you say “do x, y, to these bits” and it just figures out the optimum way of doing it for whatever platform you compile for.
That's a really cool side. Sad that it doesn't allow duplicate indices.
I tried implementing the same thing but with support for duplicates and it was definitely a humbling exercise.
I'm curious if there is any formal mathematical theory for this (shifted-off bits would probably make it less elegant than pure rotation)
that page + the book Hacker's Delight are a big part of the reason I am so convinced of this :)
If compilers/languages/standard libraries provided these bit permutations, and it was just something ~everyone had learned, it would be a lot easier to work with bits without needing to come up with the bitwise ops (or use that generator). In addition it would probably make better use of the hardware: sure, people like to pretend that we’re still programming C for PDP11, but modern hardware supports more operations than C has operators for (RISC-V B extension and co have the right idea <3)
Modern compilers are probably pretty good? but I doubt they are perfect at turning code like that in OP into the best instructions.
It is probably a bit late for C/C++ though. maaaybe possible to get it into LLVM and Rust.
That's more like the opposite, OP wants to tell the compiler what transform to do and have it figure out a solution, but in your example you give the compiler a solution and it works backwards to figure out the intent and rewrite it to a completely different solution.
Most languages do have intrinsics for ROL/ROR at least, which you should generally use instead of relying on optimizer magic. I've certainly run into cases where those magic patterns don't get optimized (looking at you MSVC) but intrinsics always work.
At least in my iOS 18 Passwords app, the passwords are shown in a monospace font that (probably deliberately) differentiates all these (e.g. a slashed zero).
I wouldn’t call it a pet peeve but I understand where you’re coming from with this: but I think the main reason for it is electronic engineers, with little-to-no product design or even mechanical design/CAD background. IMO it’s a shame: it’s sort of like the open source hardware version of the “Blender before it got good UX” problem.
Open hardware so you could build your own for fairly cheap. I bought a clone (is it a clone if the creator never sold them? I'd have preferred to buy it from him...) off aliexpress for ~$50.
Yes: because Apple actually got this added to the spec: https://www.usb.org/document-library/usb-type-cr-cable-and-c... which is the real story IMO (I am impressed no one bothered looking at the Type-C spec update after the Type-C iPhone finally came out)
This actually replaced the analog audio mode (good riddance- whoever thought adding analog audio into a port that also does digital audio was a good idea?)
The problem is that it's a rather confusing Alt Mode.
Basically, it's only supposed to be used for USB-C-to-3.5mm adapters, and it was only implemented by some smartphones. It's not a reliable way to get audio out of a USB-C port, and because it's using the internal DAC the audio quality isn't going to be good anyways.
The proper solution is to use a USB DAC. This provides the same user experience but it actually works with all USB-C devices. Considering the official Apple USB DAC is available for $9, the Audio Alt Mode really doesn't have a reason to exist.
Why is it confusing or bad? Sure, it sacrifices a data line pair, but the same can be said of DisplayPort Alt Mode - if you want 4K@60Hz on DP 1.2 you need to sacrifice USB3.0.
The ability to make this tradeoff should be up to the user.
