Verilator: g++ and uint32_t

[Fred Ma]

Hello,

I'm tring to understand some code in an example that comes with an
application called "Verilator". The app takes hardware description
code in Verilog and converts it into a C++. The hardware behaviour is
realized via library calls and various definitions from two libraries,
"SystemC" and "SystemPerl".

The C++ output from verilator contains many references to a data type
"uint32_t". This is standardized in C99 such that if a native 32-bit
data type exists, then uint32_t is defined as that data type. From my
googling, uint32_t is not standardized for C prior to C99, nor is it
standardized for C++.

Googling has unearthed that uint32_t lives in stdint.h for C99.
However, as of today, gcc does not support the things from stdint.h
(http://gcc.gnu.org/gcc-3.3/c99status.html). In fact, the gcc
complains that it can't find stdint.h when using the example's
accompanying make file. The place where stdint.h is referenced has a
comment explaining that it is specifically to enable uint32_t.

The baffling thing is that the example seems to run fine despite the
liberal use of the nonexistent data type uint32_t. I did a recursive
grep through all my include directories and found liberal usage of
uint32_t, but no definition of uint32_t:

/home/fma/INSTROOT/systemc-2.0.1/include
/usr/local/lib/gcc-lib/../../include/c++/3.3.2
/usr/local/lib/gcc-lib/../../include/c++/3.3.2/sparc-sun-solaris2.8
/usr/local/lib/gcc-lib/../../include/c++/3.3.2/backward
/usr/local/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/include
/usr/include

Would I be right in assuming that recognition of uint32_t is built in
to gcc, even though stdint.h stuff is not yet supported? I'm trying
to rule out the possibility that uint32_t is defined by some means
which I have no awareness of control over. I want its definition to
be consistent with gcc's scheme of things.

I am using gcc 3.3.2 (invoked as g++), running on sparc solaris 8.
I am using verilator-3.202 and SystemPerl-1.148.

Thanks for any comments.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

 

[Fred Ma]

Fred Ma wrote:

I'm tring to understand some code in an example that comes with an
application called "Verilator". The app takes hardware description
code in Verilog and converts it into a C++. The hardware behaviour is
realized via library calls and various definitions from two libraries,
"SystemC" and "SystemPerl".

The C++ output from verilator contains many references to a data type
"uint32_t". This is standardized in C99 such that if a native 32-bit
data type exists, then uint32_t is defined as that data type. From my
googling, uint32_t is not standardized for C prior to C99, nor is it
standardized for C++.

Googling has unearthed that uint32_t lives in stdint.h for C99.
However, as of today, gcc does not support the things from stdint.h
(http://gcc.gnu.org/gcc-3.3/c99status.html). In fact, the gcc
complains that it can't find stdint.h when using the example's
accompanying make file. The place where stdint.h is referenced has a
comment explaining that it is specifically to enable uint32_t.

The baffling thing is that the example seems to run fine despite the
liberal use of the nonexistent data type uint32_t. I did a recursive
grep through all my include directories and found liberal usage of
uint32_t, but no definition of uint32_t:

/home/fma/INSTROOT/systemc-2.0.1/include
/usr/local/lib/gcc-lib/../../include/c++/3.3.2
/usr/local/lib/gcc-lib/../../include/c++/3.3.2/sparc-sun-solaris2.8
/usr/local/lib/gcc-lib/../../include/c++/3.3.2/backward
/usr/local/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/include
/usr/include

Would I be right in assuming that recognition of uint32_t is built in
to gcc, even though stdint.h stuff is not yet supported? I'm trying
to rule out the possibility that uint32_t is defined by some means
which I have no awareness of control over. I want its definition to
be consistent with gcc's scheme of things.

I am using gcc 3.3.2 (invoked as g++), running on sparc solaris 8.
I am using verilator-3.202 and SystemPerl-1.148.

I found the answer to my question. uint32_t lives in
/usr/include/sys/int_types.h, found using cscope. I missed it
with grep because I was looking for "unit32_t[ ^I]$"
i.e. at the end of a line, as it would be if it was the target
of a typedef. Otherwise, uint32_t shows up too often to be able
to find the declaration. Unfortunately, uint32_t is followed by
a ";" in a typedef, thus the failed grep.

Fred

P.S. Funny, but grep doesn't find any hint that the above file
(or is directory) is specified as the target of includes in any
source file. That is with recursive grepping for "\<include.sys\>"
and "int_types.h". The grep was done in the parent directory of
the app, and all the apps that the app relies on. These also
contain the example code (source, object, and executable). However,
both greps found hits among library and object files *.a and *.o.
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

 

[Wim Lauwers]

Fred Ma wrote:

Fred Ma wrote:
I found the answer to my question. uint32_t lives in
/usr/include/sys/int_types.h, found using cscope. I missed it
with grep because I was looking for "unit32_t[ ^I]$"
i.e. at the end of a line, as it would be if it was the target
of a typedef. Otherwise, uint32_t shows up too often to be able
to find the declaration. Unfortunately, uint32_t is followed by
a ";" in a typedef, thus the failed grep.

Fred

P.S. Funny, but grep doesn't find any hint that the above file
(or is directory) is specified as the target of includes in any
source file. That is with recursive grepping for "\<include.sys\>"
and "int_types.h". The grep was done in the parent directory of
the app, and all the apps that the app relies on. These also
contain the example code (source, object, and executable). However,
both greps found hits among library and object files *.a and *.o.

I'm using /usr/include/inttypes.h (being #include <inttypes.h&gt and
sys/types.h for uint_t, uchar_t etc. This seems to be more or less
standard. I also had the impression that gcc automatically includes
them, but I don't rely on it, since other compilers don't.

Regards,
Wim

 

[fred ma]

Wim Lauwers <wim.lauwers@alcatel.be> wrote in message news:<c5g0ee$47g$1@news.alcatel.fr>...

I found the answer to my question. uint32_t lives in
/usr/include/sys/int_types.h, found using cscope. I missed it
with grep because I was looking for "unit32_t[ ^I]$"
i.e. at the end of a line, as it would be if it was the target
of a typedef. Otherwise, uint32_t shows up too often to be able
to find the declaration. Unfortunately, uint32_t is followed by
a ";" in a typedef, thus the failed grep.

Fred

P.S. Funny, but grep doesn't find any hint that the above file
(or is directory) is specified as the target of includes in any
source file. That is with recursive grepping for "\<include.sys\>"
and "int_types.h". The grep was done in the parent directory of
the app, and all the apps that the app relies on. These also
contain the example code (source, object, and executable). However,
both greps found hits among library and object files *.a and *.o.

I'm using /usr/include/inttypes.h (being #include <inttypes.h&gt and
sys/types.h for uint_t, uchar_t etc. This seems to be more or less
standard. I also had the impression that gcc automatically includes
them, but I don't rely on it, since other compilers don't.

Well, /usr/include/inttypes.h just includes
/usr/include/sys/inttypes.h, which in turn includes the int_types.h I
mention above. As for sys/types.h, I also have that, but it defines a
synonym for uint32_t rather than uint32_t itself. I guess we have our
system set up differently. All the files I mentioned are Sun files
except for sys/types.h, which is Copyright AT&T.

Thanks for the low-down on your uint's.

Fred