forums.silverfrost.com

[mecej4]

[mecej4]

COMMON has one bad property that one must contend with. It forces a specific order on sets of variables, when in most cases the user wishes to access just a few members the block as it it contained an unordered set -- just those variables in one or more common blocks that are needed in a subroutine.

Here is an example, that AKS brought up in his recent posts. The US Navy SMP program contains scores of subroutines. Many subroutines are about 100 lines of code, of which about 80 lines are COMMON and type declarations. Most of the variables in the common blocks are never used in the subroutine, but they have to be present (and their types declared if leaving the types implicit based on the initial letter is going to affect the memory layout).

https://apps.dtic.mil/sti/citations/ADA282341

[LitusSaxonicum]

Mecej4,

That is simply bad programming style, perhaps because the compiler first used had a limitation on the number of named common blocks. One could do the same bad thing in a module full of unused declarations, with the disadvantage that when such a module is USEd, you don't usually get to see those declarations when reading the source code, as you would not, for example, if the COMMON blocks were simply INCLUDEd.

The different lengths of variables is a 'useful stupidity' that arose when byte-orientated memory layouts became the norm: when one had two 24-bit words or a single 60-bit one, REAL and INTEGER were the same length. You lost the benefits of the same length while gaining a better utilisation of memory - but also usually created more problems of INTEGER overflow as shorter INTEGERs were the main benefit. Having implicit type (and I know that you don't like that, but I do) means that I can tell the variable type at a glance. Yep, and I know that you can stick to the I-N for integers convention with explicit typing, but explicit type declarations also make the declaration section longer than perhaps it strictly needs to be (your complaint, not mine), especially if you have a lot of local variables (I try to keep the number of those as small as possible).

I respectfully submit that the argument against COMMON in your observation is not so much an argument against a particular thing like COMMON, but is an argument against how it might be badly employed.

The same may be said against the use of a hammer, which may be used for driving in both nails and woodscrews, but although it may be used to get nails out (if it has a claw) is not so good for getting screws out, whereas a screwdriver is good for getting screws out as well as putting them in,so it must be superior - forgetting that a screwdriver is no good for driving nails in or getting them out. (Incidentally, a hammer is sometimes colloquially termed a 'Birmingham Screwdriver', and for some types of carpentry works it is far quicker at getting large woodscrews into rough timbers than a conventional screwdriver).I don't advise the use of this technique in aerospace applications, by the way!

You also find that some layouts, for example the traditional 80-column card format lead to lots of continuation 'cards', but of course, any statement that takes many lines of continuation has very little chance of being understood easily by anyone years after it was written, the fault lying not with the restriction on the length of each line, but in the complexity of the statement. Certainly, one can lay out the elements of an overcomplicated statement in a way that helps readability, but this is true whether one has a longer line length or spread it over several lines, and indeed the latter may prove preferable when printing or even using some editors.

To return to COMMON, it would be completely barmy to include a COMMON block in a subroutine that did not access any of the COMMON block's variables, and it is still barmy to put too much in a single COMMON block when you can divide the content over 2 or more. This was perhaps more obvious with the early Microsoft Fortran 77 versions where COMMON blocks were limited in any case to 64k, with the limit on how many blocks there were restricted by total memory and one's imagination in giving them names.

Eddie.
(Not from Brum, by the way)

PS. What happened to the old preference in FTN of starting arrays on 8-byte boundaries? Is it still a good idea? In which case how do we do it?

[mecej4]

My point is not that bad programming practices should be followed. It is that some aspects of old Fortran make it impossible or very tiresome and error-prone to do things right.

I have rarely come across large programs in which the order of the variables in COMMON was of any use or interest to the programmer. Rather, it makes the compiler's job easy and allows the symbol tables to be broken up into short blocks.

In the card-deck days, there was no INCLUDE 'abc.inc', and if you did not have a card duplicator, punching multiple sets of cards containing large common blocks was non-trivial.

On the other hand, many small common blocks increase the load on the linker. You may remember MS Fortran 3.3 and MS Link on MSDOS. Sometimes it took longer for the linker to finish than for the compiler to process the many source files that were part of a large program.

Hollerith strings longer than 56 characters form another example.

[LitusSaxonicum]

That's interesting. I don't think that I ever timed a linker, but you may have a point. I always thought that the MS Fortran linker had a bigger job than the compiler, which in the first version(s) I used had 2 completely separate passes, and I never compiled a whole program in one go after moving to a PC until relatively recently. I would expect compiling a single subprogram to be quick. In any case, the whole process on a PC was infinitely faster than sending a deck of cards off in a box with a courier, and waiting until the end of the day or the next day to get the results back. It was also faster than waiting for the normal day to end and getting the computer room key so that the mainframe machine could be restarted, in the case of a machine I used for some years by operating big circuit breakers like the ones in Frankenstein's lab! The margin of difference was so huge that it didn't occur to me until I got my second PC that 'virtually instant' could actually be speeded up.

Oddly, I never found that duplicating cards was a big job, using 026 and 029 card punches - but I do find it tedious with cut and paste. This must surely be to do with the pace at which one can work nowadays. (And there aren't that many of them to duplicate if you have arranged your COMMON blocks appropriately. (I don't think that I had any views about the order of variables in a particular COMMON block, what I hoped that I was saying was that the choice of variables that go in particular COMMON blocks can impact on what is needed for particular subprograms, and therefore it didn't make sense to have large sections of COMMON blocks in any subprogram).
Also, I found that IBM card punches could also copy a card that the reader had mangled, usually without too much difficulty.

You said somewhere that you worked originally on CDC machines, and the high speed card reader on a 6400 at Imperial College could, on occasions, spew 500 or so cards in the air in a matter of seconds. Afterwards, it wasn't just a matter of getting them back in order, it was also a question of replacing those that were irreparable or missing.

And anyway, wasn't card punching mainly a job for that room with four or more middle-aged women who punched the cards (or tape) from coding sheets while discussing the previous night's episode of Coronation Street and filling the air with cigarette smoke? Or the card duplicator that could punch n copies of a small deck? (If you could get it working, that is. Mostly the effort wasn't worth it, and the hardly-used duplicator was scrapped along with the worn out punches and the computer that had become a museum piece.)

I fear that we'll never agree on the ancient v. modern approaches, but I found your comments particularly valuable, as it never occurred to me that COMMON blocks made the compiler's job any easier. One lives and learns.

Eddie