Potato, potato... BDD doesn't like to call them modes, and recommends we follow, but other opinions are valid too. We all know what we mean and that's the important thing. (BDD might possibly have a point that more careful use of language might help in understanding, but for most of us that ship has sailed, and indeed I find the 816 easier to think about as a five-moded CPU.)

(Perhaps if I'd been more careful, and started with tomato, tomato, I might have communicated more clearly too...)

Choosing the D bit in the Processor Status Register as an example...

I think we can all agree that manipulating D (the Decimal Mode bit) is the means by which we access certain useful capabilities provided by the processor. Likewise we can agree that D defines the context of the code we write.

Uhhh... which maybe sounds pretentious! All I mean is, you need to be aware of D as you're writing (or reading) code, because losing track of D's status puts you at risk of losing track of what the code does.

Can we also agree that the same applies to the 816's Emulation bit and to the x and m bits? It can hardly be controversial to observe that losing track of those bits' status puts one at risk of losing track of what the code does! (Thus there's a potential pitfall, even though it's counterbalanced by the considerable benefit of not having to resort to multi-byte opcodes.)

In my view, these bits have a lot in common. But, even so, I won't protest if some folk do refer to them as "mode" bits and other folks don't. For gosh sake -- there's no danger of misunderstanding!

-- Jeff

Edit: Oops, crossed in the post, Ed, but yes -- "We all know what we mean and that's the important thing."

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

oof, i did not intend to derail the thread that much because of simple naming.

though i do agree that it should be allowed for someone to say stuff like "A is in 8-bit mode" without being corrected due to technicalities. for as long as it's clear what they meant.
obviously someone saying "the CPU is in 16-bit mode" is very ambiguous and needs some clarifying, but if they mention A, X/Y, and a bit width, then it's pretty clear what they mean regardless of if they call it "mode" or "width".

When writing large amounts of 65C186 code, do you guys generally have specific policies on how these flags should be left, as part of calling conventions? Or is it a matter of having any routine that requires them to be set in a particular way ensure that they are set that way on entry?

For myself, with limited experience, I think I expected per-routine conventions but found I was using per-project conventions. It's possible for a routine to change modes and then put things back, if that's advantageous.

The bulk of what I've written for the '816 (a VM for the BCPL compiled code totalling some 16KB at present), generally leaves register and memory in 16-bit mode. ('full native')

The underlying operating system is written in 65C02, so when compiled for the '816, the entry points remember the mode/widths/etc, save the mode/flags/registers as required, run in 8-bit/6502 mode then return to the caller in whatever mode it was in when it got called.

This means that the OS can only be called from the first bank and it can only deal with data in the first bank which for me is exactly what I want as I have no code running in any other bank as it's all claimed by the BCPL VM which makes it look like linear address space to BCPL programs because that what they wanted back in '67 so that's what it is today.

-Gordon

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

for C stuff Calypsi defaults to 16-bit A, X/Y. though for assembly projects i use 8-bit A and 16-bit X/Y. obviously unless 16-bit math or memory accesses are required.
for calling functions if i need a 16 or 32-bit value (or pointer) i use X and Y. X for the Low Word and Y for the High Word. A is used for single byte functions like printing a character or 8-bit value, or as an extra for other functions.
everything beyond those just sits on the stack before the function call, with local symbols to access them via the stack indexed addressing mode.
because keeping track of raw numbers is a pain, so per function symbols makes that much easier

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

A quick thank you to everyone so far. A great wealth of information here.

Playing around last night, I can see benefits in switching back and forth between register sizes now. Depending on the task, it can be much faster and compact to stay with 8 bit width and alternately the same can be said for 16 bit width.

Sometimes the overhead of switching the flags is enough to warrant staying with a particular width. Depends on how much you want to micro-optimise I guess. To me that's half of the fun right there.

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

Absolutely! And those are the sorts of mental challenges I enjoy now and then too. The never ending puzzle of "How can I do this better?"