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... > >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. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
