Well, so long as the function you're calling is not using the Y register. If it is, you now need to save and restore it with every call, either in the caller or the callee. (Obviously there are are several ways to do this, some of which will still be faster than the unoptimized version here.)

It's in figuring out what the best optimization is when various functions are glued together where compilers really shine, of course. Sure, a good assembly language programmer will be able to do this fairly quickly and sometimes better than a compiler for any individual circumstance, but doing it everywhere, and redoing it when the code changes, is a lot of work. Tweaking the architecture to make it easier for a compiler to do its thing this way thus makes a lot of sense. (Though I'm not saying here it's not possible that keeping the zero page to treat as a big bank of pseudo-registers might not work as well or better.)

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

I would tend to favour callee-saved conventions. I once wrote a blog post about that:

http://oneweekwonder.blogspot.com/2014/03/caller-convention-calamities.html



I'm sure that's true - the 65T2 compiler I'm thinking of wouldn't really class as an optimising compiler - merely a tolerable one.



The critical issue for compiler and architecture performance as I understand it is bandwidth. A register rich multi-operand architecture obtains performance by maximising the local bandwidth: having 3 operands within a single instruction means two reads and one write of likely 32 or 64 bits each can take place and the operand field size determines the proportion of data for which that's true.

e.g. <OpCode:4><DestReg:4><Src1Reg:4><Src2Reg:4>

Results in a maximum processing bandwidth of (3*RegisterWidth)/16 bits per instruction, whereas an instruction format of the form:

<OpCode:8><Operand:8>

Results in a maximum processing bandwidth of RegisterWidth/16 bits per instruction, up to 3 x less efficient, assuming that the 16-bits for both instructions are read in the same period.

The trade-off is that the xxxReg:4 fields capture a smaller proportion of operations than an Operand:8 field, so xxxReg:4 fields require more spilling and filling, but because there are diminishing returns on the proportion of operations captured as the operand field increases, there's a point at which the multiple smaller fields are more beneficial than a larger operand field. That trade-off comes at about 2 to 3 bits. So, 2x or 3x 4 bit operand fields are more efficient than a 1x8-bit operand field. Incidentally, this means that a variant of the 6502 which replaces the direct page with 2x 4-bit register fields ought to be marginally more efficient: <OpCode:8><DstReg:4><SrcReg:4> (2*8/16 bits per instruction of processing).

At the same time, the <OpCode:8><Operand:8> is still 33% more efficient than <OpCode:8><Operand:16> and thus zero-page (or rather single-byte) operands provide a real performance advantage over architectures that don't support them.

Nevertheless, a compiler targeted at an architecture that relies on absolute zero page memory locations will still find itself spilling and filling zero page locations, because it is simulating a single-operand, register rich architecture: the zero-page is a software managed cache for the entire set of stack frames.

This is the advantage that an architecture with support for stack frame addressing has over an absolute zero-page architecture, because that kind of spilling and filling isn't needed. Instead the stack frame pointer is merely adjusted. Operands don't need to be copied out to make space for new operands (thus saving 50% of the effort when building up a new stack frame) and Operands don't need to be copied back in at the end of a function (thus saving 100% of the effort when returning to a previous stack frame).

Both the 65T2 and 65C816 support that kind of stack frame (using ADS #n or by changing the direct page register), which is a significant performance improvement for a compiler - and it also makes compiler writing easier. A human assembly code writer can mitigate this because they can perform a global analysis on how to map stack frames to zero-page, in much the same way a 'C' compiler does for 8-bit PIC architectures.

Certainly we would agree that the 6502 can do these things in software. My point is that the llvm backend will make heavy use of this type of operation. My goal is not necessarily to make that code run faster -- I'm not sure that it can, given that 8-bit accumulator, which is the alpha and the omega of the 6502 -- but rather to make the code as small as possible.



Well, let's take your restriction as a given. In that case, I could use a set of instructions that perform more or less the following operations:



Now there are several ways I can represent this instruction sequence succinctly. I can write a small interpreter, that reads the opcode and the operands as I described them in my previous post. However, I am hoping (though not assuming) that the hardware can, partially or completely, decode this set of operations from a concise representation. And it's above my skill to determine whether this can be done in very few transistors.

As usual, Woz was completely right, way back in 1977, when he wrote the following: "While writing Apple BASIC for a 6502 microprocessor I repeatedly encountered a variant of Murphy's Law. Briefly stated, any routine operating on 16 bit data will require at least twice the code that it should. Programs making extensive use of 16 bit pointers (such as compilers, editors and assemblers) are included in this category. In my case, even the addition of a few double byte instructions to the 6502 would have only slightly alleviated the problem. What I really needed was a hybrid of the MOS Technology 6502 and RCA 1800 architectures, a powerful 8 bit data handler complemented by an easy to use processor with an abundance of 16 bit registers and excellent pointer capability." Personally I feel the 65T2 solution acknowledges the first of Woz's problems, but it ignores the second. This is not a deal breaker by any means; I just feel that perhaps the concept is focused on optimizing the wrong thing.

Historically, the processor designer that took Woz's words most to heart, was Sophie Wilson, a key designer for the ARM microarchitecture. (Sophie was at the time known as Roger Wilson.) https://en.wikipedia.org/wiki/Sophie_Wilson . Sophie provided one of the first CPU cores with a big pile of registers. Wilson was exceptionally aware of the 6502's design; she spent a great deal of time at WDC before helping to design the ARM. The ARM1 ran about 25000 gates. As a side note, it might be an interesting exercise to see how many ideas from the original 1985 design, might be backported trivially to a 65xx. http://www.righto.com/2015/12/reverse-e ... or-of.html

Lastly, realize that this whole discussion sidesteps a critical question, which is exactly what constitutes efficiency or "friendliness." This conversation seems to assume that the principal kind of efficiency to be sought is in the number of cycles saved. In practice, for any medium-sized program, the 6502's 16-bit memory limit becomes incredibly important incredibly quickly. Especially given the 6502's limited memory, a compiler author needs to consider the speed optimization case as well as the size optimization case, when considering whether a feature is language-friendly or not.

That's why we have the 65C816.

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

I think once again BDD you've missed the purpose of the thread: this is your third time chipping in with the 816. Surely, after the first time, everyone following the thread will have got the point. The thread continues because it isn't about choosing an existing design, it's about making a different one. It's completely fine if you are not interested in such a question. It's not quite so fine for you to keep on as if no-one else has seen the light.

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

Yes, but we heard the '816 recommendation the first three times BDD posted it. I've already added addressing support for it into llvm-mos. https://github.com/johnwbyrd/llvm-mos/w ... r-assembly

The 65816 is not a C-friendly 6502, for the following important reasons:

1. The 65816 still has the 6502's problems with paucity of registers. Yet it uses about as many transistors as the ARM1, a contemporary of the 65816. The ARM1 has 25 physical 32-bit registers. Now that is actually is a C-friendly design. All modern compilers practically, if not absolutely, assume that the target is register-rich. The only modern compilers that do not make this assumption, are either compilers for virtual machines, or toys.

2. The 65816 uses a bank-switched memory model, which C compilers have to take a lot of trouble to dance around. There is no support in ANSI C for pointers of different sizes, nor has there ever been. All the near/far pointer business in the 1980s and 1990s, were attempts to work around these limitations; but none of that was ever standardized across compilers. The ARM1 however has a flat 32-bit memory model... much easier to write a compiler for. All ARM1 pointers expand to 32 bits, regardless of how they are encoded in any instruction.

3. The 65816 likes 24-bit pointers, which no modern compiler supports natively... All modern compilers assume that pointers are a power of two in length.

In short, the 65816 design sacrificed too much in the name of backwards compatibility, when bus sizes were growing quickly beyond 16 and 24 bits.

Please don't lecture us any more about how C-friendly the 65816 is, without considering these points in detail.

It certainly does matter if you're exploring a historical "what-if," which is certainly one of my interests and I think (at least part of) Snial's as well. For the question, "What could the historical 6502 designers have done differently to produce something on which C would work better?" "Build the 65816" is clearly entirely the wrong answer; they would have come to the market much later (if at all) with a CPU much more expensive than the 8080, 6800 or Z80 and Apple and Commodore would have probably used the Z80 in their computers. That's probably not quite the answer we're wanting to see on forum.6502.org.


Perhaps a "Hypothetical C Friendly Post-6502 Successor" thread should be started for such ideas.

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

"No real responses" is simply not correct; there has been plenty of the further discussion you call for. Let's review some of the posts in order:

• In Snial's first post he mentions the 65816 approach and explains why he chose a different one: "The 65816 achieves it in part by adding another 16 or so additional addressing modes....The problem here though is that there's a chronic lack of instruction space for the extra addressing modes...."
• I replied right after BDD's first post on the '816 suggesting that it fails dramatically on one of Snial's critera (a criterion which is not inconsistent with the lead post). You replied immediately after that confirming that it totally blew off that criterion (10k transistors vs. 3.5k).
• BDD replied my post basically saying that from his perspective the transistor criterion was a secondary concern these days, which is clearly a personal opinion about his specific goals and doesn't address the goals of others. (Fair enough, but he's kind of coming across as if people are wrong in having other goals.) He also said that, "comparisons to 6502-family parts that are in current production and are in widespread use, both in commerce and hobby designs, are 100 percent appropriate," which is true, but Snial's post did explicitly make such a comparison. BDD's further claim that, "the 65C816 is a good fit to a C compiler" seems disputed at best; both Snial and johnwbyrd (who is actually building a modern C compiler for the 6502) disagree to at least some extent.
• In post 45, Snial said explicitly, "I'm aware of the 65C816 and it's very extensive addressing modes, including stack addressing modes and its DP register," noted that he has future plans to build an '816 SBC, and explained again why he's not following that route in this particular discussion.
• In yet another post I explain again that, "if you're going to go with "what could the original MOS 6502 have done differently without adding features that massively increase the cost," adding half a dozen registers is probably out." (The '816 adds the equivalent of eight 8-bit registers to the 6502 architecture.)
• Before BDD's third mention of the '816, Snial yet again here discusses both a clear difference between his approach and the '816 approach (dropping direct page adressing to focus on better stack-relative addressing) and mentions the '816 explicitly.
• After this BDD makes yet another post apparently suggesting that everybody who wants to think about any design other than the '816 is going terribly wrong; the entire contents of this post are, "That's why we have the 65C816."

All this in a thread where the original post specifically talked about the 6502, not the '816, in a way that's perfectly compatible with the interpretation that the '816 is not a 6502 in certain important senses. (And if you think an '816 is a 6502 in every important sense, you're essentially claiming that the low transistor count of the 6502, and thus low price, had nothing to do with its success, which is clearly ludicrous.)

If some people here are starting to feel like they're being told that the 65816 is the perfect solution to every problem, no other solutions should ever be considered, and any problems not solved by the '816 are not problems, well, you can see why.

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

That's fine; he seems interested in comparing his design to the '816, and I am as well (and learning quite a bit from this).


Nor is there anything suggesting the level of radical architectural changes introduced by the '816, which is pretty clearly a 16-bit processor. All the other processors he discusses are 8-bit, and none of the several changes he suggests involve changing the 6502 to be a 16-bit processor. (And let's remember radical architectural changes are radical architectural changes even if they are backwards compatible. We wouldn't say that a '386 is the same processor as an 8086, despite it being able to run 8086 code.)

I agree there's a lot of room for interpretation as to what he means by "6502," and given how vague the starting goals and critera were, I have no problem with discussion of the 65816 as a solution to one particular instance of the problem. But it seems to me that any sort of hardline "If it's different from the 65816 we shouldn't discuss it in this thread," or anything even approaching that, is unwarranted.


Maybe, maybe not. It does actually make a reasonable proxy for "don't just turn the 6502 into a full-on 16-bit processor, as the 65816 did."

(If all critera are completely open, the actual answer to this question is, "Redesign the 6502 to be more or less a PDP-11." That's why individuals making proposals are adding their own critera to maintain whatever they think of as "6502-nature." Some people think it's still a 6502 even with a 16-bit accumulator, and some think it isn't.)

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

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

BDD, you are addressing the wrong problem, in this thread. This thread is about designing CPUs, not about choosing them.

You'd do really well if you could try to respond to threads, not to posts. Each post has a context: each poster has a range of interests, each topic sets out some idea to be explored.

This is a 6502 forum, and Mike has very helpfully stepped in once or twice and clarified that this does include 6502-adjacent CPU designs, including new designs. It's abundantly clear what your interests are, and many people surely follow your POC threads with great interest. It's not clear that you've understood that other people's interests may differ from yours. Mike takes a much broader view than you do as to what's on topic here, and for that I am enormously grateful. There's room for breadth here: we have many subforums and any of us can start a thread at any time.

If your interests happen not to include the topic of some thread, that's a thread to leave alone - and that goes for all of us, of course.

Only if one of your constraints is that one must use an existing processor. (And even there, that leaves only the 6502 unless you also drop the constraint that some of us like to work within, that it has roughly the original transistor count.) That's clearly not at all what this thread is about, and I think that you trying to introduce that constraint may be the source of contention here.


Well, you have your idea of what "6502 hardware" is, which includes native 16-bit '816 code. My idea of 6502 hardware happens not to include that (I don't even write 65C02 code), nor does it include FPGAs, but I don't go around complaining whenever anybody brings up the '816 or asking for advice on what FPGA to use, even though it's outside my narrow focus. So perhaps we can agree that there are varying definitions of "6502" out there, we shouldn't jump on you because your definition happens to include things not included by others, and you shouldn't jump on others for the same reason. Surely it's not too hard for you to ignore this thread, as I'm sure you already ignore many others.

I've also been learning a lot about the 6502 itself from discussion of this 65T2 idea. It would be somewhat ironic if I learned less about the 6502 because you wanted to keep discussions limited to your idea of what constitutes appropriate 6502 discussion.

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