Prev: PGFIO-F-217, FORTRAN STOP
Next: Reading lines in free format (*) with an occational string
From: glen herrmannsfeldt on 30 Apr 2010 14:26
Gary L. Scott <garylscott(a)sbcglobal.net> wrote:
(big snip)

> Volatile should get it right for the case where a peripheral hardware
> device is DMAing data to/from a fixed memory location/port.

Within what the I/O system guarantees.

Does I/O necessarily fill the buffer from the beginning to the end?
(It doesn't in the case of tapes with the READ BACKWARDS option.)

Also, note that Fortran 2003 has the ASYNCHRONOUS attribute to
be used with ASYNCHRONOUS I/O.

-- glen
From: Gary L. Scott on 30 Apr 2010 15:34
On 4/30/2010 1:26 PM, glen herrmannsfeldt wrote:
> Gary L. Scott<garylscott(a)sbcglobal.net> wrote:
> (big snip)
>
>> Volatile should get it right for the case where a peripheral hardware
>> device is DMAing data to/from a fixed memory location/port.
>
> Within what the I/O system guarantees.
>
> Does I/O necessarily fill the buffer from the beginning to the end?
> (It doesn't in the case of tapes with the READ BACKWARDS option.)

It isn't really I/O, its just a large memory array at a fixed memory
starting address that never changes. The write sequence is sequential
in all cases, but the code does not assume that. There's a flag bit set
by the peripheral device to indicate when the buffer is full (or major
frame is complete) and the application is free to read it. The software
application provides a status back to the peripheral device when it can
be used again. Simple handshaking. So maybe volatile isn't needed
except, that there are times when (and other items) when you want to
read or write directly to those addresses (if they represent discrete,
analog, synchros, etc. Typically, those operate on a 20ms frame rate,
but for high speed recording, the host may want to sample faster and
instructions/commands are provided to do that at a high rate (15us or
so, although on my new system, i got it down to 7us...should be able to
do 500ns per hardware spec but Windows (mostly function call) overhead
is fairly high)

>
> Also, note that Fortran 2003 has the ASYNCHRONOUS attribute to
> be used with ASYNCHRONOUS I/O.

I've a long history with asynch I/O using BUFFERIN/OUT but that was for
getting those above fixed address recording buffers to tape or disk
without shutting down the interrupt handler. The main recording
procedure just passed the address of the next ready buffer to transfer
then goes back to waiting for the next interrupt. If it is for a
different channel, then it may be written to a different disk drive if
the data rate is too high for a single drive (once a significant problem
with 150ms disk access times). Of course, a merge process is required
at retrieval time.

>
> -- glen

From: Ron Shepard on 30 Apr 2010 19:35
In article <hrf7c4$qr1$4(a)naig.caltech.edu>,
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> Within what the I/O system guarantees.
>
> Does I/O necessarily fill the buffer from the beginning to the end?
> (It doesn't in the case of tapes with the READ BACKWARDS option.)

Data is certainly not read from the disk in that order. The disk
controller keeps track of where the heads are, which sectors need to be
read, and it starts reading the required sectors whenever they are under
the heads. If the required sectors are scattered around the disk, then
you would expect to get the information in all kinds of orders,
depending on how the heads were positioned over the disks at the
beginning. Also, modern disk drives have large buffer memories. If
your read request includes data that is both in and out of the hardware
buffers, then you might expect to get the buffered parts first as the
heads are being positioned for the nonbuffered parts. Finally there is
the possibility of striping the data over several disks. In this case
you might expect to get the data back in arbitrary orders from the
individual disks.

However, there may be several layers of buffers between the disk
controller and the user program, so by the time the fortran program
starts to get the data into its variables, it may have been reordered
into the requested order. I cannot think of any reason why this would
be desirable behavior. If this extra buffering were required somehow by
the language standard, all it would do is slow things down unnecessarily.

$.02 -Ron Shepard
From: glen herrmannsfeldt on 1 May 2010 08:19
Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote:
> In article <hrf7c4$qr1$4(a)naig.caltech.edu>,
> glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

>> Within what the I/O system guarantees.

>> Does I/O necessarily fill the buffer from the beginning to the end?
>> (It doesn't in the case of tapes with the READ BACKWARDS option.)

> Data is certainly not read from the disk in that order. The disk
> controller keeps track of where the heads are, which sectors need to be
> read, and it starts reading the required sectors whenever they are under
> the heads. If the required sectors are scattered around the disk, then
> you would expect to get the information in all kinds of orders,
> depending on how the heads were positioned over the disks at the
> beginning. Also, modern disk drives have large buffer memories. If
> your read request includes data that is both in and out of the hardware
> buffers, then you might expect to get the buffered parts first as the
> heads are being positioned for the nonbuffered parts. Finally there is
> the possibility of striping the data over several disks. In this case
> you might expect to get the data back in arbitrary orders from the
> individual disks.

Yes, it is usual now that once the proper track is found that
the drive starts reading blocks on that track into the internal
buffer. There is a good chance that those blocks will be requested,
and they will be supplied from the buffer. Even so, they are
read from the drive in the specified order.

> However, there may be several layers of buffers between the disk
> controller and the user program, so by the time the fortran program
> starts to get the data into its variables, it may have been reordered
> into the requested order. I cannot think of any reason why this would
> be desirable behavior. If this extra buffering were required somehow by
> the language standard, all it would do is slow things down unnecessarily.

There is a recent discussion in another newsgroup in LOCATE mode I/O.
At least OS/360, PL/I, and from the other discussion I believe VMS,
have locate mode I/O where at least one level of buffering is removed.

OS/360 can do I/O directly into the user data area, provided that
it is contiguous. That could be true for a single array or structure,
but likely not for a list of variables. For locate mode output,
one requests the address of the buffer from the OS, writes data
directly into the buffer, and then asks for it to be written.
Locate mode input works pretty much like any asynchronous input,
but the data could be written directly from the I/O device to
the destination without any buffering. For newer systems, that
probably means one fewer level of buffering than usual.

For the VMS version, that can mean padding of disk blocks such
that each I/O operation starts at the beginning of a block.

If you do locate mode I/O on a tape with READ BACKWARDS (that is,
a S/360 channel command) the data will be read into memory from
the end of the buffer toward the beginning.

-- glen
From: glen herrmannsfeldt on 1 May 2010 14:01
mecej4 <mecej4.nyetspam(a)operamail.com> wrote:
(snip, I wrote)

>> Remember, the OP did ask about optimization level 3.
>> As far back as Fortran H Extended even OPT=2 moved assignments
>> out of loops, and OPT=3 asked for the best the compiler could do.
>> (I haven't known any with levels higher than 3.)

> Sun Fortran goes up to -O5. Some versions of GCC allowed -O9. You may have
> had only mainframe compilers in mind, but the OP did not indicate any
> specific system.

According to the gcc (C compiler) man page that I have, it goes
up to -O3. It could have changed very recently, though.
I should try the Sun Fortran compiler sometime, but I haven't yet.

(and I also wrote)
>> I would agree if any of A, B, C, D, or W, were VOLATILE, and
>> probably also at lower optimization levels. But common
>> subexpression elimination goes back to Fortran I, and has
>> been a favorite of optimizers ever since.
(snip)

>> So my thought is that only loads of VOLATILE variables
>> need to go in the prescribed order. Others can be moved
>> around, especially with -O3.

> Why only loads? With VOLATILE, the compiler cannot say to itself, " ... I
> know that the value has not changed, and I wrote it into memory earlier, so
> I don't have to do a STORE again." The VOLATILE attribute says, "just do it
> when I tell you".

Yes stores also. But if W is not VOLATILE, then I don't see
the requirements applied to it, even from an expression with V.

Probably one should apply VOLATILE to other nearby variables
to be sure that the compiler does the right thing.

-- glen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: PGFIO-F-217, FORTRAN STOP
Next: Reading lines in free format (*) with an occational string