How do I evaluate expression with mixed real/integer operand

M

Mike

Guest
Hello,

I understand the expression size and expression signed-ness from the
P1364-2005-D3 spec (relevant info cut/paste at the end of my message).

Ignoring self-determined sub-expressions, I figure out the maximum
operand size and check to see if any operand is unsigned. Then I take
this size and sign and propagate them down the entire expression tree
to coerce every operand.

I am still confused about an expression where one operand is a real
and all the others are regs. Is the process similar to signed-ness?
Do I check to see if any operand is real, and if yes, then propagate
"real" down the entire expression tree to coerce every operand to real?
Or is there some local real->reg or reg->real conversion local to the
sub-expression operands and/or result? Or something else?

Thanks in advance,
Mike

<from P1364-2005-D3, section 4.5.1>
For non-self-determined operands the following rules apply:
- if any operand is real, the result is real;
- if any operand is unsigned, the result is unsigned, regardless of the
operator;
- if all operands are signed, the result will be signed, regardless of
operator, except as noted.

4.5.2 Steps for evaluating an expression
- Determine the expression size based upon the standard rules of
expression size determination.
- Determine the sign of the expression using the rules outlined in
4.5.1.
- Coerce the type of each operand of the expression (excepting those
which are self-determined) to the type of the expression.
- Extend the size of each operand (excepting those which are self-
determined) to the size of the expression. Perform sign extension if
and only if the operand type (after type coercion) is signed.
 
The LRM description of how reals are handled is incorrect (or at least
misleading). They are treated very differently from size and
signed-ness, which are done as early as possible. The conversions to
real are done just before they are needed. As you put it, they are
more local.

If a context-determined operand is in a "real" context (i.e. another
context-determined operand of the operator is real, which generally
means the result will be also), then it is evaluated as self-determined
and then converted to real just before the operator is applied. So if
you had something like

16'd0 - ((1.5*(3'b011 + 4'b1111))/2)

The left operand of the * is real, so the result of the * will be real.
The sum will therefore be evaluated as self-determined, in a 4-bit
width, giving 2, and converted to real, giving 2.0. That will be
multiplied by 1.5, giving 3.0. The left operand of the / is real
(since the result of the * is real), and the right operand of the - is
real (since the result of the / is real). So their other operands will
be evaluated and converted to real before the divide and subtract. The
result will be -1.5.

One of these days I need to figure out how to fix the description in
the standard.
 

Welcome to EDABoard.com

Sponsor

Back
Top