Subject: Re: [sv-cc] Another directC C mapping question: unused bits, masking
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Feb 03 2003 - 13:58:22 PST
> From: "Andrzej Litwiniuk" <Andrzej.Litwiniuk@synopsys.com>
>
> Francoise wrote:
>
> > 1 st question:
> >
> > If we consider a 4 bits register:
> > reg [4:1] r;
> > to pass to a directC function, given what is proposed
> > it would be represented in C as a unsigned int where only the first 4 bits
> > would be
> > significant. I am assuming that the remaining bits would have to be filled
> > with 0s.
>
>
> Francoise,
>
> I know that you were concerned mainly with a signness of arguments,
> but you raised here another issue, that somehow missed my attention:
>
> "the remaining bits would have to be filled with 0s"
>
> DirectC should address the issue of the contents of unused bits (insignificant,
> remaining, whatever you want to call them).
> This is relevant not only for arguments passed by value as int, for 'small'
> function result also returned as int, but also for the canonical representation
> used internally, where not all 32 bits are used.
>
> I think that there are two possible approaches:
>
> 1) mask before use
> The contents of unused bits is undetewmined and those bits must be
> appropriately masked (or sign-extended) before a use.
>
> 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
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.
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.
Kev.
This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 14:00:00 PST