Shop OBEX P1 Docs P2 Docs Learn Events
SFUNC question - Page 8 — Parallax Forums

SFUNC question

1568101113

Comments

  • msrobotsmsrobots Posts: 3,709
    edited 2017-05-04 07:11
    Even worse, does

    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



  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2017-05-04 07:28
    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?
  • jmgjmg Posts: 15,163
    cgracey wrote: »
    I don't think we can suddenly make MIN into MAX and vice-versa. The connotations, apparently, conflict too much with Prop1 precedent.

    I think FGE/FLE names will have to do.
    I think so, at least those can retrofit into P1 OK, to then bring P1 & P2 more into phase.

  • cgraceycgracey Posts: 14,134
    edited 2017-05-04 08:48
    Roy Eltham wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,069
    What about LIM for LIMIT ?
  • cgraceycgracey Posts: 14,134
    edited 2017-05-04 09:01
    Okay. Here are the latest instructions.

    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                    =       %1111
    
  • fmax is then doing what max does in other languages, but having an f in front reminds you that it is not the same as in PASM1, but the opposite.

    OK 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

  • How about changing the meaning of < and > too?

    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
  • jmgjmg Posts: 15,163
    Roy Eltham wrote: »
    Except everyone pretty much agrees that P1 PASM MIN/MAX is backwards.
    Yes, agreed,
    Roy Eltham wrote: »
    This is P2, it's not even remotely compatible with P1, so why not fix things that were wrong?
    Also a good idea.
    Roy Eltham wrote: »
    We can change them on p1 too with a new version of OpenSpin/Proptool/etc.
    Yes, that is possible, but you seem to be suggesting a Flip of the meaning of MAX & MIN as the fix ?

    How exactly do you propose to back port that change, to a new version of P1 OpenSpin/Proptool/etc, in a safe way ?
  • jmgjmg Posts: 15,163
    edited 2017-05-04 09:18
    cgracey wrote: »
    Roy Eltham wrote: »
    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.
  • jmgjmg Posts: 15,163
    edited 2017-05-04 09:35
    cgracey wrote: »
    Okay. Here are the latest instructions.
    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 ?

  • msrobotsmsrobots Posts: 3,709
    edited 2017-05-04 09:37
    so to get the smaller of two values it is not

    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
  • jmgjmg Posts: 15,163
    msrobots wrote: »
    so to get the smaller of two values it is not

    MIN D,S to get the minimum of D and S, but
    FLE D,S to force D to be less or equal S?

    Correct.
    msrobots wrote: »
    at least its not backwards like on the P1
    Even better, it can be added back into P1 tools to also fix those, without breaking any existing code.

  • cgraceycgracey Posts: 14,134
    edited 2017-05-04 09:37
    jmg wrote: »
    cgracey wrote: »
    Okay. Here are the latest instructions.
    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.
  • Not To Exceed

    Not Less Than

    NTE NLT

    Just tossing it out there.



  • jmgjmg Posts: 15,163
    cgracey wrote: »
    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 ?
  • cgraceycgracey Posts: 14,134
    jmg wrote: »
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,134
    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.
  • 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.
  • jmgjmg Posts: 15,163
    edited 2017-05-04 10:24
    cgracey wrote: »
    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.
    cgracey wrote: »
    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!!

  • cgraceycgracey Posts: 14,134
    Tubular wrote: »
    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".
  • 'tis
  • cgracey wrote: »
    Tubular wrote: »
    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.
  • JRetSapDoogJRetSapDoog Posts: 954
    edited 2017-05-04 14:30
    AJL wrote: »
    A pity. These boolean operations looked really useful and they were already there.
    jmg wrote: »
    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)
  • T ChapT Chap Posts: 4,223
    edited 2017-05-04 14:46
    If it is very useful what is one more day at this point.
  • jmg wrote: »
    cgracey wrote: »
    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.

    I'm with JMG on this one.
    Please bring them back and tweak if needed.
  • T Chap wrote: »
    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.

    Eric
  • cgraceycgracey Posts: 14,134
    edited 2017-05-04 18:20
    The WRx instructions are there.

    I just realized that we can already do single-instruction boolean operations on register bits:
    if_nc   bitl    d,s     'and
    if_c    bith    d,s     'or
    if_c    bitn    d,s     'xor
    

    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.


  • cgraceycgracey Posts: 14,134
    edited 2017-05-04 18:16
    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.
  • potatoheadpotatohead Posts: 10,261
    edited 2017-05-04 18:35
    Add WRC and WRZ to a second set of these?

    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"

Sign In or Register to comment.