an intermittent error
anal...@hotmail.com
write (6,fmt) a,b,c,d,charfu(e,f,g)
where charfu is a character function in which internal i/o takes place
(e,f,g are written on charfu).
sometimes this blows up and at other times it goes through. It is
annoying to have to store charfu in a local character variable only
for the output.
I woudl appreciate any help. Thanks.
Gib Bogle
Why is this annoying? Also, what do you mean by "blows up"?
dpb
Sorry, you're not going to get much.
That is reentrant i/o and not allowed at least thru F95. I suppose it
could have been relaxed in later Standards but I'd be somewhat surprised
if it were.
--
glen herrmannsfeldt
> Sorry, you're not going to get much.
> That is reentrant i/o and not allowed at least thru F95. I suppose it
> could have been relaxed in later Standards but I'd be somewhat surprised
> if it were.
I thought it was, I believe in Fortran 2003, specifically for
the case of internal I/O. See the third paragraph of 9.11.
(Specifically for this type of problem.) I believe that
external I/O is still restricted, though.
-- glen
James Van Buskirk
> That is reentrant i/o and not allowed at least thru F95. I suppose it
> could have been relaxed in later Standards but I'd be somewhat surprised
> if it were.
Be prepared to be surprised by f2003, then. See N1601.pdf.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
robin
> > I have statements like
> >
> > write (6,fmt) a,b,c,d,charfu(e,f,g)
> >
> > where charfu is a character function in which internal i/o takes place
> > (e,f,g are written on charfu).
> That is reentrant i/o and not allowed at least thru F95.
It's actually recursive I/O.
This form has been available in PL/I since 1966,
along with I/O generally within any function (even if
in an I/O list).
Handy for debugging!
anal...@hotmail.com
> "dpb" <n...@non.net> wrote in messagenews:gststk$8go$2...@aioe.org...
> > analys...@hotmail.com wrote:
> > > I have statements like
>
> > > write (6,fmt) a,b,c,d,charfu(e,f,g)
>
> > > where charfu is a character function in which internal i/o takes place
> > > (e,f,g are written on charfu).
> > That is reentrant i/o and not allowed at least thru F95.
>
> It's actually recursive I/O.
>
> This form has been available in PL/I since 1966,
> along with I/O generally within any function (even if
> in an I/O list).
> Handy for debugging!
recursion/reentrant stuff is for those who want to write write-only
code.
why didn't they simply name the internal read/write macros intread and
intwrite - and you wouldn't have this stupid error condition.
One of these days I'll compile together the innumerable ways the
language has been burdened with self-sabotage of even some of its best
features.
David Flower
Even if it is allowed does not mean that compilers have got it right !
Dave Flower
Richard Maine
> On Apr 25, 3:32?am, dpb <n...@non.net> wrote:
> > That is reentrant i/o and not allowed at least thru F95. ?I suppose it
> > could have been relaxed in later Standards but I'd be somewhat surprised
> > if it were.
> Even if it is allowed does not mean that compilers have got it right !
While it doesn't mean compilers are certain to have got it right, I
would say the odds are quite high for this one. The selection of f2003
compilers to test it on at the moment is... slim.
But many recent compilers of prior vintages already do this as an
extension. I wouldn't really expect others to have troubles with it
either. In the 70's and 80's this would have been a big issue for some
compilers, which was presumably a lot of the reason for the prohibition.
I did use compilers where recursive I/O failed, sometimes in strange
ways. With today's compiler technology, I don't see it as likely to be
much of a problem.
I don't recall much in the way of objection form compiler vendors when
this feature was proposed for f2003. The feature was a bit of a tack-on.
Recursive I/O was required for derived-type I/O, which was one of the
features on the high-visibility approved list. (Derived-type I/O happens
to be my candidate for the f2003 feature with the worst cost/benefit,
but that's beside the current point). As long as some case of recursive
IO was to be allowed, it was proposed to also allow the case of internal
I/O, which is one place that has a particularly good cost/benefit;
recursive I/O is useful and often requested for internal files, and many
of the complications of defining the behavior don't come up. It does
need the vendors formatting code has to be re-entrant, but then it
usually is.
I'd agree that I wouldn't use it with pre-f2003 compilers because it is
nonstandard and some compilers might catch that, even if they could
handle it, and as I noted above, I have run into compilers where it
failed strangely. But if a compiler claims f2003 comformance, this would
not be anywhere near the list of problems I'd be very concerned about.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>David Flower <DavJF...@AOL.COM> wrote:
>> On Apr 25, 3:32?am, dpb <n...@non.net> wrote:
>
>> > That is reentrant i/o and not allowed at least thru F95. ?I suppose it
>> > could have been relaxed in later Standards but I'd be somewhat surprised
>> > if it were.
>
>> Even if it is allowed does not mean that compilers have got it right !
>
>While it doesn't mean compilers are certain to have got it right, I
>would say the odds are quite high for this one. The selection of f2003
>compilers to test it on at the moment is... slim.
>
>But many recent compilers of prior vintages already do this as an
>extension. I wouldn't really expect others to have troubles with it
>either. In the 70's and 80's this would have been a big issue for some
>compilers, which was presumably a lot of the reason for the prohibition.
>I did use compilers where recursive I/O failed, sometimes in strange
>ways. With today's compiler technology, I don't see it as likely to be
>much of a problem.
Sorry, Richard, it was trivial then, and many compilers of the 1960s
(let alone later) implemented it without problems. It was a big issue
for some compiler WRITERS, who hadn't updated their mindsets to 1960s
technologies. God alone knows why it took them into the 1990s to do
that.
A colleague of mine wrote a run-time system for IBM Fortran, which did
this without problems. I did it for other languages. I tried to
explain to the Santa Teresa people how much benefit THEY would gain
from doing it, but got nowhere until very much later - and that was
for unrelated reasons.
Regards,
Nick Maclaren.
Richard Maine
> In article <1iyrxyj.pucphp9urc5cN%nos...@see.signature>,
> Richard Maine <nos...@see.signature> wrote:
> >In the 70's and 80's this [recursive I/O] would have been a big issue
> >for some compilers,
>
> Sorry, Richard, it was trivial then, and many compilers of the 1960s
> (let alone later) implemented it without problems. It was a big issue
> for some compiler WRITERS, who hadn't updated their mindsets to 1960s
> technologies. God alone knows why it took them into the 1990s to do
> that.
You clearly know more about compiler technology of that day. I was a
user of them, but not very knowledgeable about their innards (not that
I'd claim to be a compiler expert today, for that matter).
How about things like the CDC? I recall that doing anything recursive on
the CDC was a PITA. Obviously, it was possible, but trivial? Perhaps it
was; I can't say that I have the data to know for sure.
Of course, some of that might have been a consequence of other parts of
the software rather than inherent in the system, but if one starts
having to redo things in many places, that is itself a complication.
Designing from the ground up is different from working in the context of
adding a feature to an existing system.
I'd also buy that the difficulties might be ascribed to the writers of
the original compilers. But then once you have existing compilers, is it
still trivial to add such a feature if the compilers were done with the
"wrong" mindset in the first place.
The standard needed to accomodate all systems, or at least all
significant ones. If a feature could be trivially implemented on all but
one system, and it was hard on that one, then that would not have been a
likely feature to standardize. In fact, that would almost have made it a
worse candidate than if it were hard on all systems, because the
standard would have been giving a competitive advantage, which isn't the
kind of thing that goes over well in standards.
glen herrmannsfeldt
> <nm...@cam.ac.uk> wrote:
>> In article <1iyrxyj.pucphp9urc5cN%nos...@see.signature>,
>> Richard Maine <nos...@see.signature> wrote:
>> >In the 70's and 80's this [recursive I/O] would have been a
>> > big issue for some compilers,
>> Sorry, Richard, it was trivial then, and many compilers of the 1960s
>> (let alone later) implemented it without problems. It was a big issue
>> for some compiler WRITERS, who hadn't updated their mindsets to 1960s
>> technologies. God alone knows why it took them into the 1990s to do
>> that.
> You clearly know more about compiler technology of that day. I was a
> user of them, but not very knowledgeable about their innards (not that
> I'd claim to be a compiler expert today, for that matter).
Having looked at what IBM did for Fortran and PL/I for S/360,
I would say that it depends. The OS/360 Fortran compilers
did static allocation, both for the compiler and for generated code.
(Especially since much of Fortan H is written in Fortran H.)
PL/I code was reentrant, and so was much of the PL/I (F)
compiler. Among other reasons, that slowed down the compiler
and object code on the smaller machines at the time. To me,
that was the main reason PL/I didn't get as popular as
it otherwise could have been.
> How about things like the CDC? I recall that doing anything recursive on
> the CDC was a PITA. Obviously, it was possible, but trivial? Perhaps it
> was; I can't say that I have the data to know for sure.
I would say that the biggest change toward recursion is in
support for C, and the writing of compilers in C. (For CDC,
Pascal might have been more important.)
> Of course, some of that might have been a consequence of other parts of
> the software rather than inherent in the system, but if one starts
> having to redo things in many places, that is itself a complication.
> Designing from the ground up is different from working in the context of
> adding a feature to an existing system.
The PDP-10 TOPS-10 Fortran compiler used a stack for return
addresses, but static allocation for data. Even when other
languages of the time supported recursion, Fortran still had
the static allocation mindset. The OS/360 compilers use
static allocation for the return address, too.
> I'd also buy that the difficulties might be ascribed to the writers of
> the original compilers. But then once you have existing compilers, is it
> still trivial to add such a feature if the compilers were done with the
> "wrong" mindset in the first place.
I believe that it is not. At some point, though, many compilers
were rewritten from the beginning. Fortran 77 and the increasing
popularity of C might have been part of it.
> The standard needed to accomodate all systems, or at least all
> significant ones. If a feature could be trivially implemented on all but
> one system, and it was hard on that one, then that would not have been a
> likely feature to standardize.
Depending on the popularity of that system, and how loud
its proponents were. There is the cost of I/O buffers, which
aren't all that big, but were significant in the early days
of Fortran. More specifically, the usual implementation of
Fortran I/O is a call to a library routine to start the operation,
specifying the unit, format statement (if any), etc. Then a
call for each I/O list element, (sometimes for each array element,
sometimes not), followed by one to complete the operation.
If the state information is statically allocated, it will be
overwritten in I/O recursion. Normally there is a buffer
for at least one record (line), which, before non-advancing
I/O, could be reused on subsequent I/O operations, but would
cause problems for I/O recursion. As the cost of memory
went down, those problems decreased.
> In fact, that would almost have made it a
> worse candidate than if it were hard on all systems, because the
> standard would have been giving a competitive advantage, which isn't the
> kind of thing that goes over well in standards.
Well, no-one went back to write Fortran 90 compilers for the
older, smaller machines. It might be nice to have one for
the 7090 or PDP-10. Any machine designed to run C code
will do fine with recursion in general, and recursive I/O
in particular.
-- glen
Jan Vorbrüggen
> its proponents were. There is the cost of I/O buffers, which
> aren't all that big, but were significant in the early days
> of Fortran. More specifically, the usual implementation of
> Fortran I/O is a call to a library routine to start the operation,
> specifying the unit, format statement (if any), etc. Then a
> call for each I/O list element, (sometimes for each array element,
> sometimes not), followed by one to complete the operation.
> If the state information is statically allocated, it will be
> overwritten in I/O recursion.
If we consider only the clearly useful part of recursive I/O, as Richard
says, namely allowing an internal I/O as part of a non-internal I/O
operation: The important point to note for an implementor of this
feature is that the internal I/O need not (perhaps should not?) use this
internal state information. All it needs to re-use is the format
conversion routines (which need not be re-entrant) and the format parser
itself - whether that needs to be re-entrant would depend on the
implementation, and in any case it would only have to support two
possible simultaneous operations. All very doable in the technology
(both soft- and hardware) of the day, as several compiler extensions
from the period supporting this show.
Jan
glen herrmannsfeldt
(after I wrote)
>> Depending on the popularity of that system, and how loud
>> its proponents were. There is the cost of I/O buffers, which
>> aren't all that big, but were significant in the early days
>> of Fortran. More specifically, the usual implementation of
>> Fortran I/O is a call to a library routine to start the operation,
>> specifying the unit, format statement (if any), etc. Then a
>> call for each I/O list element, (sometimes for each array element,
>> sometimes not), followed by one to complete the operation.
>> If the state information is statically allocated, it will be
>> overwritten in I/O recursion.
> If we consider only the clearly useful part of recursive I/O, as Richard
> says, namely allowing an internal I/O as part of a non-internal I/O
> operation: The important point to note for an implementor of this
> feature is that the internal I/O need not (perhaps should not?) use this
> internal state information.
Well, as far as I can tell in standard Fortran 66 it wasn't
possible to do recursive I/O. Fortran 66 was very restrictive
on what was allowed for a subscript expression. Likely the
most common extension, though, was to allow a general expression
as an array subscript, allowing for function calls. Many small
machines had Fortran 66 compilers.
But yes, by the time of Fortran 77 it shouldn't have been
much of a problem to allow for it.
> All it needs to re-use is the format
> conversion routines (which need not be re-entrant) and the format parser
> itself - whether that needs to be re-entrant would depend on the
> implementation, and in any case it would only have to support two
> possible simultaneous operations. All very doable in the technology
> (both soft- and hardware) of the day, as several compiler extensions
> from the period supporting this show.
Well, you need enough state to know where you are in a formatted
I/O operation. It isn't all that much, but it is still somewhat
easier not to have to save/restore that state.
-- glen
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>Richard Maine <nos...@see.signature> wrote:
>
>>> >In the 70's and 80's this [recursive I/O] would have been a
>>> > big issue for some compilers,
>
>>> Sorry, Richard, it was trivial then, and many compilers of the 1960s
>>> (let alone later) implemented it without problems. It was a big issue
>>> for some compiler WRITERS, who hadn't updated their mindsets to 1960s
>>> technologies. God alone knows why it took them into the 1990s to do
>>> that.
>
>> You clearly know more about compiler technology of that day. I was a
>> user of them, but not very knowledgeable about their innards (not that
>> I'd claim to be a compiler expert today, for that matter).
>
>Having looked at what IBM did for Fortran and PL/I for S/360,
>I would say that it depends. The OS/360 Fortran compilers
>did static allocation, both for the compiler and for generated code.
>(Especially since much of Fortan H is written in Fortran H.)
Which was precisely the issue. Not merely was it no easier, it was
a lot SLOWER than using a stack - as was demonstrated many times from
the days of Algol 60, Egtran etc. onwards. But the stuck-in-the-muds
were still hanging on to static allocation because they claimed it was
needed for efficiency well into the 1980s.
>PL/I code was reentrant, and so was much of the PL/I (F)
>compiler. Among other reasons, that slowed down the compiler
>and object code on the smaller machines at the time. To me,
>that was the main reason PL/I didn't get as popular as
>it otherwise could have been.
That had nothing to do with it. So were BCPL, ALGOL68C, Algol F and
a lot of other compilers, and the efficiency of their compilers and
code beat the living daylights out of Fortran, let alone PL/I.
Fortran fought back by having much better optimisation, but its call
overhead was dire; ALGOL68C had a more complicated linkage, and was
twice as fast as Fortran, and BCPL was four times faster. That is
why people inlined code by hand, used assigned GOTO for internal
procedures and so on.
PL/I's linkage was unbelievable. If I recall correctly, the main
compilers did a GETMAIN for every call, rather than using a normal
contiguous stack with extensions. That may have been option-dependent,
but I looked fairly deeply into its linkage when I replaced its Fortran
interface module by one that was a hundred times faster, and it was
gruesome for all options.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>Jan Vorbr?ggen <Jan.Vor...@not-thomson.net> wrote:
>
>> All it needs to re-use is the format
>> conversion routines (which need not be re-entrant) and the format parser
>> itself - whether that needs to be re-entrant would depend on the
>> implementation, and in any case it would only have to support two
>> possible simultaneous operations. All very doable in the technology
>> (both soft- and hardware) of the day, as several compiler extensions
>> from the period supporting this show.
>
>Well, you need enough state to know where you are in a formatted
>I/O operation. It isn't all that much, but it is still somewhat
>easier not to have to save/restore that state.
Eh? That's not how you do it. That's the insane way that the old
IBM run-time system was written - and it was insane even when written,
as they could have seen by looking at the code of the access methods.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>
>You clearly know more about compiler technology of that day. I was a
>user of them, but not very knowledgeable about their innards (not that
>I'd claim to be a compiler expert today, for that matter).
Nor me, but I am a run-time system expert (and have written several!)
>How about things like the CDC? I recall that doing anything recursive on
>the CDC was a PITA. Obviously, it was possible, but trivial? Perhaps it
>was; I can't say that I have the data to know for sure.
I don't know that system well enough, but the System/370 gave compilers
no help at all; the CDCs may have gone out of their way to make it
tricky, but I doubt they were much worse.
>Of course, some of that might have been a consequence of other parts of
>the software rather than inherent in the system, but if one starts
>having to redo things in many places, that is itself a complication.
>Designing from the ground up is different from working in the context of
>adding a feature to an existing system.
You don't need to do that. That's how Algol F, BCPL, ALGOL68C, Norcroft
C and many others did things - and I wrote run-time systems for two of
those.
>I'd also buy that the difficulties might be ascribed to the writers of
>the original compilers. But then once you have existing compilers, is it
>still trivial to add such a feature if the compilers were done with the
>"wrong" mindset in the first place.
No, of course, it isn't. But the first hurdle is overcoming the mindset
that static allocation is necessarily more efficient than dynamic, and
it is THAT mindset that I was referring to.
Regards,
Nick Maclaren.
glen herrmannsfeldt
(snip, I wrote)
>>Well, you need enough state to know where you are in a formatted
>>I/O operation. It isn't all that much, but it is still somewhat
>>easier not to have to save/restore that state.
> Eh? That's not how you do it. That's the insane way that the old
> IBM run-time system was written - and it was insane even when written,
> as they could have seen by looking at the code of the access methods.
However you do it, you have to keep the state for the two (or more)
separate. There are a few different ways to do that.
-- glen
glen herrmannsfeldt
> In article <gt2j68$3e9$1...@naig.caltech.edu>,
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>Having looked at what IBM did for Fortran and PL/I for S/360,
>>I would say that it depends. The OS/360 Fortran compilers
>>did static allocation, both for the compiler and for generated code.
>>(Especially since much of Fortan H is written in Fortran H.)
> Which was precisely the issue. Not merely was it no easier, it was
> a lot SLOWER than using a stack - as was demonstrated many times from
> the days of Algol 60, Egtran etc. onwards. But the stuck-in-the-muds
> were still hanging on to static allocation because they claimed it was
> needed for efficiency well into the 1980s.
1980's is getting a little late, but for many processors
static allocation is faster. In many cases dynamic allocation
requires some kind of indirect addressing, which is slower
on many processors. I agree it is worthwhile now, but it
is still there.
>>PL/I code was reentrant, and so was much of the PL/I (F)
>>compiler. Among other reasons, that slowed down the compiler
>>and object code on the smaller machines at the time. To me,
>>that was the main reason PL/I didn't get as popular as
>>it otherwise could have been.
> That had nothing to do with it. So were BCPL, ALGOL68C, Algol F and
> a lot of other compilers, and the efficiency of their compilers and
> code beat the living daylights out of Fortran, let alone PL/I.
> Fortran fought back by having much better optimisation, but its call
> overhead was dire; ALGOL68C had a more complicated linkage, and was
> twice as fast as Fortran, and BCPL was four times faster. That is
> why people inlined code by hand, used assigned GOTO for internal
> procedures and so on.
> PL/I's linkage was unbelievable. If I recall correctly, the main
> compilers did a GETMAIN for every call, rather than using a normal
> contiguous stack with extensions. That may have been option-dependent,
> but I looked fairly deeply into its linkage when I replaced its Fortran
> interface module by one that was a hundred times faster, and it was
> gruesome for all options.
At least by the time I knew it, PL/I (F) had its own routines
do do a big (well, maybe 4K was big) GETMAIN and then divide it
up to those that needed it.
There has been much work done in more recent years on faster
calling methods. Even so, it is hard to beat BALR and
STM (for saving the registers). If the callee knows which
registers it doesn't use, save time by not saving/restoring those.
-- glen
nm...@cam.ac.uk
Yes, but doing it right is SIMPLER than using static state. IBM had
several bugs where one I/O call left the state in a form where a
subsequent one on another unit went wrong (no recursion involved).
That simply wouldn't have happened in a stack-based design.
This all goes back to the Fortran versus Algol wars of the early
1960s, where one of the Fortran arguments was that a stack couldn't
be implemented efficiently. And, yes, that's before my time!
Regards,
Nick Maclaren.