Fortran - Q: ENTRY Argument List

Author

Q: ENTRY Argument List

Gary L. Scott

2004-03-27, 12:17 am

I have used a compiler in the past that would not allow differing ENTRY
statement argument types from the subroutine. I could shorten the
argument list (number of items) or rename the argument, but the type (or
at least the size in bytes) of each ENTRY statement argument had to
match those of the subroutine (it wasn't that it would not compile, it
just would not work, and I don't mean one isolated case, I had a library
of about 50 procedures and tried it in multiple procedures). This may
have led to my own confusion regarding entry statements. Must entry
statement argument list types/sizes match the enclosing subroutine's
argument list? This doesn't come up very often because I usually use
ENTRY only for making a short name alias but there are occasions for
more complicated solutions.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Richard Maine

2004-03-27, 12:17 am

"Gary L. Scott" <garyscott@ev1.net> writes:

> Must entry
> statement argument list types/sizes match the enclosing subroutine's
> argument list?

Um. Depends on exactly what you mean. There is only one
declaration for each name in a procedure (dummy argument or any other).
So there is no way for the same name to have two different declarations.
That isn't a restriction related to entry - there just isn't even a
syntax to say that a name has 2 definitions depending on how you
entered. So you can't have something like

subroutine sub(x)
real x
entry e(x)
integer x

That would just be 2 conflicting declarations for x - not one for
each entry.

However, the argument lists for different entries don't have to
have anything in particular in common. They could have completely
different dummies, or the same dummies in different orders.

You do have to make sure that you don't reference an unassociated
dummy. Dummies do *NOT* retain their association between calls;
the only dummies you can work with are the ones in the entry
that you came through. Ssome compilers have been known to allow
tricks here, but they are not standard and do *NOT* work with
other compilers.

--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

glen herrmannsfeldt

2004-03-27, 12:17 am

Gary L. Scott wrote:

> I have used a compiler in the past that would not allow differing ENTRY
> statement argument types from the subroutine. I could shorten the
> argument list (number of items) or rename the argument, but the type (or
> at least the size in bytes) of each ENTRY statement argument had to
> match those of the subroutine (it wasn't that it would not compile, it
> just would not work, and I don't mean one isolated case, I had a library
> of about 50 procedures and tried it in multiple procedures). This may
> have led to my own confusion regarding entry statements. Must entry
> statement argument list types/sizes match the enclosing subroutine's
> argument list? This doesn't come up very often because I usually use
> ENTRY only for making a short name alias but there are occasions for
> more complicated solutions.

From the Fortran 77 standard:

"The order, number, type, and names of the dummy arguments in an
ENTRY statement may be different from the order, number, type, and
names of the dummy arguments in the FUNCTION statement or SUBROUTINE
statement and other ENTRY statements in the same subprogram. However,
each reference to a function or subroutine must use an actual
argument list that agrees in order, number, and type with the dummy
argument list in the corresponding FUNCTION, SUBROUTINE, or ENTRY
statement. The use of a subroutine name or an alternate return
specifier as an actual argument is an exception to the rule requiring
agreement of type."

Then they give the following restrictions:

"Within a subprogram, an entry name must not appear both as an entry
name in an ENTRY statement and as a dummy argument in a FUNCTION,
SUBROUTINE, or ENTRY statement and must not appear in an EXTERNAL
statement."

No recursion, even if it is a different ENTRY point.

"In a function subprogram, a variable name that is the same as an
entry name must not appear in any statement that precedes the
appearance of the entry name in an ENTRY statement, except in a
type-statement."

Note that in a FUNCTION different ENTRY points may have a different
type. The explanations I used to see had all the ENTRY names
EQUIVALENCEd to the FUNCTION name. These rules seem to be
equivalent to the EQUIVALENCE rules, without stating it.

"If an entry name in a function subprogram is of type character, each
entry name and the name of the function subprogram must be of type
character. If the name of the function subprogram or any entry in the
subprogram has a length of (*) declared, all such entities must have
a length of (*) declared; otherwise, all such entities must have a
length specification of the same integer value."

"In a subprogram, a name that appears as a dummy argument in an ENTRY
statement must not appear in an executable statement preceding that
ENTRY statement unless it also appears in a FUNCTION, SUBROUTINE, or
ENTRY statement that precedes the executable statement."

This could be the one you are running into. I could see it
generating an error message when otherwise you might expect it
to work. With the proper combination of GOTO's and moving the
ENTRY statements up, it should work.

"In a subprogram, a name that appears as a dummy argument in an ENTRY
statement must not appear in the expression of a statement function
statement unless the name is also a dummy argument of the statement
function, appears in a FUNCTION or SUBROUTINE statement, or appears
in an ENTRY statement that precedes the statement function
statement."

"If a dummy argument appears in an executable statement, the
execution of the executable statement is permitted during the
execution of a reference to the function or subroutine only if the
dummy argument appears in the dummy argument list of the procedure
name referenced. Note that the association of dummy arguments with
actual arguments is not retained between references to a function or
subroutine."

This is sort of obvious, but the one above isn't as obvious.

Just for comparison purposes, in PL/I you are allowed to return
a different type than the type of the ENTRY actually used.
The usual conversion rules apply.

-- glen

Gary L. Scott

2004-03-27, 12:17 am

Richard Maine wrote:
>
> "Gary L. Scott" <garyscott@ev1.net> writes:
>
>
> Um. Depends on exactly what you mean. There is only one
> declaration for each name in a procedure (dummy argument or any other).
> So there is no way for the same name to have two different declarations.
> That isn't a restriction related to entry - there just isn't even a
> syntax to say that a name has 2 definitions depending on how you
> entered. So you can't have something like
>
> subroutine sub(x)
> real x
> entry e(x)
> integer x
>
> That would just be 2 conflicting declarations for x - not one for
> each entry.
>
> However, the argument lists for different entries don't have to
> have anything in particular in common. They could have completely
> different dummies, or the same dummies in different orders.
>
> You do have to make sure that you don't reference an unassociated
> dummy. Dummies do *NOT* retain their association between calls;
> the only dummies you can work with are the ones in the entry
> that you came through. Ssome compilers have been known to allow
> tricks here, but they are not standard and do *NOT* work with
> other compilers.

I knew I wasn't being specific enough. I have never had a problem with
other than the one compiler, I just continue to have a sinking feeling
that I'm courting disaster whenever I use entry. It's a 20 year old
memory, but what I seem to remember not working with one early version
of VOS F77 was:

subroutine one(integer1, integer2, integer3)

character*80 char1
integer*3 integer1, integer2, integer3

entry two(integer1, char1)

....

end subroutine

If I called entry TWO with an integer*3 variable and a (say 10
character) text string, the text string data would not be passed
correctly (don't remember if I determined exactly what the values were
but I think it only filled the first 3 characters of the string).

Anyway it appears that I can stop worrying.

>
> --
> Richard Maine
> email: my last name at domain
> domain: sumertriangle dot net

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Richard Maine

2004-03-27, 12:17 am

"Gary L. Scott" <garyscott@ev1.net> writes:

> Richard Maine wrote:

>
> subroutine one(integer1, integer2, integer3)
>
> character*80 char1
> integer*3 integer1, integer2, integer3
>
> entry two(integer1, char1)

Looks fine to me. I forgot to mention that in f66, many compilers had
entry as an extension, but there was a fair amount of variation in detail.
With the character variables, the above does look like f77, unless it
was an f66 with that extension also.

P.S. integer*3?

--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Ron Shepard

2004-03-27, 12:17 am

In article <405C421D.897FBE4A@ev1.net>,
"Gary L. Scott" <garyscott@ev1.net> wrote:

> subroutine one(integer1, integer2, integer3)
>
> character*80 char1
> integer*3 integer1, integer2, integer3
>
> entry two(integer1, char1)
>
> ...
>
> end subroutine

I ran into the same kind of problem once. Here is something that I
do with entry points.

subroutine onexxx(integer1, integer2, integer3, char1)

character*80 char1
integer*3 integer1, integer2, integer3

stop 'error onexxx() called'

entry one(integer1, integer2, integer3)
...

entry two(integer1, char1)
...

end subroutine

The general idea is that an entry point argument list is always a
subset of the main subroutine argument list. The main subroutine is
never called, only the entry points. That's why the stop statement
is the first executable statement.

With f77, this was the only way for a group of subroutines to share
local data. With f90 and later, modules can be used to achieve this
same kind of encapsulation. Modules are more flexible, and arguably
simpler, so it would be a good idea to switch when possible.
Furthermore, I think ENTRY is headed toward extinction. It is
currently either deprecated or obsolete, eventually it will not be
supported.

$.02 -Ron Shepard

James Van Buskirk

2004-03-27, 12:17 am

"Gary L. Scott" <garyscott@ev1.net> wrote in message
news:405C421D.897FBE4A@ev1.net...

> character*80 char1

> If I called entry TWO with an integer*3 variable and a (say 10
> character) text string, the text string data would not be passed
> correctly (don't remember if I determined exactly what the values were
> but I think it only filled the first 3 characters of the string).

In ISO/IEC 1539-1:1997(E), section 12.4.1.1 it says:
"If a scalar dummy argument is of type default character, the
length len of the dummy argument shall be less than or equal
to the length of the actual argument."

I would say that you might have some sort of problems even in
the absence of an ENTRY since the actual argument is shorter
than the dummy argument, especially if you attempted to assign
to the dummy in the subroutine.

You know, sometimes I am told that my examples of new-style
Fortran code can be hard to parse, but I think there are some
tricky things to look out for where ENTRY is involved, especially
with functions. Like, what do the restrictions on results mean
when the result length is given by a specification function?
The function result length is in principle different on every
invocation... well, here is an example showing that perhaps I
just don't get it as far as ENTRY is concerned:

module entry_test
implicit none
contains
function get_upper(x)
character(*), intent(in) :: x
character(my_len(x,'X')) get_upper
character(my_len(x,'x')) get_lower
character(my_len(x,'1')) get_number
character(my_len(x,' ')) get_space
character(my_len(x,'!')) get_punctuation
character temp(len(x))

temp = transfer(x,temp)
get_upper = transfer(pack(temp,scan(temp, &
'ABCDEFGHIJKLMNOPQRSTUVWXYZ') /= 0),get_upper)
return
entry get_lower(x)
temp = transfer(x,temp)
get_lower = transfer(pack(temp,scan(temp, &
'abcdefghijklmnopqrstuvwxyz') /= 0),get_lower)
return
entry get_number(x)
temp = transfer(x,temp)
get_number = transfer(pack(temp,scan(temp, &
'0123456789') /= 0),get_number)
return
entry get_space(x)
temp = transfer(x,temp)
get_space = transfer(pack(temp,scan(temp, &
' '//achar(9)//achar(10)//achar(13)) /= 0),get_space)
return
entry get_punctuation(x)
temp = transfer(x,temp)
get_punctuation = transfer(pack(temp,scan(temp, &
'!"#$%&''()*+,-./:;<=>?@[\]^_`{|}~') /= 0),get_punctuation)
return
end function get_upper

pure function my_len(x,char)
integer my_len
character(*), intent(in) :: x
character, intent(in) :: char
character temp(len(x))

temp = transfer(x,temp)
if(scan(char,'ABCDEFGHIJKLMNOPQRSTUVWXYZ
') /= 0) then
my_len = count(scan(temp,'ABCDEFGHIJKLMNOPQRSTUVW
XYZ') /= 0)
else if(scan(char,'abcdefghijklmnopqrstuvwxyz
') /= 0) then
my_len = count(scan(temp,'abcdefghijklmnopqrstuvw
xyz') /= 0)
else if(scan(char,'0123456789') /= 0) then
my_len = count(scan(temp,'0123456789') /= 0)
else if(scan(char,' '//achar(9)//achar(10)//achar(13)) /= 0) then
my_len = count(scan(temp,' '//achar(9)//achar(10)//achar(13)) /=
0)
else if(scan(char,'!"#$%&''()*+,-./:;<=>?@[\]^_`{|}~') /= 0) then
my_len = count(scan(temp,'!"#$%&''()*+,-./:;<=>?@[\]^_`{|}~') /=
0)
else
my_len = 0
end if
end function my_len
end module entry_test

program test
use entry_test
implicit none
character(80) line

write(*,'(a)',advance='no') ' Enter the string:> '
read(*,'(a)') line
write(*,'()')
write(*,'(1x,a)') get_upper(trim(line))
write(*,'(1x,a)') get_lower(trim(line))
write(*,'(1x,a)') get_number(trim(line))
write(*,'(1x,a)') get_space(trim(line))
write(*,'(1x,a)') get_punctuation(trim(line))
end program test

CVF says that I just don't get it; LF95 perhaps incorrectly
lets the above slide.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Gary L. Scott

2004-03-27, 12:17 am

Xref: kermit comp.lang.fortran:80985

Richard Maine wrote:
>
> "Gary L. Scott" <garyscott@ev1.net> writes:
>
>
>
> Looks fine to me. I forgot to mention that in f66, many compilers had
> entry as an extension, but there was a fair amount of variation in detail.
> With the character variables, the above does look like f77, unless it
> was an f66 with that extension also.
>
> P.S. integer*3?

24 bit words. Also integer*6.
>
> --
> Richard Maine
> email: my last name at domain
> domain: sumertriangle dot net

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Gary L. Scott

2004-03-27, 12:17 am

Ron Shepard wrote:
>
> In article <405C421D.897FBE4A@ev1.net>,
> "Gary L. Scott" <garyscott@ev1.net> wrote:
>
>
> I ran into the same kind of problem once. Here is something that I
> do with entry points.
>
> subroutine onexxx(integer1, integer2, integer3, char1)
>
> character*80 char1
> integer*3 integer1, integer2, integer3
>
> stop 'error onexxx() called'
>
> entry one(integer1, integer2, integer3)
> ...
>
> entry two(integer1, char1)
> ...
>
> end subroutine
>
> The general idea is that an entry point argument list is always a
> subset of the main subroutine argument list. The main subroutine is
> never called, only the entry points. That's why the stop statement
> is the first executable statement.
>
> With f77, this was the only way for a group of subroutines to share
> local data. With f90 and later, modules can be used to achieve this
> same kind of encapsulation. Modules are more flexible, and arguably
> simpler, so it would be a good idea to switch when possible.
> Furthermore, I think ENTRY is headed toward extinction. It is
> currently either deprecated or obsolete, eventually it will not be
> supported.

Better not be. It is very useful for creating library routines for
older versions of the language. The above is sort of what I'm doing.
The main routine is a Win32 API wrapper, but since F77 doesn't have
derived types (except as an extension), I have entry points that return
the applicable derived type component. I much prefer this design to
duplicating the entire procedure over and over (there are lots of
components in the structure).

>
> $.02 -Ron Shepard

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

Richard Maine

2004-03-27, 12:17 am

Ron Shepard <ron-shepard@NOSPAM.comcast.net> writes:

> Furthermore, I think ENTRY is headed toward extinction. It is
> currently either deprecated or obsolete, eventually it will not be
> supported.

Although I personally recommend against using ENTRY, it is not
obsolescent (or deprecated, obsolete, or any other such thing)
in the standard. It has as full status as any other feature.

There may be some texts that give it some such label, but if
so, that is solely a judgement of the authors of the text. It
has no standing other than that.

Again, although I personally agree, I feel it important to
distinguish personal recommendations from statements of the
standard.

(As an irrelevant aside, generally this group is pretty good about
that, but there are a small number of people on the group - not
including you - who regularly project the attitude that anything they
utter is unquestionable fact, even when the utterances are broad
generalizations that include such things as the motivations of people
in various loosely labelled categories. Tends to remind me of
racial stereotyping; I suppose it figures that the worst offenders
tend to hide behind pseudonyms.)

--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Richard Maine

2004-03-27, 12:17 am

"James Van Buskirk" <not_valid@comcast.net> writes:

> "Gary L. Scott" <garyscott@ev1.net> wrote in message
> news:405C421D.897FBE4A@ev1.net...
>
[color=darkred]
> I would say that you might have some sort of problems even in
> the absence of an ENTRY since the actual argument is shorter
> than the dummy argument, especially if you attempted to assign
> to the dummy in the subroutine.

Oh. I hadn't paid that much attention to the code in this example,
but indeed. Don't do that, ENTRY or no. It is nonstandard and will
*NOT* work correctly on many compilers; and that is "many" or "most",
not just "some". Just last w

, this newsgroup helped someone debug
that exact problem - passing a short actual argument to a longer
dummy. It causes corruption of nearby memory.

I recommend that dummy character arguments almost always be
assumed length. If you have a special case where they need to
be anything else, then you have to ve *VERY* conscious of the
potential problem and check every call (particularly with
f77-style implicit interfaces).

--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Ron Shepard

2004-03-27, 12:17 am

In article <m2znaa5cpd.fsf@vega.dsl.att.net>,
Richard Maine <nospam@see.signature> wrote:

>
> Although I personally recommend against using ENTRY, it is not
> obsolescent (or deprecated, obsolete, or any other such thing)
> in the standard. It has as full status as any other feature.

I stand corrected, my memory must be faulty.

BTW, I should have said in my original post that it is always
possible to convert a subroutine plus a set of N entry points into
another subroutine with a set of N+1 entry points that behaves, to
any calling program, exactly the same as the original. That is,
this idea of creating a superset of all of the argument lists of all
the entry points for the (new) subroutine does not place any
practical restrictions on the programmer or on the API for the
programs that use those entry points. If your compiler gets

in the first case, then it is likely that it will work in
the second case, at least in my experience with f77 compilers.

$.02 -Ron Shepard

Gary L. Scott

2004-03-27, 12:17 am

"Gary L. Scott" wrote:
>
> Richard Maine wrote:
>
> I knew I wasn't being specific enough. I have never had a problem with
> other than the one compiler, I just continue to have a sinking feeling
> that I'm courting disaster whenever I use entry. It's a 20 year old
> memory, but what I seem to remember not working with one early version
> of VOS F77 was:
>
> subroutine one(integer1, integer2, integer3)
>
> character*80 char1
> integer*3 integer1, integer2, integer3
>
> entry two(integer1, char1)
>
> ...
>
> end subroutine

For the record, I usually use "character(*)" for argument declarations.
In the above referenced code, I always included an argument containing
the number of characters actually passed.

>
> If I called entry TWO with an integer*3 variable and a (say 10
> character) text string, the text string data would not be passed
> correctly (don't remember if I determined exactly what the values were
> but I think it only filled the first 3 characters of the string).
>
> Anyway it appears that I can stop worrying.
>
>
> --
>
> Gary Scott
> mailto:garyscott@ev1.net
>
> Fortran Library: http://www.fortranlib.com
>
> Support the Original G95 Project: http://www.g95.org
> -OR-
> Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
>
> Why are there two? God only knows.
>
> Democracy is two wolves and a sheep, voting on what to eat for dinner...
> Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

glen herrmannsfeldt

2004-03-27, 12:17 am

Gary L. Scott

2004-03-27, 12:17 am

glen herrmannsfeldt wrote:
>
> Gary L. Scott wrote:
>
> Could you post the generated assembly code for a small subroutine
> or function that does this? Functions with different return types
> are even more interesting, though I don't think it is quite as
> much of a problem as dummy arguments.

Oh heaven's no. It's a classified Harris H-1200/1000 dual processor
hosting an F-16 simulation package. I don't think I have a charge
number to spend 4 hours trying to get the source off of a 20 year old
9-track tape and then through security and public communications in
order to make a public posting to a news group. I don't think it's
likely to bite anyone else. I'm probably the only user left in the
world that might even think about using ENTRY statements on VOS. It's
scheduled to be decommissioned mid year. It still has way more
capability than the COTS-based replacements, but it costs an arm and a
leg to pay Harris to continue to support it. Oh well, at least the COTS
replacements have a pretty GUI, too bad its such a small subset of
capability (I guess they used all the budget writing the GUI).

> It is not unusual for compilers for languages without ENTRY to
> reference the argument list directly, often on the stack. That won't
> work if they can be different. Ones that I used to know generated
> a separate prologue and epilogue for each entry point, even if the
> argument list was the same. Each one then copies the argument or
> its reference to a local variable for use.

I looked in the VOS F77 programmer's reference on Friday. There is
nothing to suggest that it shouldn't work correctly.

>
> If one attempted to write a Fortran front end for to use with
> a C compiler back end, I could easily see this problem appearing.
> (C doesn't have entry, so there would be no way to express it.)
>
> I wonder what f2c does with ENTRY?
>
> -- glen

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

glen herrmannsfeldt

2004-03-27, 12:17 am

Gary L. Scott wrote:

> glen herrmannsfeldt wrote:

(snip)

> Oh heaven's no. It's a classified Harris H-1200/1000 dual processor
> hosting an F-16 simulation package.

There is a recent thread on comp.arch saying that Lockheed has
recently put the F-16 manuals into electronic form. It doesn't
say that they will be publicly available, but converting from
paper to electronic for isn't so common for a project that size.

>I don't think I have a charge
> number to spend 4 hours trying to get the source off of a 20 year old
> 9-track tape and then through security and public communications in
> order to make a public posting to a news group.

Well, I was mostly suggesting compiling as simple a program
as possible, which might show the problem.

INTEGER FUNCTION X(I)
X=2*I
RETURN
ENTRY Y(A)
Y=2*A
RETURN
END

That is about as simple as I could make it and actually
show the problem. Though at the time I was expecting
a more popular processor. If it did that, I would try:

INTEGER FUNCTION X(I)
GOTO 10
ENTRY Y(A)
Y=2*A
GOTO 20
10 X=2*I
20 RETURN
END

That might be enough to confuse the compiler as to which
entry point is used at each statement.

> I don't think it's
> likely to bite anyone else. I'm probably the only user left in the
> world that might even think about using ENTRY statements on VOS. It's
> scheduled to be decommissioned mid year.

Maybe they should see if the Computer History Museum is interested
in the hardware. I don't know much about Harris, though.

It still has way more
> capability than the COTS-based replacements, but it costs an arm and a
> leg to pay Harris to continue to support it. Oh well, at least the COTS
> replacements have a pretty GUI, too bad its such a small subset of
> capability (I guess they used all the budget writing the GUI).

-- glen

Gary Scott

2004-03-27, 12:17 am

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<IDs7c.55297$J05.431423@attbi_s01>...
> Gary L. Scott wrote:
>
>
> (snip)
>
>
> There is a recent thread on comp.arch saying that Lockheed has
> recently put the F-16 manuals into electronic form. It doesn't
> say that they will be publicly available, but converting from
> paper to electronic for isn't so common for a project that size.

Most of the impact is to the user. The TOs have been in electronic
form (various) "forever". They've been in PDF for quite some time.
They just weren't available via the internet. There have been
numerous studies over the years (decades) of how best to deliver
electronic versions. There is a laptop software loader that could
perform a dual role. So I think it's been mostly an issue of how best
to do it (and comfiguration management, user interface) rather than
size of the task. It's interesting that we tried electronic versions
on laptops for a while and the technicians complained that they were
less efficient than hard copies and went back to books. Newer
aircraft will have sufficient memory/throughput to host the
maintenance data/tools as part of the programming.

>
>
> Well, I was mostly suggesting compiling as simple a program
> as possible, which might show the problem.
>
> INTEGER FUNCTION X(I)
> X=2*I
> RETURN
> ENTRY Y(A)
> Y=2*A
> RETURN
> END

I would like to see if I could reproduce my 20 year old memory, but if
it were accurate, it would most likely involve a broken compiler and
one that most assuredly will not be fixed.

>
> That is about as simple as I could make it and actually
> show the problem. Though at the time I was expecting
> a more popular processor. If it did that, I would try:
>
> INTEGER FUNCTION X(I)
> GOTO 10
> ENTRY Y(A)
> Y=2*A
> GOTO 20
> 10 X=2*I
> 20 RETURN
> END
>
> That might be enough to confuse the compiler as to which
> entry point is used at each statement.
>
>
> Maybe they should see if the Computer History Museum is interested
> in the hardware. I don't know much about Harris, though.

I've suggested that to the museum. They didn't seem to be interested.
I'm not sure if we sell these older machines or junk them. Harris
still maintains a few of these around the country. Parts being in
short supply, maybe they'll take it for spares (still works
perfectly).

>
> It still has way more
>
> -- glen

glen herrmannsfeldt

2004-03-27, 12:17 am

Gary Scott wrote:

(snip regarding F-16 online documentation)

> Most of the impact is to the user. The TOs have been in electronic
> form (various) "forever". They've been in PDF for quite some time.
> They just weren't available via the internet. There have been
> numerous studies over the years (decades) of how best to deliver
> electronic versions. There is a laptop software loader that could
> perform a dual role. So I think it's been mostly an issue of how best
> to do it (and comfiguration management, user interface) rather than
> size of the task. It's interesting that we tried electronic versions
> on laptops for a while and the technicians complained that they were
> less efficient than hard copies and went back to books. Newer
> aircraft will have sufficient memory/throughput to host the
> maintenance data/tools as part of the programming.

There is a story that the Boeing 777 was designed completely on
computers. I am not sure what that really means, but the story goes
when the designers first saw the real plane they were surprised how
big it was. It might be that the traditional design methods
included scale models, and they didn't do that.

Sorry if we are getting a little off topic, but I would expect
that Boeing uses a lot of Fortran.

-- glen

beliavsky@aol.com

2004-03-27, 12:17 am

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<5dH7c.59299$JL2.763858@attbi_s03>...

<SNIP>

> There is a story that the Boeing 777 was designed completely on
> computers. I am not sure what that really means, but the story goes
> when the designers first saw the real plane they were surprised how
> big it was. It might be that the traditional design methods
> included scale models, and they didn't do that.
>
> Sorry if we are getting a little off topic, but I would expect
> that Boeing uses a lot of Fortran.
>
> -- glen

Boeing now sells some of its software, including Fortran code -- see
http://www.boeing.com/phantom/math_infosw/ .

Sponsored Links