On 04/02/2016, 22:19, "gem5-dev on behalf of Gutierrez, Anthony" <[email protected] on behalf of [email protected]> wrote:
>Since we've been discussing style/coding standards lately, I thought it >would be a good time to bring up a long-standing gripe I have: the use of >unsigned types. I'd like to suggest that the style guide mandate that the >use of unsigned types is forbidden unless there is an explicit need for >it (note I don't believe that "this variable ought never be negative" is >a good reason). Good use cases would be when we're doing bitwise >operations/masking, we need well defined overflow behavior, or we need >the extra bit of precision, e.g., addresses. > >This is already mandated in the style guide of companies like Google: >https://google.github.io/styleguide/cppguide.html#Integer_Types, and I >think it's generally accepted as good software engineering practice. This seems like a good idea. However, I would argue that registers and addresses should normally be unsigned. In both cases, we tend do do bit-wise operations on them. Since C doesn¹t define a signed integer format, you could even argue that registers that are defined to be signed should be declared as unsigned and use explicit conversions since when treating their numerical value. >Also, as a somewhat related issue, I propose mandating that we shouldn't >specify precision using the uint*_t/int*_t flavors unless we need >explicit precision, and in many of those cases we should typedef these >things, as in Addr. Agreed as long as we use some moderation. Types that are used in multiple places/components (e.g., CPU ID, socket ID, task ID, PID) should definitely be typedefed. Creating a typdef for registers that match existing uint*_t/int*_t definitions seems redundant in most cases. //Andreas IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
