Talk:Addressing mode

message: 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)
thread_title: Reason for article creation

message: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title:  This is not correct 

message: 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)
replies: text: 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)
thread_title:  Index next instruction 

message: 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)
thread_title:  memory addressing mode in 8086 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 17:32, 26 June 2017 (UTC)
thread_title:  External links modified 

message: 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)
replies: text: Yes, it is already there in the section 'Useful side effect'. Murray Langton (talk) 15:20, 17 November 2020 (UTC)
thread_title:  (ab-)using address calculation unit in the CPU to do general arithmetics