Suggestions for a microcontroller (general-purpose)

[Analog Kid]

The x86 has always been close to RISC because all the normal instructions have at most one memory operand and there is no indirect addressing.

Um:

Code: [Select]

     MOV   EAX, [EBX]
Isn't that indirect addressing?

[brucehoult]

The x86 has always been close to RISC because all the normal instructions have at most one memory operand and there is no indirect addressing.

Um:

Code: [Select]

     MOV   EAX, [EBX]
Isn't that indirect addressing?

Nope. There's only a single memory access there. It's what M68000 calls "register direct" e.g. MOV (A4),D1.  Register indirect, introduced in the 68020 (and not present in 68000 or x86) is MOV ([A4]),D1 which takes the contents of A4 as an address, loads a word from that address, and uses that data as the address of the item to load into D1.

In full 68020 can do (where bd and od are constant integers):

([bd,An),Xn.SIZE*SCALE,od)   // EA = (bd + An) + Xn.SIZE*SCALE + od

or

([bd,An,Xn.SIZE*SCALE],od)  // EA = (bd + An + Xn.SIZE*SCALE) + od

Or you can do a LEA with one of those to load EA into an address register and then continue from there.

[Analog Kid]

The x86 has always been close to RISC because all the normal instructions have at most one memory operand and there is no indirect addressing.

Um:

Code: [Select]

     MOV   EAX, [EBX]
Isn't that indirect addressing?

Nope. There's only a single memory access there. It's what M68000 calls "register direct" e.g. MOV (A4),D1.  Register indirect, introduced in the 68020 (and not present in 68000 or x86) is MOV ([A4]),D1 which takes the contents of A4 as an address, loads a word from that address, and uses that data as the address of the item to load into D1.

I hate to get into a nitpicking session with you, but I think you're using the term "indirect addressing" contrary to what other sites I just found in a search say it is.

This page says:

In assembly language, indirect addressing can be implemented using registers. For instance, in x86 assembly language, you can use registers like EAX, EBX, ECX, etc., to hold the address of the data. Here’s an example:

MOV EAX, [EBX]
In this instruction, the value in the EBX register is treated as an address, and the data at that address is moved to the EAX register. This is an example of indirect addressing using a register.

This page says:

Indirect addressing involves specifying a memory address that contains the actual address of the operand. This can be useful when the actual address of the operand is not known at the time the instruction is executed. In indirect addressing, the address of the operand is obtained by accessing the memory location specified by the indirect address. For example, in the instruction “MOV AX, [BX]”, the memory location specified by the contents of the BX register is accessed to obtain the actual address of the operand.

Both of which jibe with my understanding of the term.

[brucehoult]

The x86 has always been close to RISC because all the normal instructions have at most one memory operand and there is no indirect addressing.

Um:

Code: [Select]

     MOV   EAX, [EBX]
Isn't that indirect addressing?

Nope. There's only a single memory access there. It's what M68000 calls "register direct" e.g. MOV (A4),D1.  Register indirect, introduced in the 68020 (and not present in 68000 or x86) is MOV ([A4]),D1 which takes the contents of A4 as an address, loads a word from that address, and uses that data as the address of the item to load into D1.

I hate to get into a nitpicking session with you, but I think you're using the term "indirect addressing" contrary to what other sites I just found in a search say it is.

With the greatest respect, there is a difference between "web pages I just found" and knowing.

This page says:

In assembly language, indirect addressing can be implemented using registers. For instance, in x86 assembly language, you can use registers like EAX, EBX, ECX, etc., to hold the address of the data. Here’s an example:

MOV EAX, [EBX]
In this instruction, the value in the EBX register is treated as an address, and the data at that address is moved to the EAX register. This is an example of indirect addressing using a register.

The description of what that instruction does is correct. The name is not correct. That is just "register" addressing.

This page says:

Indirect addressing involves specifying a memory address that contains the actual address of the operand. This can be useful when the actual address of the operand is not known at the time the instruction is executed. In indirect addressing, the address of the operand is obtained by accessing the memory location specified by the indirect address. For example, in the instruction “MOV AX, [BX]”, the memory location specified by the contents of the BX register is accessed to obtain the actual address of the operand.

The text description is correct. The instruction tells you a MEMORY location to access. The data you get from that location is the address of the data you actually want. The instruction then uses the just-loaded data as an address for a second load.

x86 does not have any such instruction to do that. The “MOV AX, [BX]” merely uses that is in the BX register as the final address of the data you want, as does the 68020 "MOV (A4),D1". It does not load a pointer from that address and then make a second memory access as the 68020 "MOV ([A4]),D1" instruction with register indirect addressing does.

The diagram at that web page shows what is called "absolute indirect" addressing rather than register indirect (where the instruction contains or implies a register in the CPU that holds the first address).



If they want to call it "memory indirect" rather than "absolute" indirect that's ok with me.

BUT if you want "register indirect" then you simply replace the "address" in the instruction with a "register number" in the instruction, and keep the rest of the diagram. The CPU register contains the address for the first load, the data loaded is the address for the second load.

That is not what the x86 “MOV AX, [BX]” instruction does. Unlike PDP11, VAX, M68020 the x86 does not have an instruction that does that.

[NorthGuy]

"direct" means something specified within the instruction, "indirect" means that the instruction contains a reference which specifies where the object can be fetched from at run time.

If you apply this to the memory accesses, then "direct" would mean that the address is hard-coded within the instruction. Everything else is "indirect".

Here's from the official description of Intel ISA:

"The following addressing modes suggest uses for common combinations of address components.
• Displacement ⎯ A displacement alone represents a direct (uncomputed) offset to the operand. Because the
displacement is encoded in the instruction, this form of an address is sometimes called an absolute or static
address. It is commonly used to access a statically allocated scalar operand.
• Base ⎯ A base alone represents an indirect offset to the operand. Since the value in the base register can
change, it can be used for dynamic storage of variables and data structures.

... "

In x64, the commands don't really access absolute addresses, but only offsets, so all the addresses are relative. However Intel don't change the terminology to reflect this. They see the difference between direct and indirect in whether the address is embedded within the instruction (direct) or the instruction contains only a reference to where the address would be found at run time (indirect).

[brucehoult]

Here's from the official description of Intel ISA:

"The following addressing modes suggest uses for common combinations of address components.
:
• Base ⎯ A base alone represents an indirect offset to the operand. Since the value in the base register can
change, it can be used for dynamic storage of variables and data structures.

Note that the actual name of the addressing mode there is "Base", which I fully agree with.

The use of the word "indirect" there is informal English description, not the name of the addressing mode.

When CPU architects say that the problem with CISC is the indirect addressing modes -- and they do -- what they mean by that is not a register holding the address of the data. Everything does that. Or at least everything that supports pointers and stacks in RAM. What they mean is instruction -> reg number -> contents of that register as a pointer -> load data from memory -> interpret that data as a pointer -> load data from memory -> use that data.

Intel of course doesn't have a term for that as Intel doesn't have that feature.  VAX does that. M68020 does that. Data General does that. Pr1me does that. NS32000 does that.

[Analog Kid]

When CPU architects say that the problem with CISC is the indirect addressing modes -- and they do -- what they mean by that is not a register holding the address of the data. Everything does that. Or at least everything that supports pointers and stacks in RAM. What they mean is instruction -> reg number -> contents of that register as a pointer -> load data from memory -> interpret that data as a pointer -> load data from memory -> use that data.

Could you please provide a source for that assertion?
In my search, every single page I found did not so describe "indirect addressing".
Your definition seems quite overly restrictive to me.
I'm fine with being proven wrong here.

[brucehoult]

When CPU architects say that the problem with CISC is the indirect addressing modes -- and they do -- what they mean by that is not a register holding the address of the data. Everything does that. Or at least everything that supports pointers and stacks in RAM. What they mean is instruction -> reg number -> contents of that register as a pointer -> load data from memory -> interpret that data as a pointer -> load data from memory -> use that data.

Could you please provide a source for that assertion?
In my search, every single page I found did not so describe "indirect addressing".
Your definition seems quite overly restrictive to me.
I'm fine with being proven wrong here.

https://yarchive.net/comp/risc_definition.html

"3d) Have NO indirect addressing in any form (i.e., where you need one memory access to get the address of another operand in memory)"

See "PART II - ADDRESSING MODES" and "THE GIANT  ADDDRESSING MODE TABLE". His "r" ... Register addressing mode ... means the register contains the address of the data. That's the only addressing mode (per the table) on AMD 29K.

John Mashey is one of the most respected CPU architects ever. This is the standard terminology in comp.arch and for CPU architects everywhere.

https://en.wikipedia.org/wiki/John_Mashey

Read the whole thing.

[Analog Kid]

Read the whole thing.

WTF? Thanks, but no thanks.
What, are you nuts? This is a breathtaking ask, and is so typical of some of the responses one gets here:
"Here, read my 242 page document and then you can respond."
Do you realize how much text is in that document?
I'm somewhat interested in the topic here (indirect addressing), but I'm not about to drop everything and spend the hour and a half it would take to read and digest that! It's not that pressing an issue to me.

Have some sense of proportion, man.
Sheesh.

[Andy Chee]

Could you please provide a source for that assertion?
In my search, every single page I found did not so describe "indirect addressing".
Your definition seems quite overly restrictive to me.
I'm fine with being proven wrong here.

My basic understanding comes from the 16F84 datasheet (page 13 & 14)

https://ww1.microchip.com/downloads/en/devicedoc/35007b.pdf

(which incidentally, is the same as Ubicom/Scenix SX28)

[brucehoult]

Read the whole thing.

WTF? Thanks, but no thanks.
What, are you nuts? This is a breathtaking ask, and is so typical of some of the responses one gets here:
"Here, read my 242 page document and then you can respond."
Do you realize how much text is in that document?
I'm somewhat interested in the topic here (indirect addressing), but I'm not about to drop everything and spend the hour and a half it would take to read and digest that! It's not that pressing an issue to me.

Have some sense of proportion, man.
Sheesh.

You asked for a source. That's a definitive and highly respected source. Why even ask if you're not even intending to read it?

If you want to understand the issue then an hour and a half is nothing. I've spent decades studying computer architecture -- as in, I took the time to read and understand that post (and many others like it, and text books) at the time it was made in the early 90s.

And I put in an hour or an hour and a half researching and answering people's questions here or on reddit etc almost every day.

If you don't want to put in the work yourself, then maybe believe those who have?

Just a thought.

[shabaz]

Here's what Hennessy & Patterson have to say on the subject (2nd edition; I don't own the latest), see rows 4 and 7.

[brucehoult]

What CPU designers hate, and RISC ISAs don't have and CISC ISAs do have (except x86 .. one reason it's the only surviving CISC) is the 7th mode in that table "memory indirect" which is usually abbreviated to "indirect". I would suggest that the first listed name for each mode is their preferred one, though it does seem that Intel uses the second name.

The entire point is that the 7th addressing mode is bad, no matter what it is called, and machines that have it are now all dead.

[Analog Kid]

Well then, from that I conclude that what I've been calling "indirect addressing" is in fact what it is (4th table entry, "register deferred or indirect"), while the overly-qualified mode you've been claiming as "indirect" (7th entry) is "memory indirect or memory deferred".

Therefore, at least according to this source, Add R4, (R1) does qualify as "indirect addressing".

Or do you dispute that?

[brucehoult]

Well then, from that I conclude that what I've been calling "indirect addressing" is in fact what it is (4th table entry, "register deferred or indirect"), while the overly-qualified mode you've been claiming as "indirect" (7th entry) is "memory indirect or memory deferred".

Therefore, at least according to this source, Add R4, (R1) does qualify as "indirect addressing".

Or do you dispute that?

Let me try to use very small words for you.

When
CPU
designers
say
indirect
addressing
is
bad
they
do
NOT
mean
a
register
holding
a
memory
address

[westfw]

The DEC PDP10 architecture had very explicit “indirect” addressing.  There was a bit for it in the instruction (36 bits makes for a lot of options.). Each instruction would calculate an “effective address” based on an index register (possibly none) plus displacement.  If the indirect bit was set, it would fetch a word from that address, and do the whole effective address calculation AGAIN.


All before the opcode evaluation.  You could end up with an infinite loop, just in the address calculation!


I actually used this with two index registers once, to implement a sort of two-dimensional array.
And it was useful with some of the legacy subroutine linkage methods that stored the return address in “weird” memory locations.

[brucehoult]

The DEC PDP10 architecture had very explicit “indirect” addressing.  There was a bit for it in the instruction (36 bits makes for a lot of options.). Each instruction would calculate an “effective address” based on an index register (possibly none) plus displacement.  If the indirect bit was set, it would fetch a word from that address, and do the whole effective address calculation AGAIN.

Yes, this was common at the time.

In the Data General line, in the Nova (PDP-8 competitor) LDA and STA had an indirect bit in the opcode, which resulted in the memory operand being treated as the address of the data, not as the data itself. This worked only for a single level , but the JMP instruction also had an indirect bit, and in this case if the MSB of the data loaded was 1 then next word loaded would also be treated as indirect. This could form an infinite loop. In the Eclipse (still 16 bit but added a stack pointer, floating point registers, and virtual memory) the load and store instructions also supported infinite levels of indirection. This was carried over to the 32 bit Eclipse/MV.