C vs. FORTRAN (was: What should be added to C)

[zben at umd5.UUCP]

In article <2157 at mit-eddie.MIT.EDU> barmar at mit-eddie.UUCP (Barry Margolin) :

>In article <900 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:

>>By the way, this does raise a question in my mind about how the convention
>>of 1, not 0, being the lower bound subscript for an array is gotten around
>>efficiently in implementations of Fortran.
>>... pain to have to subtract that pesky correction factor from the ag-
>>gregate subscript in coming up with an offset for the address of the array
>>element from the base of the array the way Fortran does, unless the computer
>>has a hardwired way of accessing an object in memory based on a base address
>>(base of the array), an offset (calculated from the subscripts), and a
>>correction factor (based on how the array was dimensioned) residing in regis-
>>ters and added together automatically.

>I think many mainframes have such addressing modes.

Of course, the simplest method of doing this is to decrease the base address
of the array by the correction factor.  This tack is taken on the Sperry 1100.
The major problem with it is making sure that the <base-offset> does not go
negative, as the two high bits in the address field on the Sperry enable the
automatic incrementation of the index register [i.e. (*p++) ] and indirecting
which can cause really funny things to happen.

So, the software kluge is that the compiler can create something called a
"minadr specification" in the relocatable binary, and the system linking
loader interprets that as a request to relocate that array "no lower than"
the specified address.  In the worst case it might have to move the segment
[Sperry calls them "banks"] start address above the default 40000 (8)...

Then there was the user who said:

CASE ZIPCODE OF
20904: ROUTE1;
20905: ROUTE2;
20906: ROUTE3;

and made the Pascal compiler generate [J $-20903,X] without a "minadr"...

-- 
"We're taught to cherish what we have   |          Ben Cranston
 by what we have no longer..."          |          zben at umd2.umd.edu
                          ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben