I don't know if it rises to a formal definition, but both the 65816 datasheet and the Eyes and Lichty programming manual use the terms "8-bit mode" and "16-bit mode" a number of times. The later also states:
This is the only place in these two documents that the "width" of the registers is used. I prefer "mode" to "width", but both get the point across.

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

_________________
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 have found it useful to think of the '816 as having five modes - it's a quick way to get to an explanation of what it's like to program.

We should all, of course, be making sure we understand each other, with our various terminology, and I think we do.

No doubt about how the 816 operates but this is just terminology. You're taking a narrow view of the term "mode", applying it only to whether the processor is in "emulation mode" or "native mode". Equating other common usage to errors or confusion seems like a weak explanation.

I agree that using "8-bit mode" is imprecise without knowing that the processor is operating in native mode. If native mode is implied however, using "8-bit mode" seems perfectly acceptable.

That quote simply introduces the concept of an emulation and native mode. It doesn't prevent native mode from having both an 8-bit mode and 16-bit mode. This phase just as easily supports the alternate view:Of course this can only be done in native mode.

Edit:
I knew I should have included the code snippet. I wanted to get off to lunch and didn't want to bother with formating.

That only works in native mode. A similar situation occurs when switching from native 16-bit to emulation and back to native 16-bit. I've verified that on hardware a while back to make sure my emulator treated it correctly.

_________________
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, we're on the same page. Context is critical. It's usually clear in the discussion or code but I admit "8-bit mode" and "16-bit mode" isn't precise without the proper context.


I debated having this discussion here because the OP is struggling with terminology and operations. But I hope it points out that his question and others relate simply to ways to describe how the processor works. I had similar confusion to start, but it soon passes as you dive in deeper. Of course this site helps a lot.

For example, I wouldn't be surprised by a question on the "C register" next. It's just a construct to describe how the processor works. L&E describe it thus:This provides necessary precision but seems at odds with the alternate mnemonic allowed such as TSA in place of TSC. This of course is on the original designers. For me, a variable width accumulator (and a hidden B byte) is sufficient. My emulator, for example, doesn't model the C accumulator internally.

In the end, we can't hide from the fact that two definitive documents use terminology that is less than precise, but provides a good shorthand given the proper context. Absent some other definitive document how can we be on the same page?

I think for most people the documents are useful, rather than definitive, and we get on with the task in hand: writing code, helping people, debugging things.

It's rare indeed, I think, that anyone becomes confused beyond rescue because they came across some unhelpful terminology. But I agree it's worth trying to be more helpful, rather than less helpful!

Writing technical document is difficult, and the result is often flawed in some way - E&L is just one example of many. But I think the document succeeds in lifting the reader up to a better level of understanding.

(What tends to make these kinds of discussions interminable is an insistence on one specific terminology. Phrases like "I prefer" and "most people say" are useful to de-escalate.)

Apologies. I did not intend to spur a long tangent on a newbie friendly topic, although this is not the first occasion and regulars are ready and able to tangent.



65816 introduces three additional mode bits and five permutations are valid. One mode (Emulation) maintains legacy cycle counts and vectors. This was necessary for its first target in Apple IIgs. The other four modes (Native) set accumulator or index register width. One native mode has 8 bit registers. Two modes have a mix of 8/16 bit registers. One mode has 16 bit accumulator and index registers. This latter mode is favored as a default among many 65816 programmers.

When I'm being lazy, I may describe any use of 16 bit registers as "16 bit modes" and the remaining two cases as "8 bit modes". They are definitely modes because they have modal state. However, this description is from the view of implementing a bytecode interpreter and not writing 65816 programs. To write a bytecode interpreter, I'd probably have four or five byte dispatch routines which share the majority of implementation detail. This would eliminate the requirement to check flags before the execution of each instruction or addressing mode.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!