gsh7w@astsun1.acc.Virginia.EDU (Greg Hennessy) (04/21/89)
#In article <50500123@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: #> In some sicko implementations, and in pure ANSI F77 itself, you #>have to have a separate common block for characters (UGH!). In article <67044@pyramid.pyramid.com> (Mike Lipsie) writes: #If you allow equivalence #between CHARACTER and non-CHARACTER variables, you automatically have #non-portable code. # Is it just me or does this answer pertain to a different question? I don't see what EQUIVALENCE has to do with seperate common blocks. -Greg Hennessy, University of Virginia USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA Internet: gsh7w@virginia.edu UUCP: ...!uunet!virginia!gsh7w
weaver@prls.UUCP (Michael Weaver) (04/22/89)
In article <1390@hudson.acc.virginia.edu> gsh7w@astsun1.acc.Virginia.EDU (Greg Hennessy) writes: > >#In article <50500123@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >#> In some sicko implementations, and in pure ANSI F77 itself, you >#>have to have a separate common block for characters (UGH!). > >In article <67044@pyramid.pyramid.com> (Mike Lipsie) writes: >#If you allow equivalence >#between CHARACTER and non-CHARACTER variables, you automatically have >#non-portable code. ># > >Is it just me or does this answer pertain to a different question? I >don't see what EQUIVALENCE has to do with seperate common blocks. > Ahem. You are allowed to put different variable names into commons with the same name, thus aliasing variables. My guess is that the restriction on mixing character and integers in commons (and I have been bit by this one) has more to do with alignment (characters aligned to byte, integer to two or more bytes) and supporting characters on machines which really only know about words. Michael Gordon Weaver Signetics/Philips Components 811 East Arques Avenue, Bin 75 Sunnyvale CA 94086 USA Phone: (408) 991-3450 Usenet: ...!mips!prls!weaver
seibel@cgl.ucsf.edu (George Seibel) (04/22/89)
In article <1390@hudson.acc.virginia.edu> gsh7w@astsun1.acc.Virginia.EDU (Greg Hennessy) writes: ]#In article <50500123@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: ]#> In some sicko implementations, and in pure ANSI F77 itself, you ]#>have to have a separate common block for characters (UGH!). ]In article <67044@pyramid.pyramid.com> (Mike Lipsie) writes: ]#If you allow equivalence ]#between CHARACTER and non-CHARACTER variables, you automatically have ]#non-portable code. ]Is it just me or does this answer pertain to a different question? I ]don't see what EQUIVALENCE has to do with seperate common blocks. Yeah - although it's true that EQUIV's between char and other types is non portable. The point of not mixing character and other types in common has to do with data alignment, since character data might not fall on word boundaries. Beats me why it couldn't be padded out to the nearest word, though. That's probably what most implementations do; I've never seen a compiler that enforced the no-mixing rule. George Seibel, UCSF
kurtk@tekcae.CAX.TEK.COM (Kurt Krueger) (04/24/89)
There is a compiler that enforces separate common blocks for character and other data. A Fortran powerhouse - CDC. There are some real sticky issues about word alignment. Some machines HAVE to word align (the older CDC's for examaple). Other machines MAY or MAY NOT, but some of these machines have boundary requirements that differ for different data types. Both Gould and IBM (at least the 370 style machines) have byte addressibility but generate hardware faults if you try to fetch a full word that is not on a full word boundary. They may allow you to mix characters and full word data in the same common block, but proper alignment is usually up to you. Any goof and the code crashes. With all the possible archetectures, it is virtually impossible to write code with mixed character/full word data that won't cause grief on somebody's machine. VAXen can handle non aligned data, but only because of a special feature of the processor. Memory fetches are always aligned, but the processor can fetch twice and align it in a register. It works, but it slows things down. I know it's a pain to have two COMMON blocks where one should do. An easy way around this is to use whatever INCLUDE facility your system has. That way the code only has to mess with one INCLUDE, but both common blocks are defined in the included file.
bill@hcx2.SSD.HARRIS.COM (04/25/89)
Well, alignment is a consideration, but the real problem is the
"equivalencing" that can be done with COMMON. Consider the following
non-standard conforming program fragment:
SUBROUTINE SUB1
COMMON /C1/ A, B, C
INTEGER A(5), B(3), C(4)
...
END
SUBROUTINE SUB2
COMMON /C1/ D, E, F
CHARACTER*12 D
CHARACTER*2 E
CHARACTER*4 F
...
END
Can YOU think of a way to _portably_ define the relationship between A, B,
and C with D, E, and F? You would have to be able to do this, if you
want to allow mixing of CHARACTER and non-CHARACTER variables.
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.harris.com or hcx1!bill@uunet.uu.netsukenick@ccnysci.UUCP (SYG) (04/27/89)
>to the nearest word, though. That's probably what most implementations >do; I've never seen a compiler that enforced the no-mixing rule. Try the PDP-11 f77 compiler. It gets mad if you put mixed character and other types in common blocks; but it doesnt mind byte (a type extention) with integers, etc or if you equivalence a character to another type. But then again, it gets mad about a lot of things :-) BTW, is it ok to compare characters with logical operators eg: .or. .and. .gt. .lt. or is it required that you use the gt, lt, etc functions (77 & in 88)?