_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

(I think of the '816 as having 5 modes - it seems the simplest way, for me, to think about it.)



I'm thinking of all the little details found in Bruce's major document

65C816 Opcodes by Bruce Clark

that document/webpage has helped me so much while learning the 65816 (and still does).
and one corner case/quirk that i found on there was that JMP (abs) and JMP [abs] read from Bank 0, while JMP (abs,X) will do it in the current Program Bank instead.
it makes little sense to me, and i would honestly rather have the non-indexed versions also access the current Program Bank (or better have all of them access the Data Bank like all other absolute addressing modes, so the Jump Table can be anywhere in Memory regardless of program execution)

but ey that's just how i see it. maybe they had a reason to restrict the non-indexed indirect jumps to Bank 0.

E = 0 and E = 1 are described as modes a little further down. There are several equivalent way of thinking about these bits, and none of them are wrong.

(I've never thought of I as a mode flag, but it does make sense)

If you have 8-bit indexes and one index register free, you may be able to use a combination of LDX followed by TXA (or LDY followed by TYA)... If I understand correctly, TXA/TYA from an 8-bit index to a 16-bit accumulator should clear the upper 8 bits of the accumulator.

(Apologies for more thread derailment)

It's a bytecode interpreter and in this particular bytecode there are 255 instructions defined. So the index could be 8-bit, but it would have to do 2 fetches to fetch the 16-bit address of the target code for that particular instruction.

For the most part the system runs in native mode with 16-bit registers/memory. The dispatch code which is executed in-line for almost all the bytecode instructions takes 29 cycles most of the time and 37 cycles when it has to increment the top 16-bits of the 32-bit program counter. (I know we only have a 24-bit real PC but that's not an issue here - it's also a rare thing to have happen, but does happen from time to time with large programs)

All registers/modes/widths/whatever are free on entry but the targets expect registers+memory to be in 16-bit mode. Additionally, all '816 executable code and data lives in Bank 0. It's entirely possible I'm missing a trick or 2 but I really don't know.

Have fun...




Numbers in () are the opcode cycle counts. Saving 4 cycles from the LDA and the AND would be nice. I've been through all the scenarios of delaying the PC increment (by pushing it to the target op-code code) which might make jump instructions go faster but the compiler sometimes tries to adjust things such that the jumps don't happen, if possible (by negating the test and using the 'opposite' conditional jump) so gains there might be less than the effort required.

In practice it's not that bad on my 16Mhz system, but there's always the "wouldn't it be nice if ..."


-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

i mean is that AND really that bad? those few cycles will add up sure, but it could be worse!

look at my own bytecode VM for the 65816 (SW32VM) for example...

because i'm dumb and wanted to make the whole thing relocatable (which it isn't anymore anyways) i didn't want to make use of indirect jumps and instead instructions are choosen by just going through a chain of DEC A instructions, checking if A is 0, if not continue to the next, if it is execute the selected instruction.

it's not fast at all and means instructions further down take longer to execute by default. i really need to rewrite that someday.

but on the other hand i'm also not really making use of indirect addressing in general. because the Index Registers are 16-bit wide, i've opted to use X as the lower 16-bits of the PC, and the Data Bank Register as the upper 8-bits.
this means i load instructions by doing LDA a:$0000,X
and incrementing the PC is just INX followed by a BNE in case it rolled over and the Data bank needs to be adjusted. though i still keep a copy of the PC in memory in case X gets muddled.
in hindsight, it might've been much easier and faster to just use indirect addressing.

again the entire thing is ripe for an almost complete rewrite...
but maybe there is something in there that could help you, or make you realize that it probably isn't worth trying to hyper optimize every last line of code...

You're right - It's not that bad, but like the extra cycle on the LDA it sort of makes me feel a bit "Grr" thinking it should have been better. Not just that but removing the AND will save 3 bytes - and yes, some will point out that I've said very recently that you should use that RAM, but in this case for reasons of "architecture" I want my BCPL Bytecode VM to live entirely inside a 16KB region of RAM. Right now I have about 100 bytes free... And because this code is in-lined with every one of those 255 opcodes (sometimes twice), saving 3 bytes here will save me at least 765 bytes overall which i can use to speed something else up...

It's also annoying when some of the opcodes take less cycles than the dispatcher.... Here is an example



The "add 1" opcode is used in almost every single FOR loop...


However, it did help me achieve my objective of letting me run a high level language on the '816 and also run the compiler directly on it too. Even if it's is a shade slow. But how slow? It might be nice one day to run the benchmarks I recently run under Basic and BCPL with a C compiler for the '816 ...



That's quite something!




I will have a deeper look, thanks. I have also been guilty of the "premature optimisation" scenario too - details here https://projects.drogon.net/ruby816-premature-optimisation-and-all-that/

Trying to get back on-topic.. One reason I went down the path of BCPL was because I think we have lost all the C compilers that once did run directly on the 6502 (and 816). And by lost I mean no public source code available to let us port them to new systems. I used Aztec C on the Apple II back then. The Apple IIgs has a Pascal compiler and a C compiler (written in Pascal) that runs on the system. There are a few ones that run on the BBC Micro but what else?

We have to cross compile now. Not always what I want to do at least.

So BCPL lets me edit, compile and run programs directly on my system without using BASIC. If only it were a shade faster...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The RISC-V certainly has fanatic followers! More than one person has tried to sell me on this. I glanced over the specs for it and had the impression that it is a toy. Nobody has ever indicated any practical use for the bloated monster --- they just say that is a "joy to use" (I have no idea what that means).

The #1 priority in micro-controllers is low interrupt latency. There is no indication that the RISC-V makes any attempt at this. My own processor has only a few 16-bit registers, and it stores these in shadow registers during an ISR (rather than push them to the return-stack). Exchanging multiple registers with their shadows is a single clock-cycle save or restore.

Note that, historically, the 6502 was primarily famous for having low interrupt latency. It did push the registers to the return-stack rather than exchange them with shadow registers, but there was only the 8-bit P, A and Y (the X wasn't usually needed). The (zp),Y addressing mode of the 6502 was great for implementing circular buffers of 256 bytes. The pointer to the buffer was in a zero-page variable, so it didn't need to get loaded into a register in the ISR, which means that there was no register to save/restore in the ISR. The (zp) addressing mode of the 65c02 was even better because now the Y register didn't need to be saved/restored in the ISR. The only register that needed to be saved and restored was the A register (the P and PC were saved/restored automatically). The 6502/65c02 would have been slightly improved if the A registers got saved/restored automatically along with P and PC, but the PHA and PLA instructions were pretty fast so this wasn't a big deal.

All in all, the 6502 seemed to be designed for micro-controllers. The fact that it is mostly famous for use in personal computers was due to Steve Wozniac choosing it for the Apple-II, and he did that mostly because the only other choice was the Z80 that was horribly slow (https://map.grauw.nl/resources/z80instr.php). Notice that a lot of Z80 instructions take 19 or more clock cycles, and nothing takes less than 4 clock cycles. The Z80 does have more interrupts (the 6502 only had IRQ and NMI), but no effort was made to provide low interrupt latency.

From what I've seen, the RISC-V is to the 2020s what the Z80 was to the 1980s. Processors such as these seem to be designed by academic types who want a scaled-down mini-computer on their desktop so that it will be a "joy to use," but they have no understanding or concern for real-world issues such as low interrupt latency.

where did you see that RISC-V has high latency interrupts?

AFAIK the Unprivileged Spec doesn't specify an interrupt system at all, so you can just use something custom (like shadow registers, though they're pretty useless if you allow for nested interrupts).
and even though the Privileged Spec does have interrupts, the latency would be basically nothing as no memory accesses ever occour during an interrupt sequence, because only internal registers get used.
and of course during an ISR you would use a few registers as possible so you don't have to save and restore a lot of them.


Now you've lost me... RISC-V is designed to be simple and easy to understand with optional extensions to increase functionality if desired.. It's pretty much the opposite of bloated as you only include what you need.
Moat current RISC-V systems aim for modern functionality so they use the more complex Privileged Spec for things like memory protection, multiple system modes, etc.
Of course such features could seem like "bloat" to people who've mostly worked with basic 8 bit systems.


did you never write assembly in a specific ISA and thought to yourself "damn this is nice to use"? that's exactly what they mean, inlcuding myself.
RISC-V has a very nice ISA to write assembly for. fully orthogonal (no specific registers like on the 6502/Z80), no status register to worry about, and of course with macros you can build yourself powerful pseudo instructions.

Remember though that the Z80 often had a faster clock than the 6502 - 4MHz was common, I think.

Though I do recall an informal side-to-side comparison of a 4MHz Nascom Z80 system against my Tangerine 0.75MHz 6502 system, both running MS basic (32 bit floats for the Nascom, 40 bit floats for the Tangerine) had the 6502 coming out slightly ahead.

(Personally I was never a fan of the Z80 instruction set; I like the 8080/85 set with which the Z80 is backwards compatible, but the extra Z80 instructions - with the possible exception of the register exchange, which was handy? They never seemed to do quite what I wanted them to do. A couple of employers ago, I had to rewrite someone else's non-standard floating point code to give better precision and a more standard format, on a Z80. It made my head hurt, but at least it was a change from PIC assembly...)

Neil

Indeed, you simply can't compare clock speeds of z80 and 6502 - you need to count memory accesses. There's a difference in architecture.

I'm interested to know if RISC-V has, or could have, the sort of shadow registers which ARM has, allowing some few private registers for each level of interrupt. That saves on stack churn.

Well as said, the unprivileged ISA doesn't specify an interrupt system, so you can basically do whatever you want as long as it doesn't interfere with the standard.
So you could implement shadow registers if you wanted to, just none of the existing compilers would be able to make use of them.

The shadow registers were a feature of the older ARM architectures. Modern ARM Cortex has a mechanism where a number of registers (the "caller saved") are automatically pushed on the stack so that the ISR can be handled in a normal C function.

As far as latency is concerned, the ARM Cortex takes 12 cycles to save the registers, and automatically jump to the correct ISR. If a 2nd interrupt is pending when the first is finished, the registers are left on the stack, reducing latency. Since you already have a number of free registers, you can usually handle the entire ISR in fewer cycles than a 6502. This is especially true if multiple interrupt sources are used with different priorities.

Interesting - thanks! (Link for more info.)