so it makes sense to "carry" that form on with
GETBIT
GETPIN
One trick I learned many years ago to avoid confusion is to read the documentation.
I never assume that one MCU is going to behave the same as another.
so it makes sense to "carry" that form on with
GETBIT
GETPIN
One trick I learned many years ago to avoid confusion is to read the documentation.
I never assume that one MCU is going to behave the same as another.
so it makes sense to "carry" that form on with
GETBIT
GETPIN
One trick I learned many years ago to avoid confusion is to read the documentation.
I never assume that one MCU is going to behave the same as another.
so it makes sense to "carry" that form on with
GETBIT
GETPIN
One trick I learned many years ago to avoid confusion is to read the documentation.
I never assume that one MCU is going to behave the same as another.
Also, those instructions all work with indexing.
I like these:
GETBIT
GETBITN
GETPIN
GETPINN
The last one doesn't look right with two N's.
GETBIT
GETTIB
GETPIN
GETNIP
This is the worst idea you've had, TonyB_.
(I'm pretty sure you're joking, though.)
It's not my fault, this is what happens when someone types GETPINN.
My recent post suggested a new suffix for these. Is that acceptable?
As I said, the problem is that having WZ on the suffix implies that the Z flag will be set according to the result (as in set when the result is 0) and not what will actually happen with these instructions.
That, to me, is the crux of the problem. So it needs to be something else that indicates it.
Also, I don't like GET* at all.
To me (and I think it's safe to say, Chip), all the WC and WZ suffices indicate is that the particular flag is affected (may change). I humbly submit that the "set according to the result (as in set when the result is 0)" is an inference, not an implication.
To me, the crux of the problem is whether one can accept the idea of flag states being directly controlled, or being restricted to the ALU state output only. It seems obvious to me that we have some who can and some who can't (or won't), but only for the Z flag; Direct control of the C flag is accepted without question.
I find this inconsistency quite puzzling.
It's because there is no difference for C. Whether you shift into or test, C is set when 1 (or parity)
Z is a special case specifically meaning Zero, not Non-Zero. It is the same in ALL micros that have a Z flag. And there are special instructions that rely on that setting, such as the conditional execution IF_Z and IF_NZ, DJZ, DJNZ, TJZ, TJNZ.
It's about time some of you wrote some programs that use these things instead of commenting on theory. Then you'll find the issues and inconsistencies.
In some cases Z and C are flags in the conventional sense, in others they are single bit registers, based on the context of the instruction using them.
It is a pragmatic reuse of logic, I see no reason for any changes.
In some cases Z and C are flags in the conventional sense, in others they are single bit registers, based on the context of the instruction using them.
It is a pragmatic reuse of logic, I see no reason for any changes.
Yes, because TEST in the name implies that it is directly related to the "normal" test instruction. Which works differently and sets the flags in a different way. That will make a lot of people confused.
Yes, because TEST in the name implies that it is directly related to the "normal" test instruction. Which works differently and sets the flags in a different way. That will make a lot of people confused.
Do you guys think GETxxxx mnemonics would be better than the current TESTxxx mnemonics, though?
Yes.
I found useful the following way to think about it:
GETBIT/GETNBIT and GETPIN/GETNPIN can use either C or Z flag as accumulator for bit operations (Write=load / AND / OR / XOR).
Write (load) operation copies the selected bit into the accumulator (C or Z).
This means that Z flag's value will be the opposite of the expected value for other instructions:
WZ when the selected bit is zero results in Z=0 (instead of the usual Z=1).
Maybe you will find this useful for documentation.
Do you guys think GETxxxx mnemonics would be better than the current TESTxxx mnemonics, though?
Yes.
I found useful the following way to think about it:
GETBIT/GETNBIT and GETPIN/GETNPIN can use either C or Z flag as accumulator for bit operations (Write=load / AND / OR / XOR).
Write (load) operation copies the selected bit into the accumulator (C or Z).
This means that Z flag's value will be the opposite of the expected value for other instructions:
WZ when the selected bit is zero results in Z=0 (instead of the usual Z=1).
Maybe you will find this useful for documentation.
Okay. I like those mnemonics, too. That is what we will do.
And, as someone pointed out, these instructions will go well with GETNIB/GETBYTE/GETWORD, which also permit indexing via ALTx instructions.
Cluso99, could we have your blessing?
That sounds fine. As I said, it works differently.
Could you leave in the TESTP/TESTPN/TESTB/TESTBN WZ/WC
instructions and compile to the reverse the Z please? (ie Z sets if =0 as expected for test instructions)
Note I deliberately left out WCZ as the silicon will not support that result. I'd even be happy with just supporting WZ if easier.
BTW I wasn't having a meltdown. I just believe that it's an exception and still don't have a nice solution.
Just had a horrible thought...
What about GETNIB etc WZ/WC/WCZ ?
Fortunately, there are no WZ/WC/WCZ options for GETNIB etc
If you scare yourself half to death, twice, on the same day...
I don't want to change the meaning of TESTP(N) and TESTB(N) regarding Z because it will break my ROM code and I don't want that worry. Your ROM code would be affected, too. Let's just think about anything else.
Just had a horrible thought...
What about GETNIB etc WZ/WC/WCZ ?
Fortunately, there are no WZ/WC/WCZ options for GETNIB etc
If you scare yourself half to death, twice, on the same day...
Let me think about that... Ummm
I don't want to change the meaning of TESTP(N) and TESTB(N) regarding Z because it will break my ROM code and I don't want that worry. Your ROM code would be affected, too. Let's just think about anything else.
Sure. We can revisit later as it's just a compiler add-in and I think it's a nice instruction.
Am not really wanting to open up more discussion as it seems things are perhaps finally converging a little? but it was not fully clear to me...are we still thinking of having ANDC, ORC, XORC suffixes or are the mnenomics now going to be expanded into this:
On that note, given the nature of the explicit flag write that these instructions are, it wouldn't be out of order to compact four opcodes into one by using each CZ bit encoding for one of the flag writes.
Comments
Also, those instructions all work with indexing.
I like these:
GETBIT
GETBITN
GETPIN
GETPINN
The last one doesn't look right with two N's.
GETBIT
GETTIB
GETPIN
GETNIP
GETNBIT
GETPIN
GETNPIN
This is the worst idea you've had, TonyB_.
(I'm pretty sure you're joking, though.)
Maybe this is what we go with.
It's not my fault, this is what happens when someone types GETPINN.
Whatever gets done, we can eventually Make Some Noise about this in the documentation. It won't seem as bad.
Z is a special case specifically meaning Zero, not Non-Zero. It is the same in ALL micros that have a Z flag. And there are special instructions that rely on that setting, such as the conditional execution IF_Z and IF_NZ, DJZ, DJNZ, TJZ, TJNZ.
It's about time some of you wrote some programs that use these things instead of commenting on theory. Then you'll find the issues and inconsistencies.
It's fundamentally wrong. There's no way around it.
So you may as well leave it as is
In some cases Z and C are flags in the conventional sense, in others they are single bit registers, based on the context of the instruction using them.
It is a pragmatic reuse of logic, I see no reason for any changes.
C.W.
Do you guys think GETxxxx mnemonics would be better than the current TESTxxx mnemonics, though?
I agree.
Yes.
I found useful the following way to think about it:
GETBIT/GETNBIT and GETPIN/GETNPIN can use either C or Z flag as accumulator for bit operations (Write=load / AND / OR / XOR).
Write (load) operation copies the selected bit into the accumulator (C or Z).
This means that Z flag's value will be the opposite of the expected value for other instructions:
WZ when the selected bit is zero results in Z=0 (instead of the usual Z=1).
Maybe you will find this useful for documentation.
Okay. I like those mnemonics, too. That is what we will do.
And, as someone pointed out, these instructions will go well with GETNIB/GETBYTE/GETWORD, which also permit indexing via ALTx instructions.
Cluso99, could we have your blessing?
Could you leave in the TESTP/TESTPN/TESTB/TESTBN WZ/WC
instructions and compile to the reverse the Z please? (ie Z sets if =0 as expected for test instructions)
Note I deliberately left out WCZ as the silicon will not support that result. I'd even be happy with just supporting WZ if easier.
BTW I wasn't having a meltdown. I just believe that it's an exception and still don't have a nice solution.
What about GETNIB etc WZ/WC/WCZ ?
Fortunately, there are no WZ/WC/WCZ options for GETNIB etc
If you scare yourself half to death, twice, on the same day...
I don't want to change the meaning of TESTP(N) and TESTB(N) regarding Z because it will break my ROM code and I don't want that worry. Your ROM code would be affected, too. Let's just think about anything else.
What happens if you want to write both Z and C ? I guess that is not possible or desirable and so the assembler should flag it as an error?
That isn't allowed, but the encoding is available. That's the existing hole.
BITx/DIRx {WCZ} share the opcodes with TESTBx/TESTPx WC/WZ.
Mmm, four pages and counting for something that probably wouldn't have gone past one with a macro assembler.
So there is just GETBIT/GETNBIT/GETPIN/GETNPIN instructions, and the WZ/ORZ/ANDZ/XORZ/WC/ORC/ANDC/XORC suffix things.
Sounds good.