3 ms·

Yeah I agree with rust's decision to not go there yet. They're only really used often in very low-level niches like mmio registers, where autogenerating handler

by pitaj 5y ago

Yeah I agree with rust's decision to not go there yet. They're only really used often in very low-level niches like mmio registers, where autogenerating handlers with svd2rust works great and provides a little bit of safety along with it. This is coming from someone who uses C bitfields every day on an embedded MCU.

ajxs 5y ago
> They're only really used often in very low-level niches like mmio registers ... which are actually an incredibly common, totally everyday problem encountered by tens of thousands of developers everyday? > autogenerating handlers with svd2rust works great and provides a little bit of safety along with it. I don't think that requiring third-party tooling to implement something so basic is a suitable solution to this problem. What if the manufacturer of the device I'm working with hasn't released an SVD file? What if I'm not actually working on an MCU at all, but a peripheral driver?
- pitaj 5y ago
  > actually an incredibly common, totally everyday problem encountered by tens of thousands of developers everyday I never said they're umcommon. As I said, I user them all the time. They're incredibly common in specific fields. There are many systems programmers who barely ever use them. There are a lot of footguns with bitfields in C. (1) they know nothing about defaults, (2) they have no way of restricting values beyond bitwidth, (3) they are often inefficient, producing multiple load-modify-stores for what is really a single operation, (4) they are not endian portable. svd2rust addresses all of those: (1) it knows what the defaults are and you can tell it to load them for you, (2) it will restrict the values for each field to only those that are valid (you can use unsafe to bypass the check), (3) it produces a single load-modify-store (or less) for any given operation, (4) it produces shifts and masks internally so doesn't depend on the compiler to behave as expected. Of course, C bitfields don't require tooling, and I'd say they're a little easier to use. It's a trade-off, and I personally prefer the rust side. > I don't think that requiring third-party tooling to implement something so basic is a suitable solution to this problem. Don't most people auto-generate bitfields, too? Like sure, writing a couple by hand is fine, but I didn't think that's typical. > What if the manufacturer of the device I'm working with hasn't released an SVD file? What if I'm not actually working on an MCU at all, but a peripheral driver? You can write your own SVD, or write yaml and convert that to SVD. I think that would probably work for a peripheral driver, too.
jandrewrogers 5y ago
Bitfield equivalent constructs are used more ubiquitously than just embedded. For example, in database engines the size of internal types are often defined in bits that aren't multiples of bytes, and they are packed and composed accordingly. Good implementations use a bit of meta-programming magic to make them seem more natural but they aren't something C++ was really designed to support. I think there is an opportunity for a systems language to do bitfield types right, which means not copying C.
- pitaj 5y ago
  I agree that there's certainly usefulness for bitfields in the industry, but I haven't seen a good proposal that addresses the main issues that C bitfields have. And in rust, any given proposal wouldn't be super useful if it always required unsafe.
  - zozbot234 5y ago
    The Rust standard library should concern itself with very general patterns that could feasibly enable interoperability across crates. I'd rather see a generalized facility for working seamlessly with composable 'optics' on Rust structs/objects (similar to the existing support for Iterators) than something strictly focused on the bitfield case.

by pitaj 5y ago

ajxs 5y ago

> They're only really used often in very low-level niches like mmio registers ... which are actually an incredibly common, totally everyday problem encountered by tens of thousands of developers everyday? > autogenerating handlers with svd2rust works great and provides a little bit of safety along with it. I don't think that requiring third-party tooling to implement something so basic is a suitable solution to this problem. What if the manufacturer of the device I'm working with hasn't released an SVD file? What if I'm not actually working on an MCU at all, but a peripheral driver?

pitaj 5y ago
> actually an incredibly common, totally everyday problem encountered by tens of thousands of developers everyday I never said they're umcommon. As I said, I user them all the time. They're incredibly common in specific fields. There are many systems programmers who barely ever use them. There are a lot of footguns with bitfields in C. (1) they know nothing about defaults, (2) they have no way of restricting values beyond bitwidth, (3) they are often inefficient, producing multiple load-modify-stores for what is really a single operation, (4) they are not endian portable. svd2rust addresses all of those: (1) it knows what the defaults are and you can tell it to load them for you, (2) it will restrict the values for each field to only those that are valid (you can use unsafe to bypass the check), (3) it produces a single load-modify-store (or less) for any given operation, (4) it produces shifts and masks internally so doesn't depend on the compiler to behave as expected. Of course, C bitfields don't require tooling, and I'd say they're a little easier to use. It's a trade-off, and I personally prefer the rust side. > I don't think that requiring third-party tooling to implement something so basic is a suitable solution to this problem. Don't most people auto-generate bitfields, too? Like sure, writing a couple by hand is fine, but I didn't think that's typical. > What if the manufacturer of the device I'm working with hasn't released an SVD file? What if I'm not actually working on an MCU at all, but a peripheral driver? You can write your own SVD, or write yaml and convert that to SVD. I think that would probably work for a peripheral driver, too.

jandrewrogers 5y ago

Bitfield equivalent constructs are used more ubiquitously than just embedded. For example, in database engines the size of internal types are often defined in bits that aren't multiples of bytes, and they are packed and composed accordingly. Good implementations use a bit of meta-programming magic to make them seem more natural but they aren't something C++ was really designed to support. I think there is an opportunity for a systems language to do bitfield types right, which means not copying C.

pitaj 5y ago
I agree that there's certainly usefulness for bitfields in the industry, but I haven't seen a good proposal that addresses the main issues that C bitfields have. And in rust, any given proposal wouldn't be super useful if it always required unsafe.
- zozbot234 5y ago
  The Rust standard library should concern itself with very general patterns that could feasibly enable interoperability across crates. I'd rather see a generalized facility for working seamlessly with composable 'optics' on Rust structs/objects (similar to the existing support for Iterators) than something strictly focused on the bitfield case.