std.textio.read strange behaviour?!

[James Unterburger]

Here is a repeat of what I said in my post of 06/24/2008 01:28 PM
since (apparently) some interested parties have not been able to
see it:



If the out-of-range value is allowed, it is a bug.

See (1993 LRM) [2.1.1.1 Constant and variable parameters], line62:
After completion of the subprogram body, if the mode is INOUT or OUT,
the value of the formal parameter is copied back into the associated
actual parameter; it is similarly an error if, after applying any
conversion function or type conversion present in the formal part of
the applicable association element, the value of the formal parameter
does not belong to the subtype denoted by the subtype indication of
the actual.

Note that no "body" of the textio READ functions exist, but we do have
the functionality requirements described in [14.3 Package TEXTIO].
If we were to implement the READ functions in VHDL, there would be no way to
know the (scalar) subtype range of any actual associated with a mode OUT
formal inside the subprogram body, so it's safe to say that [2.1.1.1] does
apply, and not some internal (or external, if the GOOD formal is present)
mechanism, for catching out-of-range errors. Thus the range check must
occur after the value has been placed into the (variable) actual associated
with the VALUE formal for these READ subprograms. The value of the actual
associated with the GOOD formal (when present) does not reflect this
out-of-range error.

The reason the "b2 := byte" line does not error is that both sides of the
assignment are of the same subtype so no checking is needed (save the
case, say, when a bug causes the value of "byte" to be illegal).

The reason the "b2 := byte+0" line does fail is that the "+" operator
for (base) type INTEGER is used, and its return value can be (and will
be, in this case) outside the legal range for the target of the assignment,
so the necessary checking code is emitted as part of the compilation process.

If you change the WRITE(to_stdout...) call to use u8'image(byte) instead
of integer'image(byte), this too will error out (as it should) for illegal
value of "byte".

 

[Mike Treseler]

James Unterburger wrote:

Here is a repeat of what I said in my post of 06/24/2008 01:28 PM
since (apparently) some interested parties have not been able to
see it:

Thanks for resending. I did not see the previous version.

Note that no "body" of the textio READ functions exist, but we do have
the functionality requirements described in [14.3 Package TEXTIO].

Interesting.
A vhdl library function that
cannot be implemented in vhdl.
I can see where a sim vendor might miss this point.
Thanks for the clarification.

-- Mike Treseler

 

[James Unterburger]

Actually, I don't know if a body for textio can be written in VHDL or not,
but the LRM certainly does not specify one, it specifies only how the
subprograms must behave. The copy out rules in 2.1.1.1 apply nonetheless,
else we end up with untenable situations as shown in the testcase.


Mike Treseler wrote:

James Unterburger wrote:

Here is a repeat of what I said in my post of 06/24/2008 01:28 PM
since (apparently) some interested parties have not been able to
see it:


Thanks for resending. I did not see the previous version.


Note that no "body" of the textio READ functions exist, but we do have
the functionality requirements described in [14.3 Package TEXTIO].


Interesting.
A vhdl library function that
cannot be implemented in vhdl.
I can see where a sim vendor might miss this point.
Thanks for the clarification.

-- Mike Treseler

 

Thanks for your extensive answer. I don't have a copy of the LRM,
but it seems to be very precise about what to expect from the return
of procedure calls.

I have filed a service request to both modelsim/mentor and aldec.
Mentor acknowledges this as a bug, aldec didn't reply before I left
work.


Thank you all,
Regards -- Pontus