Cool suggestion, nyef! The Apollo Guidance Computer used a feature like this, although I'm having trouble finding the doc I read years ago. Edit: see below

The feature in question used addition, not ORing or XORing, but the intent was similar. Prior to execution, but subsequent to being fetched from memory, an instruction could be modified by adding a value computed at run time. It was a sanitized version of self-modifying code. IIRC the original intent was simply to implement indexed addressing. The addition was expected to modify an Address Field located in the bottom of the instruction word.

That's clever in itself, but a fascinating quirk yielded capabilities far beyond what had been originally planned. Someone realized that an addition could also or alternatively modify the Opcode Field in the top of the instruction word. Moreover, such an addition would produce an n+1 bit result -- a carry. This anomaly was recognized as an opportunity. The carry was decoded along with the original opcode bits, and the opcode space was thus doubled. A whole new set of instructions could then be defined -- instructions which were only available via this curious back door technique!

Edit: In this post on anycpu.org,


cheers
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I think that would require locking out interrupts between the instructions. It is an interesting idea though. It's more powerful than execute instruction in a register. You can get the same effect by setting the modified instrucion equal to zero first. With instructions up to eight bytes in length, a constant could be used to extend a single byte instruction to eight bytes + carry bit. IT would require breaking my decoder apart for the pc increment. The pc would increment depending on the unmodified instruction value.

What's the mnemonic for this instruction ? ADDEXEC ?

Maybe I should modify the decoder to skip over multiple NOP instructions all at once. So they only take a single clock cycle to execute.The goal is to improve performance, so what if it takes eight bytes, as long they all execute in a single clock ?

_________________
http://www.finitron.ca

Excellent find Jeff! The search term you may need is "extracode" - see page 15 and page 26 of http://authors.library.caltech.edu/5456 ... e/1704.pdf
and other places.


Here's a video which might be relevant (a humorous critique?): http://www.youtube.com/watch?v=dw-QzsBQS44

Cheers
Ed

RTF65002 Status Update:

OKay, I added both EXEC and 'ATNI' (Add to next instruction) instructions to the processor. I don't know yet if they work or
not.

There's a little multi-tasking kernel in the works. It's possible to kick off basic as a separate task. ALT-Tabbing between the tasks almost works. There's still a bug switching the input/output focus around. The source code for the kernel is posted at opencores as part of the bootrom.

Thinking about developing a C compiler.

Of 8,000 lines of code and indirect X, indirect Y, addressing modes are never used. This is because a register can represent a pointer to memory, so there's no need for the indirect modes. However, the design may be extended to support 64 bit addressing using the indirect addresssing modes.

I've once again maxed out the FPGA, an xc6slx45.

_________________
http://www.finitron.ca

But I only have an lx9!

That's the problem with a larger 32 bit system it takes a larger FPGA. There's an ethernet controller, SD card controller, sound generator, text controller, bitmapped graphics controller, sprite graphics controller, UART, keyboard, led controller, interrupt controller, and a couple of other things in my test system. I can't have everything loaded at once, or the design won't route. So I leave out bits and pieces.

I've been looking at an even larger FPGA. Artix-7.

Will the 65org16 fit in an Lx9 ? What kind of system fits in an LX9 ?

I got the bug fixed in the IO focus switching. works great now. Basic multi-tasking seems to work, though there's still a bug in timeout list. Sleep() doesn't work properly yet. The messaging system is untested yet.

_________________
http://www.finitron.ca

The 65Org16 is pretty small: it took up only a fraction of an lx4, according to an old synth report I have lying around:


Edit to add: here's another one, relating to an lx9:


How big is just the CPU in your SoC?

Cheers
Ed

It's currently just over 10,000 LUTs. It used to be about 15,000 LUTs but I pulled some tricks to reduce the size. There's still
lots of opportunity for size reduction. The core has a lot of built in features. Cache, barrel shifters, multiply/divide, 65C02 compatibility, TICK, LFSR regs. vector table, etc. It'd be tough to fit (by trimming features) into an LX9 but maybe not impossible. There's 5,700 LUTs in that device.

Number of Slice Registers 1291 54576 2%
Number of Slice LUTs 10382 27288 38%
Number of fully used LUT-FF pairs 921 10752 8%
Number of Block RAM/FIFO 25 116 21%
Number of BUFG/BUFGCTRLs 2 16 12%
Number of DSP48A1s 4 58 6%

780 LUTs ? for 65org16. That's good. Does it use any BRAMS ?
What's the 65org32 like ?

_________________
http://www.finitron.ca

I think we're (they are) waiting for someone, a volunteer, to have enough time and skill to dedicate to the 65Org32. I put alot of effort and time into the 65Org16. 16-bits of 6502-like power was good enough for my needs at the time.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

No, not for the core itself.

Thanks for the detail Rob! Although we don't have Verilog for the 65Org32, it's easy to configure a 32-bit wide 65Org16, which then uses 1309 LUTs in Spartan 6, or 1431 in Spartan 3. A true 65Org32 would be a little smaller because of the simpler sequencing (it has single-byte addresses to deal with, so all states concerned with the high byte of an address are unneeded)

How much of your machine is taken up by the cache? Presumably both block RAM and distributed RAM?

Cheers
Ed

All the BRAMs are for the cache. The cache doesn't use any distributed RAMs. I'm not sure how many LUT resources the cache controller and other cache interfacing uses because it's not broken out as a separate component. There are several 64 bit muxes involved with the cache to allow for eight byte instructions.

A simple icache does not use hardly any reousrces at all, eg (150? LUTs). But the rtf65002 has an eight way 64-bit mux to allow reading entire instructions all at once, it has to take into account instruction alignments. There's more muxes in the ifetch stage to allow for uncached accesses. There's something like 300 32 bit muxes in the processor. I suspect result bus muxing uses a lot. This could be improved at the expense of clock cycles. In order to allow a number of instructions to execute in two clock cycles instead of three, it doubles the resources used.

The two instructions EXEC and ATNI used about 1,000 LUTs by themselves.

Major Resources:
# Adders/Subtractors : 90
32-bit adder : 36
# Multiplexers : 1485
32-bit 2-to-1 multiplexer : 308
33-bit 2-to-1 multiplexer : 154



What about 64-bit addressing for the org32 ?

_________________
http://www.finitron.ca

Well, the 65Org32 is strictly a 32-bit machine, both for address and data... if you wanted a stretch 6502 at with 32 bits data and 64 bits of address, that's just a parameter selection on the 65Org16 - it's what I gave synthesis results for above. It's easy, now we have 65Org16, but I suspect it's not very attractive.
Cheers
Ed

Computer architecture texts always pay a lot of attention to the ALU, but really, CPU design in an exercise in MUXing more than anything else.

You've probably heard this before but,
If the 65org32 is strictly 32 bits, then the absolute addressing modes are redundant. abs,x is the same as zp,x. and abs is the same as zp.
I'd suggest reusing the address mode opcodes to add another index register 'w'. abs,y becomes zp,y and abs,x becomes zp,w.
It would also save code space to have a short form immediate eg. 16 bits instead of 32 (did this onthe rtf65002).
Then with 32 bits it also makes sense to use a plain ADD/SUB instruction rather than ADC/SBC.
Otherwise I'd keep the rest of the processor the same in order to keep it small.

there'd be no backwards compatibility.
No barrel shifter, no additional registers (save w). no additional instructions. No cache. The goal being to fit the processor in a relatively small FPGA.

_________________
http://www.finitron.ca