Path: utzoo!attcan!uunet!mcvax!philmds!leo From: leo@philmds.UUCP (Leo de Wit) Newsgroups: comp.lang.c Subject: Re: C vs. FORTRAN Message-ID: <550@philmds.UUCP> Date: 4 Jul 88 10:33:15 GMT References: <3136@phoenix.Princeton.EDU> <225800038@uxe.cso.uiuc.edu> <797@garth.UUCP> <5173@ihlpf.ATT.COM> <852@garth.UUCP> <546@philmds.UUCP> <30305@cca.CCA.COM> Reply-To: leo@philmds.UUCP (Leo de Wit) Organization: Philips I&E DTS Eindhoven Lines: 81 In article <30305@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: >In article <546@philmds.UUCP> leo@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.