Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Philosophy of _bm vs _gm suffixes #912

Open
stefanrueger opened this issue Mar 22, 2023 · 4 comments
Open

Philosophy of _bm vs _gm suffixes #912

stefanrueger opened this issue Mar 22, 2023 · 4 comments
Labels
question Further information is requested

Comments

@stefanrueger
Copy link

stefanrueger commented Mar 22, 2023

One ostensibly signifies the notion of a one-bit bit-mask while the other denote multi-bit bitmasks. But when is that distinction in the constant name actually useful? I mean when I don't know whether something (say a clock frequency selector) has two (one bit) or more (multiple bits) selections, how should I proceed?

On the other hand I can always count the number of bits set when I have the pattern. The name of the constant does not need to encode that.

Would it not be better to always use the suffix _bm?

@dl8dtl
Copy link
Contributor

dl8dtl commented Mar 22, 2023

IIRC these names came straight from Atmel.

@stefanrueger
Copy link
Author

IIRC these names came straight from Atmel.

Should employ more people who pass the Sally-Anne-test.

@dl8dtl
Copy link
Contributor

dl8dtl commented Mar 22, 2023

Btw., I'm always hesitant to change things that have been that way for 10+ years. Regardless of whether they make any sense or not, you can never know who might actually be using them out there.

@stefanrueger
Copy link
Author

Sure, can and should keep all there is, but that wouldn't preclude duplicating those _gm constants also as _bm constants (or a new one _mask). I admit it's probably not worth the trouble, as there are much bigger inconsistencies in naming registers etc - this was actually more of a question out of curiosity (as I didn't want to presume there wasn't much thought behind these decisions).

@sprintersb sprintersb added the question Further information is requested label Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants