Subject: Re: [sv-cc] Another directC C mapping question: unused bits, masking
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Mon Feb 03 2003 - 13:34:55 PST
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
This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 13:35:45 PST