From: Adam Krolnik (adamk@cyrix.com)
Date: Sun Sep 28 1997 - 22:48:50 PDT
Good morning:
Here are several comments that you can use in the meeting on this proposal.
Thanks for the work done on this.
<p>Does the following section imply that these will not be addressed, or that this
proposal isn't complete yet because it doesn't address these?
What is not included:
<ol>
<li>Reading and writing binary files.
<li>Opening pipes. (Named pipes do work)
<li>Opening sockets.
<li>Opening URLs.
I would hope that we could include definitions for reading and writing
binary files.
<p>The description of the parameters of these routines reads as:
"filename is a character string, or a register containing a character string that names the file to be opened."
Why couldn't filename be a net? a parameter, an input port? Same goes for other
parameters of the routines being defined.
module getFile(name, data, clk);
input[`FNMAX] name;
output[63:0] data;
input clk;
parameter type = "r";
integer fd;
initial begin
#1 fd = $fopen(name, type);
if (!fd)
begin
$display("ERROR: Couldn't open %s to read.", name);
$finish;
end
end
always @(posedge clk)
begin
amt = $fgets(data, fd);
end
endmodule
What should the definition of "code" be for all the routines. What is
the definition (the value) of EOF for code?
The definition of "c = $fgetc(fd)" is incoherent with the other definitions.
The other routines use a form of "code = $routine()". I think a better definition would be
code = $fgetc(fd, c);
This allows one to get the result code back separately from the value. Since
the result is larger than the value this also is a win since you don't need
to make the value larger to hold the code or the file value.
Along these same lines, "$fgets()" and "$ungetc() are the only routines that specifies the file descriptor as the second argument. If we like the idea of similar calling conventions, wouldn't a better definition of "$fgets()" be:
code = $fgets(fd, str);
code = $ungetc(fd, c);
Is "$ungetc()" useful enough to warrant inclusion in the spec?
The formatted data routines fscanf and sscanf specify,
"Both expect as arguments a control string, format, and a set of
arguments specifying where to place the results."
May the control string be a register containing a format string? May it be
a input port, a parameters, etc?
Also, specified in this section are the arguments
"If there are insufficient arguments for the format, the behavior is undefined. If the format is exhausted while arguments remain, the excess arguments are ignored."
As you all know, undefined behavior also includes core-dumping! It would be
nice for all implementations to compile time verify this if possible (E.g. when
the format string is actually there.)
The file output doesn't specify if the routines buffer data before writing it. It would be nice to have the ability to flush the buffers to disk, or specify
that no buffering should occur.
The current proposal relies on the existing definitions for file output. I would like to ask that we re-define the print format specifiers to respect
the size field rather than ignoring it.
E.g.
$fdisplay(fd, "%6s contains 6 characters. This number is %-20s",
"printf", "(right justified) 7");
<p><p> Adam Krolnik
Verification Engineer
Cyrix, Corp.
Richardson TX, 75083
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:42 PDT
and
sponsored by Boyd Technology, Inc.