Here’s some anecdata.
I tend to work pretty close to the metal (deeply embedded systems, network protocol stacks, crypto, etc.) and I do a lot of bit manipulation.
I never think in terms of the “halves” of an integer. In fact, I clicked into this thread because
hi() suggest, to me, either least/most-significant bit or byte access, and I was unclear on what half an integer would mean.
I am significantly more likely to need:
- Bits 19:15 of this integer, zero-extended.
- A particular byte, or every byte for serialization.
I note that all of the motivating examples you sent are actually accessing bytes in 16-bit integers, not halves per se. I believe byte access is a natural thing to need, and the fact that your byte accesses happen to map to halves is an artifact of your emulating a (mostly) 16-bit platform — not an indicator of the intrinsic value of “integer halves.” Were you emulating a 32-bit system I think you’d have less desire for halving integers (because
new_addr.lo().hi() isn’t nearly as pretty).
I don’t think these operations (
hi()) are sufficiently general/primitive to merit the API surface area in
core that you’re suggesting. Maybe implement them in your own codebase first?