sleigh: operands in with block bit pattern cause duplicate symbol error

[shuffle2]

Describe the bug

I'm trying to write a processor extension. My slaspec contains the following:

define token instr32(32)
    isa         = (31,31)
    opc         = (25,30)
    subop       = (0,4)

    u24_24  = (24,24)
    u20_24  = (20,24)
    u15_24  = (15,24)
    u20_23  = (20,23)
    u16_19  = (16,19)
    u15_19  = (15,19)
    u5_19   =  (5,19)
    u14_14  = (14,14)
    u11_14  = (11,14)
    u10_14  = (10,14)
    u10_10  = (10,10)
    u0_14   =  (0,14)
    s0_23   =  (0,23) signed
    s0_15   =  (0,15) signed
    s0_14   =  (0,14) signed
    s0_13   =  (0,13) signed
    u8_9    =   (8,9)
    u5_9    =   (5,9)
    u6_7    =   (6,7)
    u0_7    =   (0,7)
    u5_7    =   (5,7)
    u5_5    =   (5,5)
;

with : isa=0 {
    with : u20_24 & u15_19 & u10_14 & u5_9=0 {
        with : opc=0b100000 {
            :ADD u20_24, u15_19, u10_14 is subop=0b00000 { u20_24 = u15_19 + u10_14; }
            :AND u20_24, u15_19, u10_14 is subop=0b00010 { u20_24 = u15_19 & u10_14; }
        }
    }

I receive errors like the following:

ERROR .slaspec:100: Duplicate symbol name: u20_24 (previously defined at .slaspec:61) (SleighCompile)  
ERROR .slaspec:100: Duplicate symbol name: u15_19 (previously defined at .slaspec:65) (SleighCompile)  
ERROR .slaspec:100: Duplicate symbol name: u10_14 (previously defined at .slaspec:69) (SleighCompile)  

Expected behavior From the documentation, I would expect this to work (the with blocks prefixing patterns to the patterns defined by the nested constructors). Is there some trick to get it to work? Is it supposed to work like that?

Looking at the documentation a bit closer, it seems like a constraint without a comparison is considered a definition as opposed to a pattern, and suspiciously the example in the with section does not show definition syntax being used. However, I don't really understand why this shouldn't be allowed / why it doesn't work - it seems useful and would unify the behavior.

Environment (please complete the following information):

• OS: Microsoft Windows [Version 10.0.22621.819]
• Java Version: jdk-17.0.4+8
• Ghidra Version: 5ebbf0b2689eed7ce2faf9988ef70bb57822478c
• Ghidra Origin: locally built

[mumbel]

Just a guess that it's not liking the tokens without a =RHS, since they're operands in the bit pattern, not constraints.

The with description has this sentence: The listed constraints take the form described in Section 7.4, “The Bit Pattern Section”

Which states: The patterns required for processor specifications can almost always be described as a mask and value pair.

[shuffle2]

I've updated the title to be more accurate about the terminology. I still think this would be a nice feature to have, although I've since worked around it and it's only a minor inconvenience.

[ghidra1]

Although the pcode is invalid I have been able to reproduce. I will have to defer back to @caheckman for his insight on this.

[caheckman]

Yes, your observation is correct. The "with" clause in SLEIGH can currently only take constraints like "isa=0" not the unadorned symbols like "u20_24 & u15_19" in the example. We will consider this a new feature request.