Talk:Addressing mode

Reason for article creation

Have started this as it had a link from RISC. Not very good yet, will look at more sometime. Mat-C 15:06, 17 Jul 2004 (UTC)

This is not correct

On some RISC machines, the effective address is obtained by using the top 4 bits of the current program counter with the 28 bits given in the instruction. This can be done because RISC

(This partial comment was left by Ruud_Koot on 23:52, 22 July 2005 (UTC) according to the talk page history. I am unsure what he was getting at. --Kelerain (talk) 03:12, 14 January 2008 (UTC))

OK, it's old, but Rudd was probably getting at MIPS (See any Patterson & Hennessy) refers to pseudo direct addressing, which uses high order 4 bits of PC + a 26 bit immediate offset shifted 2 bits to form a 32 bit address. Darned if I see it mentioned on this page, while thousands of students are taught it routinely.) Did I miss it? — Preceding unsigned comment added by 209.65.48.3 (talk) 16:13, 19 November 2013 (UTC)

The part on Multi-level memory indirect states that you can get an infinite loop trying if one reference to itself. This is not true as you would have to specify a level of deepness at the instruction, else we won't know when to end, and thus it isn't an infinite loop. —Preceding unsigned comment added by 84.218.39.128 (talk) 16:32, August 24, 2007 (UTC)

Multi-level indirect can result in an infinite loop in the case when a 'word' is bigger than an address and when one of the bits unused for the address is is used to indicate another level of indirect addressing (e.g. PDP-6, PDP-10), i.e. the level of deepness is NOT specified in the instruction. The addressing chain continues for as long as the indirect bits are set in each address referenced. If one of the addresses refers to some word earlier in the chain (including possibly itself) then a infinite indirection loop appears. Murray Langton (talk) 14:56, 3 March 2008 (UTC)

On the PDP-10, if you did create an infinite-address-loop, the CPU would time out the instruction and generate an interrupt. Mzellers (talk) 23:20, 27 September 2011 (UTC)

Index next instruction

My understanding is the machines mentioned in the "Index next instruction" section did something more like this when the "INDEX" instruction was executed:

• start loading the next instruction (possibly from ROM) normally
• Normally the CPU stores each instruction it reads into the IR (instruction register) -- but when executing the "index" instruction, instead it stores the *sum* into the IR -- the sum of the instruction currently being read and the accumulator.
• Then it goes on to executing the instruction in the IR normally.

So I think the "Index next instruction" section is slightly misleading in it's "self-modifying code" comment. This is very similar to self-modifying code, but it's not exactly the same -- the sum is not actually written back out to program memory, and it works exactly the same whether the instruction is in RAM or ROM.

Could someone with more expertise confirm if my understanding is correct? (Perhaps my understanding is incorrect, and these machines, like MIX, really do require self-modifying code, which must be placed in RAM -- ROM won't work).

If my understanding is correct, could you fix the "Index next instruction" section to make it more accurate? --68.0.124.33 (talk) 04:02, 15 March 2008 (UTC)

The description in the self-modifying code article of the "EXECUTE" instruction makes it sound similar to this "INDEX" instruction. Are they really the same, or is there some significant difference I am missing? --68.0.124.33 (talk) 05:12, 25 November 2010 (UTC)

Your interpretation is correct. I have modified the article (feel free to tweak the article more if it's still unclear) Murray Langton (talk) 11:01, 25 November 2010 (UTC)

Is 'Skip' in the right place?

'Skip' has been in the article as an addressing mode since March 2008. I agree that it should be in the article (it was the only conditional control intruction for Dec PDP-8 and Data General Nova), but I'm not sure if it is in quite the correct place within the article. Does anyone know of any current computers which use this addressing mode; if there are some significant current computers which use 'skip' I'll leave that section where it is (possibly with revised wording), if there are some relatively obscure current computers I propose to move that section further down under 'Other addressing modes', otherwise I propose to move it down under 'Obsolete addressing modes'. Murray Langton (talk) 15:25, 1 December 2008 (UTC)

Both the Atmel AVR instruction set and the PIC microcontroller instruction set has some instructions that use the "skip" addressing mode ( addressing_mode#skip ). All conditional instructions for PIC microcontrollers with "12-bit core" and the "14-bit core" use the skip addressing mode -- the only way to implement a loop on these chips is to use such a "skip" instruction to skip over an unconditional branch instruction. I've been told that Microchip sold more units of such microcontrollers in 2006 than the total unit sales of any other CPU manufacturer (still looking for a WP:RELIABLE reference that lists unit sales of the top CPU manufacturers in some recent year, even if it contradicts this rumor). I hope you agree with me that a CPU family that is apparently currently selling in higher volume than any other CPU family is "current" and "not obscure". --68.0.124.33 (talk) 19:15, 1 December 2008 (UTC)

Thank you for your prompt response. I agree that by sales volume it doesn't seem to be obscure; however I doubt if the micro-controllers you mention are all that well known, so I'll have to think about whether it stays where it is or moves down under 'Other addressing modes'. Murray Langton (talk) 21:56, 1 December 2008 (UTC)

On further thought I'm wondering if we need a new section 'Not an addressing mode' or similar to handle both the conditional instruction execution (ARM) and the 'skip' instruction. Any thoughts? Murray Langton (talk) 17:19, 2 December 2008 (UTC)

"well known": Is there some other other CPU that would be more well known, among people who solder or who use solderless breadboard? Just about every issue of Nuts and Volts for the past few years has a project for the PIC or the Atmel AVR (sometimes both). As far as I can tell, the PIC is more popular for ARRL projects than any other CPU.

The early PIC instruction set was designed decades ago, so it would be easy to say that it is "not current" -- but the same logic would force us to admit the x86 architecture instruction set is "not current" -- do we really want to admit that?

The ARM condition code and the conditional skip are functionally about the same -- so I agree that discussing them both in the same section is a good idea.

Perhaps also explicitly list in that section the normal, default, "execute the next sequential instruction" in order to comply with the WP:OBVIOUS guideline.

Perhaps call this section something like "sequential addressing"? --68.0.124.33 (talk) 21:39, 3 December 2008 (UTC)

Thanks for your suggestions. I'll meditate for a few days before changing anything. Murray Langton (talk) 08:39, 4 December 2008 (UTC)

I'm going to succumb to my completist tendencies, and add the one remaining way that the PC is modified. Because really, who wants to read a list of "Every possible way that the PC can be modified -- except for the most important one."? I'm making up a name for it off the top of my head -- we should probably find some references and adjust the name to what those references use. --68.0.124.33 (talk) 19:43, 8 December 2008 (UTC)

You mentioned the PDP-8; I see the PDP-8 and PDP-10 articles mention that they have "skip" instructions. I am tempted to mention the 4 CPUs we discussed in the "skip" section of this article. Is that a slipperly slope leading to every CPU ever built being listed under every addressing mode it supports? --68.0.124.33 (talk) 04:27, 18 December 2008 (UTC)

Unless an addressing mode is unique to a single computer family, I think it is probably better not to mention specific computers in relation to specific addressing modes. In the more general sections near the start of the article I think it may be reasonable to mention specific computer families as examples. Murray Langton (talk) 12:47, 18 December 2008 (UTC)

memory addressing mode in 8086

there are seven addressing modes in 8086 index,base,offset,index+offset,index+base,base+offset,index+base+offset —Preceding unsigned comment added by 116.71.188.163 (talk) 08:12, 16 February 2010 (UTC)

Comments on IBM mainframe (System/360, System/390 etc.) not correct

The references to addressing modes on IBM mainframe systems are misleading.

Until very recently there was only one way for application code to refer to operands or branch address and that was that all addresses are formed from a base address, an index address, and a displacement value. The Relative and Immediate Instruction Facility added instructions to address data using relative values. The size of the base and index values changed over the years from 24 to 31 and now 64 bits and the displacement has changed as well, but in all cases the instruction contained base and index register designations and the actual value of the displacement. Still, none of these things are called "addressing modes" in IBM terminology which by the way has a 50+ year history.

However...

In IBM terminology, addressing mode has to do with control register values and PSW (program status word) settings that determine how instructions and operands are fetched. There are 4 addressing modes in z/OS:

1 primary space mode (instructions and data fetched from current primary)

2 ASC AR mode (intructions fetched from current primary, data fetched depending on contents of access register)

3 secondary space mode (instructions fetched from current primary, data fetched from secondary)

4 home space mode (instructions and data fetched from home address space)

Applications receive control and run exclusively in mode (1) above, primary space mode. The application programmer has no knowledge of this and no control over it. None of the HLL languages or Java have any provision for changing modes nor do they have any mode awareness.

Systems software often runs in modes (2) or (3) above in addition to mode (1) above. Very rarely, pieces of operating system code run in mode (4) above, home space mode. This mode is mostly used for creating new address spaces and coordinating user work in them.

See SA22-7832-07 z/Architecture Principles of Operation at http://publibz.boulder.ibm.com/epubs/pdf/dz9zr007.pdf and SA22-7614-07 z/OS V1R11.0 MVS Programming Extended Addressability Guide at http://publibz.boulder.ibm.com/epubs/pdf/iea2a570.pdf for complete information. 77.126.191.239 (talk) 16:43, 28 April 2011 (UTC)

For better or worse, many of IBM's terms have not been adopted by the rest of the computer industry. Relatively few company speak of "storage" rather than "memory", or speak of "direct access storage devices".

In this particular case, I suspect that the term "addressing mode", used in the sense of this article, dates back to the PDP-11, as per, for example, the PDP-11/20 Handbook. In the PDP-11, the opcode did not specify whether the instruction operands came from a register or memory or, if it came from memory, how the memory address was formed; the operands were specified by a combination of a 3-bit addressing mode and a 3-bit register number. Some other instruction set architectures, such as the VAX and Motorola 68000 series, modeled themselves after the PDP-11 in that manner.

The GE-600 series used the term "address modifier", as per the GE-635 System Manual; however, it did not have the fully-orthogonal scheme that the PDP-11 did; one operand of an instruction would either be the accumulator, the multiplier/quotient register, or an index register, specified by the opcode, and the other operand would be in memory (so to move something from the AC to the MQ, you'd have to move it through memory).

In the PDP-6 and PDP-10 instruction sets, one operand would be a general-purpose register (called "accumulators"), and the other would be in "memory"; however, on the PDP-6 and earlier versions of the PDP-10, the general-purpose registers were stored in the low memory locations, so that accumulator-to-accumulator moves and arithmetic instructions were possible, and there was an option to put the GPRs into fast registers, in which case references to the low memory locations were redirected to the fast registers - later machines always had fast registers. The memory address was always formed in the same fashion, with the only "addressing mode" being an indirect mode specified by a single bit. The UNIVAC 1100/2200 series was similar, with accumulators and index registers mapped into low memory.

S/360, as the page notes, didn't have a PDP-11ish addressing mode concept; for the load/store/binary-and-floating-point arithmetic instructions, one operand is in a GPR, and the other could be in memory or a GPR, with the difference being indicated by the opcode. Memory addresses were formed by adding the displacement, the index register, and the base register (with R0 meaning "zero"), and there was no indirect addressing, so there were no explicit "addressing mode" fields.

The MIPS has three-register versions of arithmetic instructions, with all operands in registers, and immediate versions, with one operand being a constant in the instruction; there is no explicit "addressing mode" field specifying that. Load/store instructions always reference memory in the same fashion, except for a "load immediate" instruction that loads the upper part of a GPR from an immediate constant - large constants are synthesized from multiple instructions. Other RISC architectures are similar.

When comparing instruction sets, it's useful to have some concept to indicate how operands are specified, and to have a term for it. For better or worse, "addressing mode" has come to be used for that by a large number of people, IBM's use of the term nonwithstanding (does that use really date back 50 years? 50 years ago, S/360 was introduced, and S/360 didn't have address spaces - that was, I think, an S/390ism) - so it didn't have "primary space", "secondary space", etc., nor did it have 31-bit addresses - another S/390ism - and thus didn't have 24-bit, 31-bit, or 64-bit mode.)

So I'm afraid you will have to live with references to S/3x0 and z/Architecture addressing modes. You may want to add a note at the beginning that IBM used the term "addressing mode" differently, but there's nothing misleading about discussing S/3x0's ways of referring to operands in this article. Guy Harris (talk) 23:37, 13 April 2014 (UTC)

For S/360, they are called "instruction format types". Well, the RR, RX, and RS, refer to register, indexed, and storage address modes, but they don't seem to describe them separately from instruction formats. Well, S is described for the S-type address constant. Gah4 (talk) 23:44, 10 July 2024 (UTC)

References

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Addressing mode. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20131227033204/http://hpc.serc.iisc.ernet.in/~govind/hpc/L10-Pipeline.txt to http://hpc.serc.iisc.ernet.in/~govind/hpc/L10-Pipeline.txt

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:32, 26 June 2017 (UTC)

Lead

The changes being discussed:

• Revision 0 — Prior revision
• Revision 1 — by Alexander Davronov (talk · contribs)}
• Revision 2 — by Murray Langton (talk · contribs)

Please use {{re}} to notify participants

Pease use {{re|Alexander_Davronov|label1=<span><span style='color:#a8a8a8'>DAVRONOV</span><span style="color:#000">A.A.</span></span>}} to notify @DAVRONOVA.A.:

Please use {{tq|i=1|your text..}} for quotation.

@Murray Langton: Hi. I would like to ask you to elaborate how exactly my last edit reduced clarity. IMO the old version doesn't meet WP:EXPLAINLEAD & MOS:INTRO. I especially question second sentence which has mangled words. And I also added notion on related concept — orthogonality. I want to return it back since both subjects are related. DAVRONOVA.A. ✉ ⚑ 22:50, 8 December 2019 (UTC)

Hi Alecander,

I'm currently a long way from home (New Zealand instead of England). I can give this my full attention when I get home on 18th December. In the mean time I will reinstate your comment re orthogonal instruction sets and have a look at the mangled words. Murray Langton (talk) 06:52, 9 December 2019 (UTC)

@Murray Langton: Ok, it's fine, have a safe trip. Looking forward to hearing you again. DAVRONOVA.A. ✉ ⚑ 17:10, 9 December 2019 (UTC)

I'm now back in UK. When I first reverted your changes I may have been over-hasty due to jet-lag. Could you put you proposed text for the lead here so that we can consider it and work towards agreement. Murray Langton (talk) 07:34, 22 December 2019 (UTC)

(ab-)using address calculation unit in the CPU to do general arithmetics

At least on x86 assembly it is quite common to use (or abuse?) the address calculation unit of the CPU to do general arithmetics, e.g. additions or simple multiplications via the LEA opcode. It is faster and can be done in parallel to the normal ALU unit, so it is quite often, both in hand-written assembly code and in compiler-generated code. I don't know whether this trick also exists on other CPU architectures. Should this fact be mentioned here in the article? --RokerHRO (talk) 13:07, 17 November 2020 (UTC)

Yes, it is already there in the section 'Useful side effect'. Murray Langton (talk) 15:20, 17 November 2020 (UTC)

The S/360 LA instruction works similar to LEA, but with the S/360 base and index registers, and displacement. For S/360, the result is a 24 bit address. LA is often enough used in assembly code to add a constant to a register, if the result fits in 24 bits. It is also common for loading 12 bit unsigned constants into registers. The PDP-10 is too hard to describe here, but many addressing tricks were used with it. Gah4 (talk) 17:34, 10 July 2024 (UTC)

For z/Architecture the width of LA and LAY depends on the addressing mode: 24, 31 or 64. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:45, 10 July 2024 (UTC)

This article is about instruction-set features; the notion of (ab-)using an address calculation unit is microarchitectural, as whether there is a separate address calculation unit is a microarchitectural detail of a processor rather than a characteristic of the instruction set.

(Ab-)using a "compute effective address" instruction would be something appropriate to an article discussing instruction set features; it could mention microarchitectural reasons for doing so, in addition to "you can do the addition in fewer bytes of machine code", which is architectural. Guy Harris (talk) 20:45, 10 July 2024 (UTC)

Questions such as the speed, or otherwise, would be microarchitectural. But for user level instructions, they can be used however the programmer wants to use them. But yes, the comment about parallel processing doesn't apply. Gah4 (talk) 04:25, 11 July 2024 (UTC)

"This load instruction puts the effective address, rather than the {byte,halfword,word,etc.} at the effective address, into the destination register" is instruction-set-architectural, as is "this instruction can be used to put the sum of the source register and an N-bit immediate instant into the destination register". "This load instruction puts a sum computed by the address generation unit into the destination register", however, is microarchitectural, and may or may not be true on all implementations of the instruction set architecture in question. Guy Harris (talk) 06:24, 11 July 2024 (UTC)

I was noting the mention that it could be done in parallel. I am not so sure that "address generation unit" is microarchitectural. It could, for example, be a microcode subroutine, and so not separate logic. It is logically the same as other address generation, but it doesn't need to be physically the same. And address generation might be done by the same logic as other arithmetic operations, in which case it is still true. It might be faster, or it might not be. For hand generated code, some programmers make assumptions that some things are faster. Some thing XR must be faster than SR, as it doesn't need to do carry. Code generators using dynamic programming can generate code with no unwarranted assumptions. Gah4 (talk) 10:09, 11 July 2024 (UTC)

Where it is done and which are faster are implementation issues, not architectural. In general, an instruction sequence that is faster on one processor may be slower on another, so hand optimization can be dicey unless you know which model the code will run on. Back in the S/360 era there were endless arguments over whether to use SLR, SR or XR to clear a register, but on modern processors they all take the same amount of time. I'm confident that this phenoneum is not limited to IBM. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:11, 11 July 2024 (UTC)

I am not so sure that "address generation unit" is microarchitectural. It could, for example, be a microcode subroutine The use of microcode, and the microcode itself, is microarchitectural for most, if not all, instruction sets. At the abstraction level of an instruction set, there is a process of address generation, the details of which are hidden in the microarchitecture.

The only thing you can say about "load effective address" instructions, at the instruction set level, is what they do, not how they do it, or how fast they do it, or how what the operations it involves are assigned to particular units in the CPU and scheduled at the hardware level. I.e, It is faster and can be done in parallel to the normal ALU unit are statements that might or might not be true of a given implementation of an instruction set, just as anything such as the address calculation unit of the CPU might or might not be true of a given implementation of an instruction set - there might not be an "address calculation unit" in a given CPU. Saying that it may be faster, and that it might be more likely to be done in parallel with other operations (in modern CPUs, two separate additions, neither of which is done as part of effective-address formation, might be done in parallel), can be true at the instruction-set level, because they're vague enough not to commit to how a particular instruction set is implemented.

If you want to talk about what the "load effective address unit" involves in some ISA that has multiple implementations, speak of the address generation process, not the address generation unit. Guy Harris (talk) 11:52, 11 July 2024 (UTC)

Nomenclature: Branch versus Jump

@Guy Harris: The documentation for IBM Z uses the term branch, with jump a synonym for branch relative. I believe that the article should at least note this in passing.

Has anybody done a survey of nomenclature on other architectures? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:27, 1 May 2024 (UTC)

The documentation for IBM Z uses the term branch, with jump a synonym for branch relative. And the PDP-11 uses "branch" for instructions in which the branch target is specified by an 8-bit signed PC-relative offset and "jump" for instructions (jump, jump to subroutine) in which an arbitrary address mode specifies a source that contains the branch target address (e.g., JMP R2 jumps to the address contained in R2). The VAX uses the same convention for "PC-relative with a signed offset in the instruction" vs. "arbitrary target" (although the more complicated procedure call instructions use "call"); Alpha is also similar, although the jump instructions have the target specified by a register. So DEC's convention, at least for their 8-bit-byte-oriented architectures, are somewhat opposite to the S/3x0 convention.

Has anybody done a survey of nomenclature on other architectures? Well...

x86 calls them all jumps, including the PCIP-relative control-transfer instruction introduced in x86-64 (except for the loop and procedure call instructions).

32-bit ARM calls the PC-relative transfer-of-control instructions branches. "Branch to an address in a register" is called a "move" - use the MOV instruction to move the register in question to R15, which is the PC. "Branch to an address stored in memory" is similarly called "load". To use those for procedure calls, you precede them with a MOV of R15 to R14, where the latter is the "link register", into which the PC-relative "branch to subroutine" puts the return address.

64-bit ARM calls them all branches, and are Alpha-like in that most branches are relative, but they also have "target is in a register" transfer-of-control and procedure-call instructions, also called branches, except for the "return from subroutine", which is called RET; it's a "branch to address in a register", but also hints that it's a return.

SPARC calls the PC-relative instructions branches, except for the very-long-displacement procedure-call instruction "call", and the arbitrary-target instruction a jump.

Power ISA calls them all branches (unsurprisingly for an IBM-designed ISA).

It's probably a mix for other ISAs; I've limited that survey to DEC 8-bit byte (because the first of them, the PDP-11, was the first one that came to mind with "branch" for PC-relative and "jump" for others) ISAs and the main currently still living ISAs.

So there's no consensus, although "branch" seems to be more popular these days. Guy Harris (talk) 19:35, 1 May 2024 (UTC)

@Guy Harris: It's dated, but Bendix has used the term transfer on the G-20, GE has used it on, e.g., the GE 635, Honeywell has used it on, e.g., the H-800, IBM has used it on, e.g., the 7090, and RCA has used it on, e.g., the 501. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:49, 10 July 2024 (UTC)

And then there is the PDP-10, where JUMP doesn't jump and SKIP doesn't skip. Gah4 (talk) 04:28, 11 July 2024 (UTC)

You're just being silly. The JUMPx and SKIPx instructions jump or skip when the condition x is true. But null x means never, just as x=A means always. Macrakis (talk) 04:48, 11 July 2024 (UTC)

To be clear, the PDP-10 calls all transfers of control "jumps". It has a fixed-width instruction and 18-bit word addresses everywhere. The op codes that perform jumps are:

• JUMPx, where x is a condition like LE (less than or equal), etc. Unconditional jump is JUMPA.
• JRST 'jump and restore flags', JFCL 'jump if flag set then clear' -- as it happens, with no flags specified (in the AC field), JRST was the fastest unconditional jump on the KA-10, and JFCL was the fastest no-op
• Various subroutine call and return: PUSHJ/POPJ, JSP, rarely used: JSR, JRA, JSA. The J in these instructions of course means jump.

The PDP-10 also has many conditional-skip instructions. Not just the SKIPx family, but also CAxy (compare accumulator) and Txyz (test). These do not have an address argument because they use their two arguments (accumulator and address) for other things. The most common case is skip-instruction followed by an unconditional jump, but other combinations are possible, like the (in) famous TRCE / TRCE / TRCE which swaps two bits in a word (see HAKMEM item 162). --Macrakis (talk) 15:32, 11 July 2024 (UTC)

Someone else was being silly, and I still remember it. The 6809 has relative branch instructions: BRA (branch always) and BRN (branch never). Also, 16 bit offset LBRA and LBRN. There are also other conditional branch for other flag bits. There is only unconditional JMP for absolute address. Gah4 (talk) 08:22, 12 July 2024 (UTC)