Hmm, if knowing _do_method_entry_point always tells you where vtable is going to be, then it might be okay. In your original code, vtable is 3 bytes beyond _do_method_entry_point, so if _do_method_entry_point+3 (rather than _do_method_entry_point) -- which is the same as vtable -- is stored at [obj], _do_method_entry_point is no longer needed. Obviously, you'll know where _do_method_entry_point+3 is at the same time you know where _do_method_entry_point is. Now, where vtable is located relative to _do_method_entry_point may be another question.



No. (abs) gets the (intermediate) address from bank 0; (abs,X) gets the address from bank K (the PBR) rather than B (the DBR), which means vtable would have to be in the bank of calling code, which pretty much confines you to 64k for all the code and address tables.

I should offer the disclaimer that I am just speculating here with all of this, and I may be overlooking something that I'd encounter if I were actually writing and experimenting with code.

<spammer's post content deleted, but post retained as a place keeper>

BTW: is it only me who can't really understand the 65816 addressing mode descriptions in the 65816 datasheet from WDC?

I tried to find some addressing mode that for a jump, would fetch a two byte address from $00FFFC, and then jump to this address in bank 0, preferably in emulation mode (I think you guess what I want to do...) but I couldn't even decipher what the JML (ABS) resp. JMP (ABS) do.

So I actually store a "JMP ($FFFC)" (resp. a JMP directly to the address read from $00FFFC/D) somewhere in bank 0 and do a long jump there (can't do a direct long jump to ($00FFFC) via self-modifying code, as code runs in ROM). But that's absolutely not elegant...

André

fachat, that's all you can do. And that is precisely why the 65xx architecture is not suitable for object oriented or functional programming at all, for both styles rely heavily on polymorphism implemented through such mechanisms.

BRK and COP are perhaps the only instructions implementing an "addressing mode" anywhere near what you're looking for, despite having its operand address hard-wired.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I understand them but only because I've run different sorts of code on my POC to see just what happens (reaching for the reset button on occasion).

The language used in the data sheet leaves something to be desired in clarity and even contains some outright errors. Not sure who does that documentation at WDC, but it's probably safe to say that the documentation work doesn't have a lot of priority around there.


Perhaps the following may be of some help:


In JMP (ADDR), ADDR is stored in bank $00 RAM, but the actual jump is into the current program bank defined in the MPU's PBR. With JMP [ADDR], ADDR is also in bank $00 RAM, but the jump occurs to the bank specified at ADDR+2.

As you can see, JMP [ADDR] and JML (ADDR) accomplish the same thing. Syntactically, JML is an oddity, as the addressing mode symbology doesn't conform with other representations for indirect long addressing (e.g., LDA [ADDR]). My suggestion is to ignore the JML instruction, as it acts as an alias that is analogous to using INA as an alternative to coding INC A.

Incidentally, if JML ADDR is used in the WDC assembler in place of JMP ADDR you will end up with a 24 bit operand instead of 16 bit, even if the target address is entered as 16 bits. That is, JML $1234 will generate:


using up four bytes and four clocks to do what three and three would accomplish with JMP $1234.

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

@Garth, thanks, that explains it. I've only been looking at the general 65816 data sheet so far, which is ungrokable.

@BDD, it seems you missed the point with the indirect address as pointed to by the opcode being in program bank with (ABS,X) addressing vs. being in zero bank with (ABS)...

Good to see I'm not the only one being confused, but I'll have a closer look at the programming manual, that was a good pointer!

But on the other hand, what opcodes or addressing modes would you like to see on a "new" version to support object-oriented or functional programming?

André

I'm confused. Which point did I miss?

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

Sorry, maybe it's me but I did not read from your explanation, that with
JMP (ABS), ABS is an address in bank0, and with JMP (ABS,X), ABS is an address in the program bank.

André

I did say that about JMP (ADDR) and JMP [ADDR].

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

JMP (ADDR,X) pulls the vector from bank K, not bank 0. Contrast this with JMP (ADDR) which pulls the vector from bank 0 only. That is the source of everyone's confusion.

Consider, without pulling from bank K, the following code cannot work:

I'm not confused with how it works. Apparently the confusion was in the translation.

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

I don't think the 6502 is a pipelined processor at all. Even the NOP instruction takes 2 clock cycles (fetch + Execute). If it were pipelined it would take only 1 cycle.

And the instruction decoder uses a PLA, so, it looks more like microprogramming.

But, I must agree, the instruction set is, indeed, reduced. (missing ADD_without_carry, for instance)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks for the explanation about the 6502 pipelining. I must admit there is some pipelining: last steps of execution in parallel with next instruction fetch. I think this is not always possible, but it can be done on some instructions, and is far from those pipelines found on typical RISC processors.

I don't want to look as being too critic about the old 6502. It was a remarkable design. Probably the best MIPS/$ and MIPS/#transistor of its time.