How can we convert Arlet's code to take advantage of the << and >> shifts?
I'm sorta pxssxng in the wind here, but I thought I would ask anyway in order to apply to 65Org16...

I would like to add some effort into making a 65Org32 Core a reality. The way I see it so far is we need to truncate some of the 64 address lines. This means Indirect Indexed mode must be sacrificed as it will be non-functional. Personally, I like 4GB worth of addressable memory, but also I would prefer a size just abit larger than the 65Org16. Just a few more additional address bits can put it within the range of some affordable SSD drives (sure they're slow now, but just think in the near future). I would like to see around 128GB of addressable memory, that's A0-A36...

Just some food for thought...

The 65Org32 idea is that it be all 32-bit, no 64-, except possibly a double 32-bit register to hold intermediate fixed-point/scaled-integer arithmetic results from a 32x32-bit MULtiply instruction and the dividend of a 64/32 divide with 32-bit divisor, quotient, and remainder.


I may be missing something, but I don't see anything keeping it from being fully functional.

If we were to follow BigEd's 16bit modification of Arlet's original 8bit 6502 and procede further to convert all data width's to 32bits and address width's to 64bits there would be no problem I guess...

Is there a problem with a 64bit address bus? You think today's memory could cover such an expanse?

We could reassign the IRQ/NMI/Res vectors, but Indirect Indexed mode would/could not be covered.

I guess there's no problem with a 64-bit address bus if the FPGA resources are there, but even my 1.8GHz PC only has 2.5GB of DRAM which I suppose is 625Mx32, or about 15% of a 4Gx32 (16GB) space, so I can't imagine a 65-family processor with its typical applications having any need for that much memory. Holding the address bus width down to 32 bits means operands are always one byte, which I expect would simplify the instruction decoding a little.

Is the problem only the method by which Arlet did the indirect indexed mode? Because certainly the applicability is not eliminated merely by having a 32-bit op code, operand, data bus, address bus, and 32-bit implementation all of the 65816's registers.

No, that is not the problem at all. In fact his code structure very easily, even for someone of very limited Verilog understanding like myself, allows for n-byte expansion. The problem lies in what to do with the unneeded addresses. For you it seems to not be a problem and maybe it really isn't a problem to have just a bunch of floating addresses. We can still re-assign the IRQ/RES/NMI vectors to whatever we want easily enough...

BTW: I'm going to exercise my First Amendment Constitutional rights and wish you and all a Merry Christmas!
Don't like that? Don't make me exercise my Second Amendment Constitutional rights!

I don't see the problem either.

The point of the indirect modes is that they fetch something from zero page, and then they use that as an address. In 65Org32, there is no zero page, or more usefully, everything is zero page. So we fetch something, then we use it as an address.

In the 6502 and the 65Org16, the fetching of an address has to be done in two reads, because the address bus is twice the size of the data bus. In the 65Org32, the whole point is that the address bus and the data bus are the same size. So we only need to do a single read.

It's because we only need to do a single read that the 65Org32 is a bit more distant than the 65Org16 - we need to modify the state machine quite a lot. It is a series of simplifications, which gets us to a machine which is slightly faster because it takes fewer states and fewer memory accesses to get work done, so that's attractive. But it is extra work.

On the other hand, unless you do it yourself EEye, I don't think anyone is going to make something with a 32bit databus and a 64bit address bus, or even an abbreviated 64bit address bus. Once we have 32bit addresses, which we now do, we've got quite enough to work with, and the challenges of putting as much as 4Gword of memory on a hobby motherboard are quite big enough.

Cheers
Ed

But as you say:

Since I don't know Verilog that well, all I meant was that the easiest solution would be to get rid of Indirect Indexed Mode, no other modifications would be necessary for a working 65Org32 Core. Also no need to physically bring out 64bit address lines, but if it's necessary in the Verilog code then so what if we only bring out a few of the addresses?...
The situation now being discussed is very similar to my preference of dumping BCD mode for the 65Org16. Sure it's possible, but how long before something solid is actually tangible without some very knowledgeable modifications to the Verilog coding?

OK, I begin to see what you're getting at! But what do you mean by a 65Org32? As originally defined, with addresses being only a single byte, you still need to modify the other indirect modes, and the fetching of absolute address operands, and the stacking/unstacking of addresses for subroutines and interrupts.

(What I mean is, it's not just addresses fetched from zero-page which need some attention, unfortunately.)

You are quite right that the 65Org16 can very simply be stretched to an even wider machine - it's parameterisable to any width, so 24bit data/48 bit address or 32 bit data/64 bit address are both trivial from a verilog perspective. But I don't think you get much from those changes. I suppose 32-bit wide registers is something - to check the cost of a wide shifter I set up a machine at 32-bit data/40-bit address. You need at least 33bits of address for the verilog to compile OK. But you are carrying the overhead of two accesses for every address, which is to say two bytes in a pointer. This is not what Garth had in mind for 65Org32.

Cheers
Ed

Sounds like you have done some testing?
I think maybe Garth's (an possibly my) idea for a 65Org32 Core is not going to be realizeable in the way we would have liked it to have been. The 65Org16 is such a natural and successful progression from Arlet's NMOS6502, it does take some serious time and thought to analyze the few successes/many failures in the transition of opcodes to a 32bit machine.
ATM, this is out of my league, and I am done entertaining the thought!

I did one quick experiment - that's now a link in my previous post. It does show the way to a machine with 32bit registers if that's of prime importance, but without the efficiency of single-byte addresses.

As you say, doing the work to make that simpler desirable 65Org32 is still looking out of scope for us at present.

But we can do things like adding opcodes and operations, and, probably, registers or register banks.

One step at a time!

Cheers
Ed