C vs. FORTRAN

[Leo de Wit]

In article <30305 at cca.CCA.COM> g-rh at CCA.CCA.COM.UUCP (Richard Harter) writes:
>In article <546 at philmds.UUCP> leo at philmds.UUCP (Leo de Wit) writes:
>
>>So for static and 'static parameter list' variables. Even if you load
>>a register with the base of the list, you address the variables in it
>>relative to this base. That is as much computation as addressing relative
>>a frame pointer. On a paging system it may even take more, as the stack
>>pages are more likely to be in core than data pages - although a stack
>>pointer may behave weird, it will generally move in a relative small area.
>
>	I'm not sure I'm following this argument (or that it should be
>followed) but when has that ever stopped anyone.  Arguments about efficiency

The reason for me assuming a base register + offset addressing mode instead
of absolute addressing can be found below. Perhaps I should have been more
explicit.

>of different schemes are affected by how the hardware works.  In general,
>however, a static area calling sequence scheme will be more efficient than
>a stack scheme because the dirty work is done at link time rather than at
>execution time.  Attend:

 [stuff about address referencing inside function]

>Now, in a stack implementation, each reference to 'a' is of the form
>
>contents(fixed_offset + stack pointer)

 [talk about static references which eventually uses references like:]

>contents(fixed address)
>
>It doesn't necesarily work this way -- it is all a matter of how the system
>is set up.  But, given the supporting cast, static area calling sequences
>can be treated as globals.  In many machines absolute address globals will
>be faster than relative addressing; in many other machines there will be
>no difference.  It depends on the implementation of the instruction set.

This is simply NOT TRUE (or FALSE 8-), or, to be on the safe side,
there are a lot of cases in which the opposite holds. I don't know
which machines/architectures you are referring to, but I know of at
least one (quite popular) in which relative addressing is faster than
absolute addressing: the MC68000 and successors.

The reason is also quite simple: an absolute address (on the Motorola
32 bits) takes more bits to encode than a register relative address (on
the Motorola 16 bits; the addressing mode is called register indirect
with offset).  It takes more cycles to get the extra two bytes from the
bus than to perform the (short) implicit addition to a register.

That is the reason I suggested loading an address register also for the
static data, just because it makes the following stores/loads faster
(except if there are very few references, e.g. 1). Again, on the Motorola,
but I don't see why the same arguments shouldn't apply to other cpu's.

Here are some typical instruction sizes for the Motorola (assume a move
from a data register into memory):
register indirect: 2 bytes
register indirect with offset: 4 bytes
absolute: 6 bytes
If you move memory to memory, the situation gets even worse (assume two
address registers being used):
register indirect: 2 bytes
register indirect with offset: 6 bytes
absolute: 10 bytes

So instructions using the top of the stack (pushing & popping using 
register indirect, evt. combined with predecrement/postincrement) 
are MUCH faster, and the references of local variables (stack pointer
relative or frame pointer relative with offset) is faster than absolute
addressing (on several architectures).

I hope my point is made clear now: there are (quite a few) popular
cpu's for which register relative addressing is cheaper, if not much
cheaper than absolute addressing. Undoubtedly there will be others for
this is not the case (perhaps you should mention some for clarity,
since you talk about 'many architectures'). And this being the case, it
makes a good point in favor of stack addressing instead of static
absolute addressing, even when speed is at stake.

      Leo.