Sorry, but the 65C816 does all of this and much more elegantly. Best of all, it's already in production and can be run at speeds up to 20 MHz (6T cores).

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

Really? Looking at the four objectives he listed for the 65T2, it seems to me that the 65C816 might fail (perhaps dramatically) on one of them: "equivalent MOS transistor and resource budget as a 6502 (or 65C02)." Is the 65C816 that parsimonious a chip? (I am no expert, but I find it difficult to see how it would be.)

Though now that I re-read that objective, it occurs to me that at least some, if not all, of the 65C02s might have been significantly larger than the original NMOS chips.

_________________
Curt J. Sampson - github.com/0cjs

_________________
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'd suggest it might be good to have a new thread about 65T2. Snial's substantial post brought several things into play:
- the objectives, which should forestall any spurious mention of '816
- a historical perspective, which might help, or might distract from the technical proposal
- a new assembly syntax, which might in fact be a distinct and separable line of thought
- the programmer's model and instruction set: which is surely the most interesting thing (bearing in mind the objectives)

Of course, a historical perspective can be very helpful indeed. And of course, the '816 is an interesting effort, just as the 6809 is.

But - for me - it would be very interesting to look into the 65T2 specifically
- is it feasible, or has anything been overlooked
- what is it like to program
- how well does it serve as a target for C
- what other strengths and weaknesses might it have

If two or three people are sufficiently interested, or if snial is sufficiently energetic and motivated, the machine could make that crucial step from a paper exercise to an implementation project, which in my view is always good to see.

There will always be those who don't get it - it's necessary to forge ahead, and see what positive interest can be picked up. The negative interest has to be inspected for value and not taken to heart.

(The same points apply, of course, to other paper designs: some fraction make their way to some sort of implementation.)

Why can't I find a "thumbs up" for your post, Ed?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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

BDD, we can all see exactly where you're coming from. It doesn't make you right. A crusade against - what - maybe 1% of posts - really doesn't leave you looking good, and it's not effective either. Just concentrate on the threads which you do find interesting.

_________________
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?

Sure, but that's a particular hobbyist's perspective, and from a modern point of view, addressing today's concerns and ease of development, the 6502 in its entirety is a complete dead-end path that should be ignored in favour of modern small processor designs. Thinking about the 6502 at all is no more justifiable than thinking about redesigns of the 6502 using the same transistor count as the original NMOS chip. We're all just setting arbitrary limits and goals here for fun, not for efficiency.


Which sounds like a pretty valid historical investigation or hobby project to me!


Well, perhaps we should start by remembering that the post in question itself discussed the '816. Even that aside, I'm with BDD here:


Exactly. If one's examining the design of the 6502 and playing around with a redesign that should allegedly improve it for certain purposes, it makes perfect sense to look at how someone else did it and compare the two new designs. Since the '816 actually appears to meet several of the objectives of Snial's design, it's not only valid to ask, "what are the differences between the two and their effects," but one of the most interesting and educational questions. So I'm pleased to see it raised, though I wouldn't mind a bit more detail on the differences and a deeper investigation of their consequences.

It might also be worth remembering that too much focus on trying to corral discussions into their "correct" places and making sure that people aren't going "off-topic" can be more disruptive to a conversation than just letting it go where it goes. This isn't Wikipedia or a business meeting; especially on topics like this it's more a brainstoming session.


While I agree that the foundational theories seem to have some issues that should be addressed, I suggest that the "zero page," narrowly defined, is not a thing that makes a 6502 a 6502. After all, the 6800 has a zero page as well. I propose that a core feature that gives 6502-nature is actually indirect indexed addressing through a pointer in RAM, which his design perserves, and is why his design is more like a 6502 than the 6800, despite his lacking a zero page and the 6800 having one.

_________________
Curt J. Sampson - github.com/0cjs

Since I got interested in electronics to build calculators, decimal mode is really useful to me. If we're dreaming up processors, I would definitely keep it in! An alternative is how the 8051 does it where decimal numbers are added the same as binary numbers but there's a separate decimal correct instruction. I suppose that could be faster than having a decimal mode. Even better would be to give decimal addition it's own instruction like the MSP430, but I might be the only person using it.

Well, do keep in mind that you can just write your own code to do a decimal adjust, as well. Decimal mode or a decimal adjust instruction are just optimizations, and probably not particularly important ones when building a calculator used at human speed.


That's how the 6800 and the 8080 did it, but that's slower than having a decimal mode becuase you need to execute the extra adjust instruction with every decimal operation. This is why the 6502 designers chose to have a decmal mode instead. Having a mode still introduces its own issues: in a program you need to keep track of which mode you're in (or push/pull the status flags to preserve the previous mode) and if you have a system that runs arbitrary code and takes interrupts, the interrupt handler needs to clear decimal mode if that would affect any of its operations.

For most purposes, I think it's perfectly reasonable to reduce or remove CPU support for decimal arithmetic if CPU resources are very tight.

_________________
Curt J. Sampson - github.com/0cjs

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

I dispute this premise. This premise seems to have been universally decided sometime around 1990, when C compilers weren't very wise. This premise continues, principally because cc65 is the most common C compiler available for the target nowadays, and for some reason people assume that cc65's limitations would be general to any C compiler.

Modern C compilers do a significantly better job of register management than the older compilers. This functionality maps well to letting a compiler manage the zero page of a 65xx processor, in order to keep the majority of active variables in zero page. Modern C compilers are also excellent at dead code elimination and link-time optimization, both of which will be critical for a 6502 target.



Again, I dispute this premise. This is simply no longer the way that modern C compilers emit code. In practice, both gcc and llvm have near-optimal register allocation and management, and this would map at runtime to 65xx code that used zero page in a near-optimal fashion. In practice, a modern C compiler targeting the 6502, would spend little time accessing the C stack. In fact, with link-time optimization, many small C programs would maintain variables entirely in zero page, without using any stack whatsoever.

Anyway, the best disproof is an example of the opposite of the premise. I've had some mild initial successes with porting llvm to the 6502 -- the assembler and disassembler are now working well enough -- and I intend to continue that work until llvm-c can target the 65xx series. It'd be easier with some help, if anyone felt like joining in. https://github.com/johnwbyrd/llvm-mos

> I've had some mild initial successes with porting llvm to the 6502...

Excellent!

BTW, on re-reading Snial's original message, I see that he seems to have said this, though perhaps not in the clearest way, and I (and perhaps others) may have just gotten lost in the weeds with all the details flying about:


The difficulty here that I (and I believe others) are falling into is that, as 6502 users, we tend to link the zero page and the indirect addressing modes that use it, though they are orthogonal, because on the 6502 indirect addressing must use the zero page (i.e., there is a (zp),Y addressing mode taking an 8-bit address, but no corresponding (addr),Y addresing mode that allows specifying a full 16-bit address). I see no reason offhand why one couldn't simply change all of the indexed mode opcodes to take a two byte address and thus do indirect through any memory location (though with an obvious reduction in efficiency).

What Snial's approach does is actually a double indirection: he changes the function of the current indirect addressing opcodes (which use an absolute address) to instead first indirect through the stack pointer to find a location, and then indirect again through the location itself. You might think of this as overloading the stack pointer to be also a "direct page" register, much like the 65816's DP register.

I wonder about both the performance of that (since now two additions are necessary rather than just one) and the removal of the ability to use absolute addresses (what does one do with global variables that are pointers?).

_________________
Curt J. Sampson - github.com/0cjs