Defining the 65Org32 - addressing modes (and instructions)

[BigEd]

Recently there were some posts about the addressing modes of the 65Org32. I thought it might be good to have a thread for that.

Quick summary of the machine: 65Org32 is a 6502 with 32-bit bytes. The address and data bus are both 32 bits. And so an address is just a single byte. Therefore:

• zero page is the whole address space
  indirections use only a single location for the address
  address push and pop use only a single slot on the stack

Possibly not all 32 address bits would be brought out or decoded. (Note that this is not a 64 bit address machine)

Paraphrasing the discussion:

• EEye thought at first that indirect indexed (ZP),Y would not be 'needed'
  Garth thought otherwise (in the sense that it's still meaningful and useful)
  EEye changed his view
  Arlet pointed out that absolute and absolute indexed are not needed [presumably because equivalent zero page addressing modes cover the whole address space already]
  kc5tja reckoned that indirect indexed is not 'needed' in the sense that modern RISC does without

As for the ease of implementing, Arlet will have a feel for this: the state machine needs to collapse all the double states which presently deal with the two bytes of addresses.

I hope this an accurate and useful summary!

Cheers
Ed

Edit: updated subject/title to reflect conversational drift

[kc5tja]

BigEd wrote:

kc5tja reckoned that indirect indexed is not 'needed' in the sense that modern RISC does without

This is not to suggest it should be removed; I'm just curious what gain we get from having it. EEye changed his position, for example, so there had to be a reason.

[BigEd]

I would leave things in mainly on the grounds that keeping the machine familiar to the 6502 assembly-level programmer is a goal.

Even possibly leaving in the redundancy that Arlet points out. It's also less work than removing it!

Specifically on your point though - have you checked ARM? How about this:

Code: Select all

str	r0, [r1], r2

• Move contents of r0 into address pointed to by r1, and increment r1 by contents of r2. *r1 = r0, r1 = r1 + r2

Similar, but different: the offset is not applied to the address but is added to the indirection for the next time around.

[kc5tja]

BigEd wrote:

Specifically on your point though - have you checked ARM? How about this:

Code: Select all

str	r0, [r1], r2

• Move contents of r0 into address pointed to by r1, and increment r1 by contents of r2. *r1 = r0, r1 = r1 + r2

Similar, but different: the offset is not applied to the address but is added to the indirection for the next time around.

This is not ARM-specific. PowerPC and MIPS both have similar "load/store and update" instruction forms. It makes perfect sense to have them, for they actually make more efficient use of the instruction pipeline than a simple load/store instruction would by re-using the ALU's results. These forms are used to replace pre-decrement / post-increment addressing modes found on CISC processors like the 68K/Coldfire family.

However, since the update always occurs after the memory access, software will need to bias the pointers before entering the loop, depending on which direction through memory it wants to cycle through.

[ElEctric_EyE]

kc5tja wrote:

... EEye changed his position, for example, so there had to be a reason.

I think the reason I "changed my position", was mainly because of a lack of 6502/65Org16 registers and not being able to easily add the accumulator together with the X & Y registers (since the X&Y registers were already being used for pixel placement)...

In my graphics routine, I add accumulator several times as needed with other variables to the low "byte", and then finally index it using indirect index using the Y-register.

I think in my "moment", I was imagining a 32-bit "zero-page" as BigEd mentioned, whereby my previous 16bit byte manipulation would not be needed. A programmer can add as much as they want without worrying about page boundaries, they would just need to worry about the limits of the attached "external" memory...

I'm posting my plot routine made for the 65Org16 on the V1.1 DevBoard thread, so you/anyone can tear it apart there if you desire.

[ElEctric_EyE]

I changed my mind again, indirect indexed opcodes could be sacrificed for speed...

One thing crossed my mind though, about 65Org32: If zero page covers the entire 4GB, where is the stack going to reside?

Must reconcile this code?:

Code: Select all

/*
 * Address Generator 
 */

parameter
	ZEROPAGE  = 32'h0000_0000, //  all zero
	STACKPAGE = 32'hFFFF_FFFFF; //  one

[kc5tja]

The stack overlaps zero page. This is simultaneously a blessing and bug, depending on how you use the resource. It could be a bug if you're sloppy with pushing stuff on the stack, causing it to overwrite previously allocated locations. Or, it's a blessing, allowing you to pass parameters to subroutines, and *directly* use passed pointers with zero-page addressing modes. Assuming you do this, (dp), (dp),Y, and (dp,X) all become useful again.

Consider that most CPUs have a free-roaming stack pointer, with as many bits as there exists on the address bus at least. They will assign a register to serve as the "frame pointer," which points to the current routine's variables and input parameters. In the case of the 65org32, X would serve as the frame pointer, making dp,X and (dp,X) useful for dereferencing passed or computed pointers.

However, if you prefer to manage a stack in software, like all RISCs do today as far as I know, then dp,X and (dp,X) aren't worth a whole lot, and abs,X prove more useful, I think.

Generally, stack is placed at top of RAM (but below ROM and I/O) and grows down, while you reserve memory locations for data starting at address zero and growing up. When they meet in the middle, you're out of memory.

[ElEctric_EyE]

Well, if the 65Org32 is going to be an extension of Arlet's Core, the natural progression would be 32bit data bus and 64bit address bus, so at this point they would look like this:
zero page..... $0000_0000_0000_0000-$0000_0000_FFFF_FFFF
stack............. $0000_0001_0000_0000-$0000_0001_FFFF_FFFF.

But we want 32bit addresses, so simply truncating the upper 16bits might not work too well...

[Arlet]

Easiest solution is to leave out upper 32 bits, and then the stack and zeropage both end up in the same 4GB memory space. By setting the stack pointer, the programmer can allocate his own stack.

[BigEd]

ElEctric_EyE wrote:

Well, if the 65Org32 is going to be an extension of Arlet's Core, the natural progression would be 32bit data bus and 64bit address bus, so at this point they would look like this:
zero page..... $0000_0000_0000_0000-$0000_0000_FFFF_FFFF
stack............. $0000_0001_0000_0000-$0000_0001_FFFF_FFFF.

But we want 32bit addresses, so simply truncating the upper 16bits might not work too well...

No, it's not 64 bits address bus. Never was. If you want to make one of those, call it something else! I realise the name is not exactly analogous to 65Org16, but that's how it is. In fact 65Org32 might have got there first.

As Samuel (and Arlet) say, the stack is free-roaming. It would be an extension to be able to limit the high or low value, or to mask it against a mask, or to force some bits to some value. You'd need to define an interface, or of course you could code it in the HDL as a parameter.

In fact, all of X, Y and SP can point to all of memory, as can any data value (which can be used as a direct page value in an indexed address mode.) That's the beauty of having the address and data bus the same width.

I think this machine might be faster anyway, on account of the smaller number of states. I wouldn't ditch any addressing modes for that reason. There are other ways to get speed: faster FPGA, caching. (Speed was never a goal as such, it just comes for free with today's FPGA and memories.) Let's get it working first, then we can get working on fast.

Cheers
Ed

[ElEctric_EyE]

BigEd wrote:

...No, it's not 64 bits address bus. Never was. If you want to make one of those, call it something else!
Cheers
Ed

No, you misunderstand me. Maybe I misunderstand you guys too. I was only trying to provide a starting point by stretching the address bus to 64bits and showing a natural progression...

So, am I to understand the code would look like this:

Code: Select all

/*
 * Address Generator 
 */

parameter
	ZEROPAGE  = 0, 
	STACKPAGE = 0; 

[Arlet]

BigEd wrote:

[Let's get it working first, then we can get working on fast.

Getting it to work should be a matter of changing the 'dw' parameter in your code from 16 to 32, right ?

Removing redundant addressing modes, such as ABS and ABS-X should be a simple matter of just removing those states. The speed gain would probably not be impressive, but it would simplify the core, making additional changes easier to implement.

Modifying JMP/JSR/RTS/RTI/BRK to only use 32 bit addressing would be a bit more complicated (and would also require changes in the assembler for JMP/JSR), but it would save a cycle, and would make the JMP/JSR instructions shorter.

[Arlet]

ElEctric_EyE wrote:

So, am I to understand the code would look like this:

Code: Select all

/*
 * Address Generator 
 */

parameter
	ZEROPAGE  = 0, 
	STACKPAGE = 0; 

You could do that, but they are really "don't cares". With a 32 bit address and data bus, the "upper 32 bits" of the address wouldn't exist, and all logic driving it would be optimized away by the synthesis tools.

[GARTHWILSON]

Quote:

The Ra+offset mode would translate into direct-page-indexed (e.g., dp.X or dp,Y) in the 65xx architecture. I'm curious to learn where the extra level of indirection would prove especially useful.

If the DP register is also 32-bit as I said I wanted on the 65Org32, that would definitely reduce the need for indirect indexed. Otherwise, if you're indexing into a table whose base address you don't know until the task is loaded, you would need more than just dp,X and dp,Y. I expect the RISC machines' way of doing it takes more steps, doesn't it? (I don't know.) If the RISC can add more registers together to avoid it, it's the same thing, because most of the 6502 family's registers are zp, or dp, and in the case of the 65Org32, all of memory. That's a lot more than 16 or 32 processor registers, although it does require more bus accesses.

What I had not thought about until now however is that there's still a need for absolute indexed, where you don't want the DP offset added. The total instruction length would be the same as dp,X, at two 32-bit "bytes." It would be like ZP in that sense, but not get the DP register offset.

There is no ADH. I don't see any 64-bit registers, except possibly a double 32-bit for the resutls of multiplying two 32-bit numbers, and the 64-bit dividend to be divided by a 32-bit divisor, resulting in a 32-bit quotient and a 32-bit remainder.

[BigEd]

Arlet wrote:

BigEd wrote:

[Let's get it working first, then we can get working on fast.

Getting it to work should be a matter of changing the 'dw' parameter in your code from 16 to 32, right ?

I think also one must get rid of all the handling of upper-byte operands and second-byte direct page actions and second-byte address push and pull.

Otherwise one does just have a double-size version of 65Org16, which isn't especially interesting (to me).

Conversely, a half-width version of the 65Org32 is slightly interesting. It's 16 bits throughout, with therefore a limited addressing range (like a 6502) but with the lean and fast single-byte addresses.

I hadn't thought about the impact on assemblers!

Cheers
Ed