From: Michael McNamara (mac@surefirev.com)
Date: Mon Nov 02 1998 - 12:02:48 PST
Proposals:
Proposal 1) System Task/Functions $swrite, $swriteb, $swriteo, $swriteh and $sformat
1.A) Add to the list in section 15.2:
-- Tasks that output data into registers
1.B) Insert a new section between 15.2.2 "File output system
tasks" and section 15.2.3 ""Reading data from a file", entitled:
"Formating data to a string".
1.C) The text of the new section as follows:
<table>
string_output_tasks ::=
string_output_tasks_name( output_reg, list_of_arguments);
string_output_task_name ::=
$swrite | $swriteb | $swriteh | $swriteo
variable_format_string_output_task ::=
$sformat( output_reg, format, list_of_arguments);
</table>
Syntax for string output system tasks
$swrite(output_reg, list_of_arguments);
$sformat(output_reg, format_string, list_of_arguments);
length = $sformat(output_reg, format_string, list_of_arguments);
The $swrite family of tasks are based on the $fwrite family of
tasks, and accept the same type of arguments as the tasks upon
which they are based, with one exception: The first parameter to
$swrite shall be a register variable to which the resulting
string shall be written, instead of a variable specifying the file
to which to write the resulting string.
The variable 'output_reg' is assigned using the Verilog's string
assignment to variable rules, as specified in section 4.2.3.
Optionally, these system tasks can be redefined (or additionally
defined) as functions that return the number of characters in the
resulting string before any truncation that would occur if the
register to hold the result is not large enough.
The system task $sformat is similar to the system task $swrite,
with a one major difference.
Unlike the display and write family of output system tasks,
$sformat always interprets its second argument, and only its
second argument as a format string. This format argument can be a
static string, such as '"data is %d"', or can be a register
variable whose content is interpreted as the format string. No
other arguments are interpreted as format strings. $sformat
supports all the format specifiers supported by $display, as
documented in section 15.1.1.2.
The remaining arguments to $sformat are processed using any format
specifiers in the 'format_string', until all such format
specifiers are used up. If not enough arguments are supplied for
the format specifiers, or too many are supplied, then the
application shall issue a warning, and continue execution. The
application, if possible, may statically determine a mismatch in
format specifiers and number of arguments, and issue a compile
time error message. Note that if the format_string is a register,
it may not be possible to determine it's value at compile time.
The variable 'output_reg' is assigned using the Verilog's string
assignment to variable rules, as specified in section 4.2.3.
Optionally, the system task can be redefined (or additionally
defined) as a function that returns the number of characters in
the resulting string before any truncation that would occur if the
register to hold the result is not large enough.
Proposal 2) Formating Binary Data
2.A) Add to Table 14-2 in section 15.1.1.2 "Format
specifications" the lines:
%u or %U Unformatted 2 value data
%z or %Z Unformatted 4 value data
2.B) Add the following paragraphs under the table:
The formatting specification "%u" (or "%U") is defined for writing
data without formatting (binary values). The application shall
transfer the 2 value binary representation of the specified data
to the output stream. This escape sequence may be used with any
of the existing display system tasks, although $fwrite should be
the preferred one to use. Any unknown or high-impedance bits in
the source shall be treated as zero. This formating specifier is
intended to be used to support transferring data to and from
external programs that have no concept of 'x' and
'z'. Applications that require preservation of 'x' and 'z' are
encouraged to use the "%z" i/o format specification.
The data shall be written to the file in the native endian format
of the underlying system (i.e., in the same endian order as if the
PLI was used, and the C language write(2) system call was
used). The data will be written in units of 32 bits.
Note to POSIX applications: It may be necessary to open files for
unformatted I/O with the "wb", "wb+" or "w+b" specifiers, to avoid
the systems implementation of I/O altering patterns in the
unformatted stream that match special characters.
The formatting specification "%z" (or "%Z") is defined for writing
data without formatting (binary values). The application shall
transfer the 4 value binary representation of the specified data
to the output stream. This escape sequence may be used with any of
the existing display system tasks, although $fwrite should be the
preferred one to use.
This formating specifier is intended to be used to support
transferring data to and from external programs that recognize and
support the concept of 'x' and 'z'. Applications that do not
require the preservation of 'x' and 'z' are encouraged to use the
"%u" i/o format specification.
The data shall be written to the file in the native endian format
of the underlying system (i.e., in the same endian order as if the
PLI was used, and the data were in a s_vecval structure(See
Section 22.35, Figure 21-7), and the C language write(2) system
call was used to write the structure to disk). The data will be
written in units of the native size of an integer on the machine,
which is typically 32 bits.
[NOTE TO YATIN: Section 22.35, but Figure 21-7???]
Note to POSIX applications: It may be necessary to open files for
unformatted I/O with the "wb", "wb+" or "w+b" specifiers, to avoid
the systems implementation of I/O altering patterns in the
unformatted stream that match special characters.
Proposal 3) Scanning Binary Data
A) Add to Section 15.2.3.3 "Reading formatted data"
after the paragraph
s Matches a string, which is a sequence of non whitespace
characters
the following two paragraphs:
u Matches unformatted (binary) data. The application shall
transfer sufficient data from the input to fill the target
register. Typically the data is obtained from a matching
$fwrite("%u",data), or from an external application written in
another programming language such as C, Perl or FORTRAN.
The application shall transfer the 2 value binary data from the
input stream to the destination register, expanding the data to
the four value format. This escape sequence may be used with any
of the existing input system tasks, although $fscanf should be the
preferred one to use. As the input data can not represent 'x' or
'z', it is not possible to obtain an 'x' or 'z' in the result
register. This formating specifier is intended to be used to
support transferring data to and from external programs that have
no concept of 'x' and 'z'. Applications that require preservation
of 'x' and 'z' are encouraged to use the "%z" i/o format
specification.
The data shall be read from the file in the native endian format
of the underlying system (i.e., in the same endian order as if the
PLI was used, and the C language read(2) system call was used).
Note to POSIX applications: It may be necessary to open files for
unformatted I/O with the "rb", "rb+" or "r+b" specifiers, to avoid
the systems implementation of I/O altering patterns in the
unformatted stream that match special characters.
The formatting specification "%z" (or "%Z") is defined for reading
data without formatting (binary values). The application shall
transfer the 4 value binary representation of the specified data
from the input stream to the destination register. This escape
sequence may be used with any of the existing input system tasks,
although $fscanf should be the preferred one to use.
This formating specifier is intended to be used to support
transferring data to and from external programs that recognize and
support the concept of 'x' and 'z'. Applications that do not
require the preservation of 'x' and 'z' are encouraged to use the
"%u" i/o format specification.
The data shall be read from the file in the native endian format
of the underlying system (i.e., in the same endian order as if the
PLI was used, and the data were in a s_vecval structure (See
Section 22.35, Figure 21-7), and the C language read(2) system
call was used to read the data from disk).
[NOTE TO YATIN: Section 22.35, but Figure 21-7???]
Note to POSIX applications: It may be necessary to open files for
unformatted I/O with the "wb", "wb+" or "w+b" specifiers, to avoid
the systems implementation of I/O altering patterns in the
unformatted stream that match special characters.
<p><p>Proposal 3) Opening binary files
A) Modify table 14-7 in section 15.2.1 as follows
change '"r"' to '"r" or "rb"'
'"w"' to '"w" or "wb"'
'"a"' to '"a" or "ab"'
'"r+"' to '"r+", "r+b", or "rb+"'
'"w+"' to '"w+", "w+b", or "wb+"'
'"a+"' to '"a+", "a+b", or "ab+"'
Change the sentence fragment in the paragraph after the table
from
'the type specified is "r" or "r+"'
to
'the type specified is "r", "rb", "r+", "r+b" or "rb+"'.
Add a paragraph after the above paragraph reading:
The "b" in the above types exists to distinguish binary files from
text files. Many systems (such as Unix) make no distinction
between binary and text files, and on these systems the "b" is
ignored. However, some systems (such as machines running NT or
Windows) will perform data mappings on certain binary values
written to and read from files that are opened for text access.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:01 PDT
and
sponsored by Boyd Technology, Inc.