From: Stuart Sutherland (stuart@sutherland.com)
Date: Thu Oct 07 1999 - 21:19:59 PDT
Mac,
I agree with the principles of your arguments that two processes should be
able to write to different points in the same file. But, if I understand
the new features of $fopen correctly (always a big IF) I think there is a
flaw in your arguments.
You mentioned that an mcd file can be opened in append mode. It is my
understanding, however, that only the new fd (file descriptor) can open
files in append mode. The old behavior for $fopen is that a file is opened
as a new file each time $fopen is called -- there was no append mode for
mcd's. As a new file, The second $fopen will wipe out the file and
pointers being used by the first $fopen.
It is my understanding that for 1364-2000 the old "mcd" usage of $fopen is
to remain unchanged. That is, when $fopen is used without a second
argument, a new file is created, and an mcd is returned. The new "fd"
usage of $fopen is what opens a file in append mode, and would support
multiple file descriptors for the same file.
>From the PLI side, only mcd's are supported. The 1995 vpi_mcd_open()
remains unchanged, and only return mcd's (as is indicated by the routine
name). vpi_mcd_printf() also remains unchanged, and only writes to files
using an mcd -- using an fd with vpi_mcd_printf() is an error. The changes
we made for the 1364-2000 standard are only to document that the new fd
file descriptor is not supported by these routines. We decided not to add
new VPI routines to support the fd file descriptors for two reasons: It
would require adding several more routines to the VPI library, and it does
not add any capability that C can't do already (including, as you noted,
opening and appending to a file already open).
This leaves the original question unspecified in section 17 of the draft 3
LRM: What happens if $fopen is called twice on the same file? Perhaps the
answer is different for $fopen without its second argument (the old mcd)
versus $fopen with its second argument (the new fd).
And there is the objection you raised: Should vpi_mcd_open() be allowed to
'magically' return an existing mcd for a file that is already open?
>From my perspective, it makes sense to state for both $fopen without its
second argument, and for vpi_mcd_open(), that if the file is already open,
an mcd of 0 is returned (and perhaps a run-time error or warning is
generated).
It also makes sense for the two functions to do the same thing, so the BTF
and PTF should try to resolve this together, and soon.
That's my 2 cents worth. Now it's time for the real experts to jump in...
Stu
At 08:26 AM 10/7/99, Michael McNamara wrote:
>
>Stuart Sutherland writes:
> > BTF,
> >
> > In our PTF meeting today, it was noted that the draft 3 description
> > in section 17 for $fopen does not say if it is legal or illegal to
> > open the same file twice. By not saying anything, the implication
> > is that it is legal.
>
> That is correct.
>
> > In the VPI counterpart, vpi_mcd_open(), which only supports mcd
> > descriptors, we explicitly state:
> >
> > If the file has already been opened either by a previous call to
> > vpi_mcd_open() or using $fopen in the Verilog source code, then
> > vpi_mcd_open(), shall return the descriptor number.
> >
> > Please let us know what the intended behavior should be for $fopen.
>
>My expectation is that if you open the same file twice, you get two
>completely different file descriptors, which which you can do two
>completely different things, and hence which each might point to
>different parts of the file at any particular time.
>
>This is what unix would do in general, and does provide for the most
>flexibility. One could imagine usefully opeing a file twice in read
>mode, once say, to read top level documentation, and once walking
>through a section of the later instructions.
>
>I argue _strongly_ against vpi_mcd_open() having the 'magical' ability
>to latch on to the file descriptor of a file that happens to be
>already opened from verilog, and then moving that file pointer.
>
>Let me be clear: I have no problem passing a file descriptor from the
>verilog to the vpi, and allowing the vpi to perform operations through
>that passed file descriptor that modify data. This is wonderful.
>
>I also have no problems with vpi passing filedescriptors to verilog,
>for verilog's use.
>
>I also have no problem with the vpi appending data to the same
>verilog.log file. Since mcd's can only be opened for append (writing
>at the end), what you have in the vpi is ok. But I would have a real
>problem if you extended the vpi to be able to 'horn in' on a file
>descriptor opened for reading, or for random access writing, by
>$fopen.
>
>For example, given:
>
> fd = $fopen("program.exe", "rb");
> while (1) begin
> if (cde) begin
> cde = $fread(op, fd);
> if (cde) top.execute(op);
> end
> if(!cde) top.finish();
> end
>
>It is possible that the vpi could get invoked in the middle of this
>loop (say due to some call back), happen to open "program.exe", and
>get the same file pointer, move it around, and hence break the
>expected execution of the above loop.
>
>-mac
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:30 PDT
and
sponsored by Boyd Technology, Inc.