On 06/02/2016, 18:41, "gem5-dev on behalf of Steve Reinhardt" <[email protected] on behalf of [email protected]> wrote:
>Thanks for the feedback, Andreas... a few questions below: > >On Sat, Feb 6, 2016 at 10:25 AM Andreas Sandberg ><[email protected]> >wrote: > >> >> 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. >> > >I'm not sure what you mean by "C doesn¹t define a signed integer >format"... are you worried about running on machines that don't use two's >complement? That seems like a pretty unlikely portability issue... It’s not exactly a problem in practice, I has been a while since I used a machine that didn’t represent signed numbers in 2’s complement. :) I’m mainly concerned about bit-wise operations having undefined behaviour when they operate on signed integers. At least bit-shifts on negative numbers are undefined according to the C standard. Even if they work in practice, they will cause issues with static code checkers. >>>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. >> > >Can you clarify? There are already existing typedefs for addresses and >registers (Addr and IntReg/FloatReg etc.), and it's important to use these >because we support both 32- and 64-bit ISAs. Certainly in the >implementation of the StaticInst::execute() methods there is often a lot >of >gnarly casting going on to get semantics right, but I would argue that >that's the only place there's any reason to use uint*_t/int*_t types for >registers. > >Or are you talking about control registers for I/O devices? In that case >I >might agree with you, but unless you're actually working on modeling I/O >devices, that's a pretty narrow exception. I’m sorry if I was unclear here. I was talking about control registers in device and not normal CPU registers. //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
