Various questions about SLEIGH constructors and debugging them

[Zinfidel]

I'm trying to implement some pseudo-instructions for MIPS mostly just for my own edification, and have run into a number of issues I'd love to have some clarity on. Answers to any given question will be greatly appreciated!

1. Is it possible for one token in a concatenated, variable-length instruction, to "back reference" an operand defined in a previous token for the purpose of using it as a constraint?

Say I want to implement this pseudo-instruction:

#la      rt,      imm32        ;load address   (alias for lui rt / addiu rt)

lui,     rt,      imm16
addiu,   rt, rt,  simm16       # rs == rt here

The pseudo-instruction should match so long as rt is the same register in all three places. I tried (very hard) to implement this pseudo-instruction like this:

:la rt, addr is prime=0xF & rs=0   & rt     & immed
              ; prime=9   & rt=rs1 & rt=rt1 & simmed
                [addr = //etc] {}

where rs1/rt1 are duplicate field definitions for rs/rt. I have also tried the above using the alias RT defined in mips.sinc which is just rt, exported. Nothing I have tried has worked and either the pattern will not compile, complaining about redefining operands, or it compiles but the pattern always matches regardless of the requirement that rt be the same for both tokens, because the value of rt is drawn from the second token instead of the first.

2. Is it possible to set context state in an instruction such that it affects the parsing of concatenated tokens in that very same instruction?

This is related to the above example, and is the second angle of attack I tried. I figured I would set local context in the first token that I could use in subsequent tokens for matching:

define register offset=0x4F00 size=4   pseudocontext;
define context pseudocontext
    REG=(16,20)
;

RX: rt is rt [REG=rt;] { export rt; }

:la RX, addr is prime=0xF & rs=0    & RX      & immed
              ; prime=9   & REG=rt1 & REG=rs1 & simmed
                [addr = //etc] {}

This did not work and the context value was always unset when parsing the second token. I tried to set the context value globally even with instr_start but that did not work either. Is the above possible?

3. Could I somehow use the ... operator to implement the above example?

Ultimately I moved past this problem by defining a new 64-bit token with matching fields in the upper and lower parts, so that I could define the pseudo-instruction in a single line. I tried to understand the ellipses operator and every time I read the manual it seemed like it might be relevant to my problem, but I could never even get the pattern to compile if I threw an ellipses in there.

4. Why does this constructor fail to ever match an instruction?

I have a pseudo-instruction I can match where I know every bit of the token. Despite this, my constructor never matches any instructions. Here it is:

:kernel "A0" is prime=9 & rs=0 & rt=t2 & simmed=0xa0  # t2 = register

This is a special case of :li RT, simmed, which is itself a special case of :addiu RT32, RS32src, simmed, defined in mips32Instructions.sinc. My constructor is defined before these constructors in an included file.

I used the debugger script to find out what was going on and got this:

check pattern[1 of 3]: {line# 133} kernel A0
   byte pattern: mask=11111111.11111111.11111111.11111111
           bytes[0-3]=10100000.00000000.00001010.00100100
          match-value=10100000.00000000.00000000.00100100 Failed

It looks like the rt=t2 part is getting masked out in match-value, as it is for the other two constructors, causing my constructor to fail. Why is this happening here? I have no operands defined for this constructor but rt is being masked out as if it were.

5. What is the purpose/intent of the RS/RT/etc aliases in the mips.sinc file?

They look like this:

RS: rs is rs { export rs; }

There are multiple duplicate fields for rs already defined in the instruction token, so I don't think it's needed for that purpose. Any insight here? Most/all instructions are matched using these aliases for RS/RT/etc in the MIPS files.

6. What is the purpose of sext() in the implementation of lui in mips32Instructions.sinc?

:lui RT, immed                  is $(AMODE) & REL6=0 & prime=0xF & rs=0 & RT & immed {
    tmp:4 = immed << 16;
    RT = sext(tmp); 
}

There is only one register size - 32 bits. immed is a 16-bit field. When immed is placed in the upper half of the word like this, what purpose could sext() or zext() serve here? Wouldn't sext/zext only make sense here if the field was being shifted less than 16 bits?

7. How do sext()/zext() "know" how many 0s/1s to pad a value with?

{ tmp:4 = sext(simmed + 0x20) } // simmed = signed 16-bit field

Do they always pad to some specific sized based on sleigh definition information? Is it contextually understood through the assignment to a 4-byte variable? Would I need to specify simmed:2 to ensure this would work?

8. How does the "signed" attribute for a field interact with sext()/zext()?

In the above example, since simmed is already defined as being signed, do I need to even specify sext() sign extension for it? Does the signed attribute affect parsing here in some other way, or is it just for convenience?

[GhidorahRex]

I'm trying to implement some pseudo-instructions for MIPS mostly just for my own edification, and have run into a number of issues I'd love to have some clarity on. Answers to any given question will be greatly appreciated!

1. Is it possible for one token in a concatenated, variable-length instruction, to "back reference" an operand defined in a previous token for the purpose of using it as a constraint?

Say I want to implement this pseudo-instruction:

#la      rt,      imm32        ;load address   (alias for lui rt / addiu rt)

lui,     rt,      imm16
addiu,   rt, rt,  simm16       # rs == rt here

The pseudo-instruction should match so long as rt is the same register in all three places. I tried (very hard) to implement this pseudo-instruction like this:

:la rt, addr is prime=0xF & rs=0   & rt     & immed
              ; prime=9   & rt=rs1 & rt=rt1 & simmed
                [addr = //etc] {}

where rs1/rt1 are duplicate field definitions for rs/rt. I have also tried the above using the alias RT defined in mips.sinc which is just rt, exported. Nothing I have tried has worked and either the pattern will not compile, complaining about redefining operands, or it compiles but the pattern always matches regardless of the requirement that rt be the same for both tokens, because the value of rt is drawn from the second token instead of the first.

Yes, this is possible. The easiest way is to create a single 64-bit token with the corresponding fields:

define token instr2(64)
	prime64        = (26,31)
        prime64_2       = (58,63)
...
;

2. Is it possible to set context state in an instruction such that it affects the parsing of concatenated tokens in that very same instruction?

This is related to the above example, and is the second angle of attack I tried. I figured I would set local context in the first token that I could use in subsequent tokens for matching:

define register offset=0x4F00 size=4   pseudocontext;
define context pseudocontext
    REG=(16,20)
;

RX: rt is rt [REG=rt;] { export rt; }

:la RX, addr is prime=0xF & rs=0    & RX      & immed
              ; prime=9   & REG=rt1 & REG=rs1 & simmed
                [addr = //etc] {}

This did not work and the context value was always unset when parsing the second token. I tried to set the context value globally even with instr_start but that did not work either. Is the above possible?

No, not that I am aware of. Maybe with a :^instruction constructor.

3. Could I somehow use the ... operator to implement the above example?

Ultimately I moved past this problem by defining a new 64-bit token with matching fields in the upper and lower parts, so that I could define the pseudo-instruction in a single line. I tried to understand the ellipses operator and every time I read the manual it seemed like it might be relevant to my problem, but I could never even get the pattern to compile if I threw an ellipses in there.

No, that's for combining subconstructors of potentially varying size.

4. Why does this constructor fail to ever match an instruction?

I have a pseudo-instruction I can match where I know every bit of the token. Despite this, my constructor never matches any instructions. Here it is:

:kernel "A0" is prime=9 & rs=0 & rt=t2 & simmed=0xa0  # t2 = register

This is a special case of :li RT, simmed, which is itself a special case of :addiu RT32, RS32src, simmed, defined in mips32Instructions.sinc. My constructor is defined before these constructors in an included file.

I used the debugger script to find out what was going on and got this:

check pattern[1 of 3]: {line# 133} kernel A0
   byte pattern: mask=11111111.11111111.11111111.11111111
           bytes[0-3]=10100000.00000000.00001010.00100100
          match-value=10100000.00000000.00000000.00100100 Failed

It looks like the rt=t2 part is getting masked out in match-value, as it is for the other two constructors, causing my constructor to fail. Why is this happening here? I have no operands defined for this constructor but rt is being masked out as if it were.

Rather than use t2, use 0xa

5. What is the purpose/intent of the RS/RT/etc aliases in the mips.sinc file?

They look like this:

RS: rs is rs { export rs; }

There are multiple duplicate fields for rs already defined in the instruction token, so I don't think it's needed for that purpose. Any insight here? Most/all instructions are matched using these aliases for RS/RT/etc in the MIPS files.

RS is redundant, but included there because of RSsrc which is used to allow the zero register to always return 0. Same for the others.

6. What is the purpose of sext() in the implementation of lui in mips32Instructions.sinc?

:lui RT, immed                  is $(AMODE) & REL6=0 & prime=0xF & rs=0 & RT & immed {
    tmp:4 = immed << 16;
    RT = sext(tmp); 
}

There is only one register size - 32 bits. immed is a 16-bit field. When immed is placed in the upper half of the word like this, what purpose could sext() or zext() serve here? Wouldn't sext/zext only make sense here if the field was being shifted less than 16 bits?

In mips64 the registers in RT are 64-bit, not 32-bit. So the sign-extension is there on purpose.

7. How do sext()/zext() "know" how many 0s/1s to pad a value with?

{ tmp:4 = sext(simmed + 0x20) } // simmed = signed 16-bit field

Do they always pad to some specific sized based on sleigh definition information? Is it contextually understood through the assignment to a 4-byte variable? Would I need to specify simmed:2 to ensure this would work?

sext and zext are based on the size of the left-hand size. I believe the sleigh will complain about not knowing how big to make simmed in your example - you can either specify a size or assign it to a temp variable.

8. How does the "signed" attribute for a field interact with sext()/zext()?

In the above example, since simmed is already defined as being signed, do I need to even specify sext() sign extension for it? Does the signed attribute affect parsing here in some other way, or is it just for convenience?

If you've defined your field as signed, you can resize it safely. For instance tmp:4 = simmed; would sign-extend the signed immediate to be 32-bits. It also has a minor effect on the size of the display operand. This came up in the m68000 module recently.

[Zinfidel]

Thank you very much for answering everything in one go, @GhidorahRex ! I am able to get past some stumbling blocks and move on now thanks to your answers. I have a follow-up if you (or someone) have the patience:

For 4, do you have any insight on this behavior? My guess is that there is some assumption in the SLEIGH processor that dictates that if a register is ever named then it's always an operand, regardless of the rest of the constructor, but that's just speculation. I am also assuming that operands are what cause the pattern masking behavior that I saw.

[GhidorahRex]

I believe if the field is used in the display section it counts as an operand, no matter what. Doesn't matter if it's attached to a register or not. And that's probably what caused your pattern masking behavior, but I can't be 100% certain about that.

[Zinfidel]

Unfortunately I don't think that's it, as the constructor in question does not use the field in the display section. The display section is just a mnemonic and a single string literal; no fields are used at all. I'll note that the example has the string "A0" which happens to match the hex value of one of the fields, but that field isn't the one that gets masked out.