Subject: Re: [sv-cc] Another directC C mapping question: unused bits,
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Mon Feb 03 2003 - 14:29:27 PST
> > 2) invariant: unused bits are always filled with 0s (or a sign bit, depending
> > on the signness).
> >
> > The later approach seems less safe and less practical.
> > It would mean that for every operation that may partly fill a canonical
> > representation, leaving unused bits, the user would have to specify how
> > to fill the unused bits: with zeroes for unsigned values or with an extended
> > sign bit for the signed values. So, either a double version for each function
> > would be required, say, svGetPartSelectBitSigned()/svGetPartSelectBitUnsigned(),
> > or an additional argument secifying what to do with the remaining bits.
> >
> > Therefore I opt for 1).
> > It would apply for argument passing, for function result, and for the contents
> > of canonical representation, and, more generally, any representation where
> > not all bit are used.
> >
> > Andrzej
>
> KEVIN:
> In C you can define a bit field in a struct:
>
> struct {
> int bf:4;
> } foo;
>
> If you pass that to a routine:
>
> bar(foo.bf)
>
> it will be passed as a signed integer, i.e. 0xF would become 0xFFFFFFFF on
> a 32-bit machine.
True, but this is a wrong reasoning. Here the type of formal argument
is 'int', not a 4-bit value! C does not specify the contents of unused bits
for bit fields; compiler simply generates the necessary masking/shifting.
> It would therefore be reasonble to expect the same to happen with SV types
> like bit, and by extension logic, i.e. when copying a value with a smaller
> number of bits to another value, the value being copied is assigned to the
> least significant bits and its MSB is extended to fill the target if it
> is signed.
Kevin,
Let me repeat my reasoning:
> > It would mean that for every operation that may partly fill a canonical
> > representation, leaving unused bits, the user would have to specify how
> > to fill the unused bits: with zeroes for unsigned values or with an extended
> > sign bit for the signed values. So, either a double version for each function
> > would be required, say, svGetPartSelectBitSigned()/svGetPartSelectBitUnsigned(),
> > or an additional argument secifying what to do with the remaining bits.
For example, C Layer defines a function:
void svGetBitVec32(svBitVec32* d, const svBitPackedArrRef s, int w);
Neither of arguments specifies whether the packed array (to be copied into
a canonical array) contains a signed or unsigned value.
So what MSBits are to be filled with? Zero or a sign bit?
If you, or others, insist that unsused bits must be somehow set, then the signness
of a packed value must be provided somehow.
We may split 'svBitPackedArrRef' type into two types, for signed and unsigned
values, or split the function svGetBitVec32() into two variants, or add
another argument.
IMO such automatic sign-extension or zero-filling will be a useless overhead.
If all you want is to pass a value around, you don't care about the unused bits
of an intermediate representation.
Please note also, that the user may always specify the type of a formal argument
in SV as signed or unsigned int, or usigned or unsigned 32 bits, and then the SV compiler will take care of the proper coersion from, say, 4 bits (signed or unsigned) of an actual argument, to signed or unsigned int formal argument.
Andrzej
This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 14:30:53 PST