Paul_L_Schauble@cup.portal.com (05/13/88)
I'm presently working on maintaining a Fortran compiler for a mainframe
computer manufacturer. I've had a few requests lately that I'd like to
throw out for opinions. Flames accepted too.
The machine in question is a segmented architecture. Each segment has its
own size and read/write permissions. Unfortunately, the hardware only
permits 512 segments visible at one time, so they can't be used for
individual arrays. The compiler has basic scalar optimization and automatic
vectorizing.
The first program is this
program main
real a(10000), b(10000)
...
call sub (a, b, 10000)
...
end
subroutine sub (a, b, n)
real a(1), b(1) <-- note dimensions
do 1 i = 1,n
1 a(i) = complex expression with a(i) and b(i)
....
The vectorizer looked at this and said that the maximum size of the array
is 1, therefore the maximum subscript is 1 and the vector temporary needed
in the subroutine only needs to be one word long. Of course, the real
vector size in n.
Second program is this
program main
...
common /one/ a(1)
common /two/ space(100 000)
common /tre/ alast
...
c calculate sizes of sub arrays
il1 = something
il2 = something else
il3 = yet more
c calculate starting points of sub arrays
ist1 = 1
ist2 = ist1 + il1
ist3 = ist2 + il2
c call working subroutine
call subbr (a(ist1), a(ist2), a(ist3), il1, il2, il3)
...
end
subroutine subbr(x, y, z, ilx, ily, ilz)
real x(1), y(1), z(1)
c long calculation using x, y, z as arrays ilx, ily, and ilz long
...
end
It's an interesting attempt at dynamic storage allocation. This is from the
CERN library, which is appearantly popular in Europe.
My problem is that the compiler puts each common block in its own segment,
so that all of the references to a produce segment protection faults.
Now, I know that both of these are non-standard. The last not only assumes
that all of common is in one segment but also assumes the order in which
the common blocks are laid down in memory. The technique would work if used
within a common block.
But they become significant issues to me when the customer bugs my
management to change the compiler to support these programs! They say that
they don't want to change their code.
I wonder of other compiler groups have hit these issues, and, if so, what
have you decided to do about them? Is there really a significant amount of
Fortran code out there that does this type of thing? Is it really possible
to do Fortran on a segmented architecture machine or do prevailing coding
practices rule it out? My thought is that these practices were ruled out of
the standard for very good reasons. But the customer is still always right.
Thanks in advance for any information,
Paul_L_Schauble@cup.portal.com or sun!portal!Paul_L_Schauble
...geoff@desint.UUCP (Geoff Kuenning) (05/15/88)
In article <5377@cup.portal.com> Paul_L_Schauble@cup.portal.com writes: > subroutine sub (a, b, n) > real a(1), b(1) <-- note dimensions Since variable dimensions have been part of standard Fortran for over ten years, there is little excuse for using this older technique. However, it used to be very popular, so I suppose the customer has an argument in expecting the compiler to support it. Isn't the vectorizer smart enough to see that the loop overruns the array? > common /one/ a(1) > common /two/ space(100 000) > common /tre/ alast This is totally unacceptable. In particular, I have used Fortran compilers (actually linkers) that created common in order of declaration, and others (e.g., DEC, I think) that sorted it into alphabetical order. This code would not work on a DEC, since "alast" would precede "space". The standard explicitly and loudly prohibits assumptions about the order of common. In this case, I think you should tell your customer to read the standard and stuff his program in a certain dark place. -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
franka@mmintl.UUCP (Frank Adams) (05/17/88)
In article <5377@cup.portal.com> Paul_L_Schauble@cup.portal.com writes: > real a(1), b(1) <-- note dimensions At least one Fortran compiler I have used generated faster code with these declarations than with the alternative a(n), b(n). The latter did some initialization, even when it wasn't used. I would recommend that you regard a dimension of 1 for an argument as meaning that the dimension is undefined. It's not pretty, but it works. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
rmarks@KSP.Unisys.COM (Richard Marks) (05/18/88)
In reply ot Paul L Schauble's article: (mail to him @cup.portal.com bounced):
brings back old memories. Two quick answers:
1. segmented architecture machines can handle fortran (Burroughs B5500)
2. both cases are clear Fortran Errors.
The bottom line is that it is going to cost someone to get these programs
running on your machine. The programs do to work on some machine. What
is the cost of buggering the compiler to make them work on your machine, what
is the cost of upgrading the users code, and how much money will you guys make
from the user as a customer?
I worked a lot on the B5500 Fortran compiler in 1970s. The B5500 is a segment
architecture machine. I just automatically broke the large arrays into
hunks and dynamically figured out what segment each hunk was in. A segement
was 1024 bytes, the standard trick (in all languages) was to use the low 10
bits for the index into the segment and the high bits to tell which segment.
All pretty obvious stuff.
However, THERE IS NO GUARANTEE THAT NAMED COMMON WILL BE CONTIGUOUS!!
Also when passing variable length arrays to a subroutine, the formal params
should be declared as so:
subroutine sub(a, b, n)
real a(n), b(n)
Richard Marks
rmarks@KSP.unisys.COM