Except everyone pretty much agrees that P1 PASM MIN/MAX is backwards. We can change them on p1 too with a new version of OpenSpin/Proptool/etc.
To me this debate is maddening. So I need to just drop out of it. I've said what I think should be done, and that's that. This is P2, it's not even remotely compatible with P1, so why not fix things that were wrong?
The Clamp function with 3 operands is always Clamp(val, min, max) so your example would be Clamp(Evel, 1000, 2000). You would be making things broken in completely different ways if you did it with the value to clamp as the middle parameter.
And again, why put the dumb F on the beginning of all the PASM instructions for this?
F means "force". Force greater or equal, force less or equal, etc. Do you not like that? I just changed everything to it. I like CLAMP, but it's too long to add LE/GE to, plus an S. Contractions of CLAMP don't look good, at all. I don't love FGE/FLE/FGES/FLES, but they make suitable mnemonics. What do you think?
EDIT: And FORCE is too long, FORCLE looks bad, and FRCLE doesn't look good, either.
The Clamp function with 3 operands is always Clamp(val, min, max) so your example would be Clamp(Evel, 1000, 2000). You would be making things broken in completely different ways if you did it with the value to clamp as the middle parameter.
And again, why put the dumb F on the beginning of all the PASM instructions for this?
F means "force". Force greater or equal, force less or equal, etc. Do you not like that? I just changed everything to it. I like CLAMP, but it's too long to add LE/GE to, plus an S. Contractions of CLAMP don't look good, at all. I don't love FGE/FLE/FGES/FLES, but they make suitable mnemonics. What do you think?
EDIT: And FORCE is too long, FORCLE looks bad, and FRCLE doesn't look good, either.
I'm not following Roy's aversion to the F, because you cannot use an existing name for a new operation.
So it is not possible to simply flip MIN and MAX and back port to P1, without breaking legacy code big time.
FGE/FLE/FGES/FLES seem a good compromise, - they have a valid root, and can be safely fitted into P1 flows.
Can you point to the new mnemonic mapping for the new expanded Boolean Opcode group ?
That added a lot of extra power to the P2, but they are now harder to see ?
Can you point to the new mnemonic mapping for the new expanded Boolean Opcode group ?
That added a lot of extra power to the P2, but they are now harder to see ?
Like I said, I removed them. We now have MODCZ which can perform operations between C and Z, but when it comes to operations on bits, we can only read and write them. We can't perform logic operations on them, unless we do something like 'IF_C BITN D,{#]S' - that's an XOR on a bit.
Like I said, I removed them. We now have MODCZ which can perform operations between C and Z, but when it comes to operations on bits, we can only read and write them. We can't perform logic operations on them, unless we do something like 'IF_C BITN D,{#]S' - that's an XOR on a bit.
Am I reading that right ???
Are you saying you regressed back to the previous build, thus dropping the new Boolean Logic operators ??
... but why ? They worked didn't they ? And you reported had little logic cost.
They certainly added a lot of power to P2, and have the ability to save COG memory, and the P2 is rather COG memory starved.
If you read any PLC documents around IEC 61131, you can see that would have given a solid silicon base, for PLC designs.
The multiple COGs in P2 also make it a natural for safely encapsulating PLC control groups.
I've given examples of where even modern C compilers are able to make good use of such Boolean Logic operators, where they exist.
The result can be fewer jumps in code, which also helps HUBEXC.
I'm seeing a lot of plusses, but not grasping any minus - seems highly retrograde to me & a quite serious mistake ?
Like I said, I removed them. We now have MODCZ which can perform operations between C and Z, but when it comes to operations on bits, we can only read and write them. We can't perform logic operations on them, unless we do something like 'IF_C BITN D,{#]S' - that's an XOR on a bit.
Am I reading that right ???
Are you saying you regressed back to the previous build, thus dropping the new Boolean Logic operators ??
... but why ? They worked didn't they ? And you reported had little logic cost.
They certainly added a lot of power to P2, and have the ability to save COG memory, and the P2 is rather COG memory starved.
If you read any PLC documents around IEC 61131, you can see that would have given a solid silicon base, for PLC designs.
The multiple COGs in P2 also make it a natural for safely encapsulating PLC control groups.
I've given examples of where even modern C compilers are able to make good use of such Boolean Logic operators, where they exist.
The result can be fewer jumps in code, which also helps HUBEXC.
I'm seeing a lot of plusses, but not grasping any minus - seems highly retrograde to me & a quite serious mistake ?
They worked. I just couldn't make them presentable. They just didn't feel right, at all. They broke rules and didn't mentally flow.
Looking at the bigger picture for a moment, I think its time to stop hacking on the instruction set and move forward, because such changes ripple through so many aspects of not just he design but the P2 project as a whole.
I don't see 61131 applications caring whether it takes a few pasm instructions to manipulate a bit, given typical scan times.
I'm always slightly amused when people say something comes 'almost for free'. But there's always a cost, and it's usually time and lost opportunity.
They worked. I just couldn't make them presentable. They just didn't feel right, at all. They broke rules and didn't mentally flow.
I didn't see them breaking any Logic rules, and of course they will present differently. They are Boolean operators, so will never mesh fully with other opcodes, nor do users expect them to.
What you had was actually very clean and orthogonal, as boolean opcodes go.
The 8051 has boolean opcodes, but a smaller subset than what you had on P2, so P2 would have attracted 8051 users looking to upgrade.
Look at any Ladder Logic diagrams, and you can see whole control systems, done with boolean logic operators.
Embedded control also has many instances where flags are used.
I'll think about it some more. I need to find a way to present them that is congruous with the rest of the instruction set.
Please do. You may be over-thinking the need to be 'congruous with the rest of the instruction set'
Compilers do not really care what is congruous - they are all binary opcodes!!
Looking at the bigger picture for a moment, I think its time to stop hacking on the instruction set and move forward, because such changes ripple through so many aspects of not just he design but the P2 project as a whole.
I don't see 61131 applications caring whether it takes a few pasm instructions to manipulate a bit, given typical scan times.
I'm always slightly amused when people say something comes 'almost for free'. But there's always a cost, and it's usually time and lost opportunity.
I think what we have at the moment, while not having full bit-logic operations, is probably "done".
Looking at the bigger picture for a moment, I think its time to stop hacking on the instruction set and move forward, because such changes ripple through so many aspects of not just he design but the P2 project as a whole.
I don't see 61131 applications caring whether it takes a few pasm instructions to manipulate a bit, given typical scan times.
I'm always slightly amused when people say something comes 'almost for free'. But there's always a cost, and it's usually time and lost opportunity.
I think what we have at the moment, while not having full bit-logic operations, is probably "done".
A pity. These boolean operations looked really useful and they were already there. Representation could have been tweaked later if necessary.
They certainly added a lot of power to P2, and have the ability to save COG memory, and the P2 is rather COG memory starved.
The book entitled Microprocessor and Assembly Language Programming says "[The 8051] was optimized for 8-bit math and single bit Boolean operations." (emphasis added). I was just attempting to discover why all microcontrollers wouldn't have such direct functionality. The lack thereof seems surprising to me, but I haven't done much assembly language programming. Maybe the op-code space was constrained on some microcontrollers and didn't allow such "convenience" operations considering that such functionality could be done with multiple instructions, albeit somewhat more slowly. But we don't currently seem to be so constrained on the P2 design, as Chip keeps pulling rabbits out of hats to open up more op-code space. Anyway, although we all want to see silicon, if we've waited this long, it seems worth investing another couple days or so to continue the discussion/consideration. After all, with the development situation now being down to considering things at the bit level, it seems that the tunnel exit is just ahead (with plenty of daylight left). And if development seems done, remember that you spread icing on cinnamon rolls after they come out of the oven. (Yes, I'm attempting to appeal to Chip's love for analogies, which seems to surpass even that of Dan Rather)
If it is very useful what is one more day at this point.
And then there'll be the next very useful feature, and then the next one...
What's already in v18 gives everything needed to implement boolean flags; it's not like there's any missing functionality. The question is solely how many instructions it will take, and we're generally talking about a difference between 1 instruction (if jmg's proposal were implemented) and 1-3 instructions (if not).
The same thing applies to my earlier suggestion of a way to set a register to the value of C or Z. I thought it would be a nice convenience for C and for some interpreters, and would be easy to implement. But in retrospect, given the can of worms it's opened, I'm perfectly willing to go without those instructions. I'd much rather see silicon sooner. So Chip, if you haven't already implemented the WRx instructions please don't and focus on getting the hardware out the door.
While I see the value of having every possible bit boolean instruction, I don't think I've ever had to program like that. Maybe I just solved problems differently, given the constraints I typically had.
Comments
newElev := ((1000 <# Elev ># 2000) + 600 ) / 42 // or whatever form...
changes Elev?
are you sure reading this source?
NO.
In SPIN we can have building functions like min() max(), clamp() perfectly usable in expressions.
And readable and understandable for anybody without consulting the manual again and again.
I guess to use the CORDIC stuff in SPIN2 we will need buildin functions anyways, like sin(), cos(),...
Mike
To me this debate is maddening. So I need to just drop out of it. I've said what I think should be done, and that's that. This is P2, it's not even remotely compatible with P1, so why not fix things that were wrong?
F means "force". Force greater or equal, force less or equal, etc. Do you not like that? I just changed everything to it. I like CLAMP, but it's too long to add LE/GE to, plus an S. Contractions of CLAMP don't look good, at all. I don't love FGE/FLE/FGES/FLES, but they make suitable mnemonics. What do you think?
EDIT: And FORCE is too long, FORCLE looks bad, and FRCLE doesn't look good, either.
This is the new MODCZ instruction that lets you set C and Z to any logical combination of each other, plus 0 and 1:
EEEE 1101011 CZ1 0cccczzzz 001101111 ** MODCZ c,z {WC,WZ} Examples: MODCZ _CLR, _Z_OR_C WC,WZ 'C = 0, Z |= C MODCZ _NZ,0 WC 'C = !Z MODCZ 0,_SET WZ 'Z = 1 --------------- MODCZ constants --------------- _CLR = %0000 _NC_AND_NZ = %0001 _NZ_AND_NC = %0001 _GT = %0001 _NC_AND_Z = %0010 _Z_AND_NC = %0010 _NC = %0011 _GE = %0011 _C_AND_NZ = %0100 _NZ_AND_C = %0100 _NZ = %0101 _NE = %0101 _C_NE_Z = %0110 _Z_NE_C = %0110 _NC_OR_NZ = %0111 _NZ_OR_NC = %0111 _C_AND_Z = %1000 _Z_AND_C = %1000 _C_EQ_Z = %1001 _Z_EQ_C = %1001 _Z = %1010 _E = %1010 _NC_OR_Z = %1011 _Z_OR_NC = %1011 _C = %1100 _LT = %1100 _C_OR_NZ = %1101 _NZ_OR_C = %1101 _C_OR_Z = %1110 _Z_OR_C = %1110 _LE = %1110 _SET = %1111OK with that.
Or is fmax giving the smaller value again???
Clinging to the weird decision that a max limits to the smaller value and a min limits to the bigger one?
plain English:
what is the minimum of 5 and 3?
5!
because its a LIMIT minimum!
just brilliant.
Mike
IF (a<b)
is TRUE when a is greater or equal b, because it is a LIMIT compare!
that can give a whole new meaning to Boolean expressions!
I am with @ROY here, I give up.
Mike
How exactly do you propose to back port that change, to a new version of P1 OpenSpin/Proptool/etc, in a safe way ?
I'm not following Roy's aversion to the F, because you cannot use an existing name for a new operation.
So it is not possible to simply flip MIN and MAX and back port to P1, without breaking legacy code big time.
FGE/FLE/FGES/FLES seem a good compromise, - they have a valid root, and can be safely fitted into P1 flows.
That added a lot of extra power to the P2, but they are now harder to see ?
MIN D,S to get the minimum of D and S, but
FLE D,S to force D to be less or equal S?
at least its not backwards like on the P1
a := 1000 FGE b FLE 2000
is even readable.
Mike
Correct. Even better, it can be added back into P1 tools to also fix those, without breaking any existing code.
Like I said, I removed them. We now have MODCZ which can perform operations between C and Z, but when it comes to operations on bits, we can only read and write them. We can't perform logic operations on them, unless we do something like 'IF_C BITN D,{#]S' - that's an XOR on a bit.
Not Less Than
NTE NLT
Just tossing it out there.
Are you saying you regressed back to the previous build, thus dropping the new Boolean Logic operators ??
... but why ? They worked didn't they ? And you reported had little logic cost.
They certainly added a lot of power to P2, and have the ability to save COG memory, and the P2 is rather COG memory starved.
If you read any PLC documents around IEC 61131, you can see that would have given a solid silicon base, for PLC designs.
The multiple COGs in P2 also make it a natural for safely encapsulating PLC control groups.
I've given examples of where even modern C compilers are able to make good use of such Boolean Logic operators, where they exist.
The result can be fewer jumps in code, which also helps HUBEXC.
I'm seeing a lot of plusses, but not grasping any minus - seems highly retrograde to me & a quite serious mistake ?
They worked. I just couldn't make them presentable. They just didn't feel right, at all. They broke rules and didn't mentally flow.
I don't see 61131 applications caring whether it takes a few pasm instructions to manipulate a bit, given typical scan times.
I'm always slightly amused when people say something comes 'almost for free'. But there's always a cost, and it's usually time and lost opportunity.
What you had was actually very clean and orthogonal, as boolean opcodes go.
The 8051 has boolean opcodes, but a smaller subset than what you had on P2, so P2 would have attracted 8051 users looking to upgrade.
Look at any Ladder Logic diagrams, and you can see whole control systems, done with boolean logic operators.
Embedded control also has many instances where flags are used.
Please do. You may be over-thinking the need to be 'congruous with the rest of the instruction set'
Compilers do not really care what is congruous - they are all binary opcodes!!
I think what we have at the moment, while not having full bit-logic operations, is probably "done".
A pity. These boolean operations looked really useful and they were already there. Representation could have been tweaked later if necessary.
And then there'll be the next very useful feature, and then the next one...
What's already in v18 gives everything needed to implement boolean flags; it's not like there's any missing functionality. The question is solely how many instructions it will take, and we're generally talking about a difference between 1 instruction (if jmg's proposal were implemented) and 1-3 instructions (if not).
The same thing applies to my earlier suggestion of a way to set a register to the value of C or Z. I thought it would be a nice convenience for C and for some interpreters, and would be easy to implement. But in retrospect, given the can of worms it's opened, I'm perfectly willing to go without those instructions. I'd much rather see silicon sooner. So Chip, if you haven't already implemented the WRx instructions please don't and focus on getting the hardware out the door.
Eric
I just realized that we can already do single-instruction boolean operations on register bits:
We can actually do a lot more than that by using more complex if_?'s.
The only thing that is lacking is having results go into C/Z.
Write Result to Flag
That gets a ton of cases covered, and we just use the existing flag bits differently.
Syntax is consistent.
Pnut picks the right opcode, based on "WC, WZ" or "WRZ, WRC"