Re: Signed, Unsigned syntax issues. Please help, I'm stumped

"Jim Lewis" <jim@[EMAIL PROTECTED]
> wrote in message 
news:O9GdnawnGcWjz8jVnZ2dnUVZ_rDinZ2d@[EMAIL PROTECTED]
> Jonathan,
>> More im****tant still, it would prevent errors that are currently 
>> unavoidable: if you use := or <= to copy a fixed-point value from one 
>> place to another, and the target object is of the wrong subytpe, you
can 
>> get its
>> fixed-point scaling silently and disastrously screwed-up.
>
> For fixed point math, to address the range issue, this seems
> reasonable, but it also seems open other issues.  For example,
> if I use an intermediate object that is too small, overloading
> ":=" will automatically downsize it.
>

Another solution might be to allow a function access to attributes of the 
thing being copied to.  Similar to C++ and 'this', maybe a function that 
could get the range of the target with something like that'range.  So you 
could do

function blah(a, b:ufixed) return ufixed is
  variable ReturnVal: ufixed(that'range);
begin
....
return(ReturnVal);

Or (perhaps simpler), 'that' would be the thing that can be assigned to
and 
returned.  It would likely require the user of function blah to explicitly

define the range of the target so composing multiple function like

y <= blah(a, blah(b, c))

might not be possible....or maybe it could if the function would define
the 
range that *it* thought was correct, and just use that'range to error out
if 
the range wasn't appropriate.  In any case, it would give the function
some 
knowledge of attributes of the target beyond just the signal/variable
type.

Kevin Jennings