Subject: Re: CP-007 and CP-008: textio for std_logic_1164
From: Peter Ashenden (peter@ashenden.com.au)
Date: Wed Feb 19 2003 - 20:14:24 PST
On Thu, 2003-02-20 at 10:13, Rob Anderson wrote:
> I agree with this implementation, "warning". THen "error" if we hit
> the end of line; probable we also want to skip whitespace
> as a matter of course, but not the EOL.
Recall that we're reading from a string, not an input stream. So the
end of the line is defined by there being no more characters in the
string, not by coming across any particular character such as CR.
The read procedures in CP-007 do skip whitespace. To be consistent with
std.textio, whitespace is defined to be a sequence of space,
non-breaking space and horizontal tab characters. Other characters,
such as LF, CR, FF and VT, are not considered whitespace.
> Other issues:
>
> Do we extend hex to include X,Z, etc? And, do we want to
> select the case of hex digits (E.G. f vs F). perhaps a permissive
> reader and case-controlled writer would be best.
The oread and hread procedures in CP-007 allow reading X and Z, yielding
a sequence of 'X' and 'Z' elements respectively. The procedures also
accept lowercase and uppercase variations of hex digits A through F.
The owrite and hwrite procedures will write Z for a sequence of all Z
elements corresponding to an octal or hex digit.
> Also, does a line end in <lf> or <cr> <lf> ? Perhaps there could
> be a control for that as there is in some editors. It is annoying to
> run a tool under cygwin then have to "d2u" the file. Possibly this
> would be a VASG ISSUE.
As I mentioned above, a line is just a string. How the characters got
there from an input stream is not strictly relevant. For example, in my
test suite for std_logic_textio, I wrote:
L := new string'(" 01HL01");
test_ieee.std_logic_textio.read ( L, value_std_ulogic_vector_12 );
Usually, however, you'd get a string into the variable using the
READLINE procedure. In that case, the answer to your question is given
by the 1076 LRM in clause 14.3:
Procedure READLINE causes the next line to be read from the file and
returns as the value of parameter L an access value that designates an
object representing that line. ... The representation of the line does
not contain the representation of the end of the line. ...
The language does not define the representation of the end of a line.
An implementation must allow all possible values of types CHARACTER
and STRING to be written to a file. However, as an implementation is
permitted to use certain values of types CHARACTER and STRING as line
delimiters, it might not be possible to read these values from a TEXT
file.
Presumably, if a file was written using CR/LF as line delimiters and
read on a system that assumed just LF as the line delimiter, the CR
would be read into the string variable. If you're reading values of any
type other than character or string, encountering CR would not cause any
additional problems over encountering the end of the line. It's only a
pain if you're reading character or string values, since then the CR is
read into the character or string variable. So you're right: if it is
an issue, it is a VASG issue.
> > write(Output, to_string(now, right, 12) & " " & to_hstring(A_slv)) ;
> >
> > This to me would work quite well in lieu of printf.
> > Perhaps in a VHDL sense, it is easier than printf.
>
>
> I prefer this over printf. It is easy to control formatting in VHDL
> with this approach. It allows you to control the exact position of
> every character, something we have to do for finnicky file readers.
> I would not use printf, it is too obscure, there are non-compatible
> implementations all over the place.
Agreed. Let's see what the outcome of discussion is in VASG next week,
and make sure we coordinate.
Cheers,
PA
-- Dr. Peter J. Ashenden peter@ashenden.com.au Ashenden Designs Pty. Ltd. www.ashenden.com.au PO Box 640 Ph: +61 8 8339 7532 Stirling, SA 5152 Fax: +61 8 8339 2616 Australia Mobile: +61 414 70 9106
This archive was generated by hypermail 2b28 : Wed Feb 19 2003 - 20:17:45 PST