register src/sysc/datatypes/int/sc_nbutils.h

[sumit_tuwien]

Hi All,

 

I have a question - can I safely delete registers in  src/sysc/datatypes/int/sc_nbutils.h OR some surprise might come during simulation ?

 

Regards, Sumit

[Philipp A Hartmann]

Sumit,

 

yes, you can safely remove the storage class specifier "register" from sc_nbutils.h.  It's only a hint for the compiler, and today's compilers usually now way better which variables to put in registers (and e.g. loop variables will probably end there anyhow).

 

But why do you want to bother? Does your compiler complain about these?

 

Please keep in mind, that this is still a reserved keyword in C/C++. You don't want to re-#define this token, do you?

 

Greetings from Oldenburg,
  Philipp

[sumit_tuwien]

Hi Philipp,

 

Nice new pic by the way.

 

 

yes, you can safely remove the storage class specifier "register" from sc_nbutils.h.  It's only a hint for the compiler, and today's compilers usually now way better which variables to put in registers (and e.g. loop variables will probably end there anyhow).

 

 

Thanks, we will do that.

 

But why do you want to bother? Does your compiler complain about these?

 

We want to embed some simulation control and debug capabilities and hence we will have to do some modification of SystemC kernel.  That is the reason we are going through SystemC code well. We have created a build environment which works for both gcc and clang. So, we thought why not clean up the SystemC library as much as possible while we understand the code ? It is clang which always warns about "register".

 

Please keep in mind, that this is still a reserved keyword in C/C++. You don't want to re-#define this token, do you?

 

Thanks for the reminder. I really do not want that to happen to us - but I see clang always saying it will be deprecated. Further more, our virtual prototypes are using lot of c++11 standard constructs, so anyway we cannot go back to old compiler versions.

 

 

By the way, we are looking forward more towards clang (for some tool-chain creation) due to its modular design, easy hackability (APIs) and BSD license which behaves little different than gcc - which mean more work for us. But Clang APIs changes lot and fast over versions. Is it safe for us to start using Clang APIs now ? I know this question is out of context, but just wanted a opinion from you. I already had a discussion with Torsten over skype on this.

 

Regards, Sumit