Subject: Re: DirectC: C layer - #define vs. typedef enum
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Thu Jan 09 2003 - 14:50:56 PST
Michael's raised the question whether the representation of x, z
should be defined via #define, as proposed, or via typedef enum.
> > "sverilog.h"
> > =================
> >
> > #define sv_0 0
> > #define sv_1 1
> > #define sv_z 2 /* representation of 4-st scalar z */
> > #define sv_x 3 /* representation of 4-st scalar x */
>
> > typedef unsigned char svBit; /* scalar */
> > typedef unsigned char svLogic; /* scalar */
Michael's comment:
> There are several members of our working group discussing about OO features,
> C++ and others, but nobody is asking why we are still using antique styles
> like #define instead of enum's here. I understand that this is similar to
> PLI/VPI, and as such might be a more compatible solution, but from a software
> engineering viewpoint I needed to say this.
>
> So why is this not a typedef'd enum? This could also be used then for -- and
> compiler provable - definitions of the both types below.
It may seem natural to group logically the constants that define the
representation of 4-state scalars as an enum type, for example:
typedef enum {
sv_0 = 0,
sv_1 = 1,
sv_z = 2,
sv_x = 3
} scalars;
There are some technical issues, however, with such solution.
The main issue is the size. Enums are usually represented as ints.
sizeof(scalars) = sizeof(sv_x) = 4
sizeof(svBit) = sizeof(svLogic) = 1
If the enum type 'scalars' is used just for grouping the names - fine.
There should be no problems with variables of that type, either.
It makes a difference, however, whether a function result type is defined
as 'scalars' or as 'svBit' or 'svLogic', because of different sizes.
C compiler may use different registers to return value of size 1 and
value of size 4 (e.g. gcc 2.96 for Linux).
(Very likely similar problem will occur for function arguments.)
So I'm afraid it could lead to some hard to detect errors.
Andrzej
This archive was generated by hypermail 2b28 : Thu Jan 09 2003 - 14:51:49 PST