Currently I am not able to test the functionality of this mode, need some help in that.
Also for the time being I have created different function for parsing, we can merge that later, just to make sure SS-a doesnt break, I have not merged this since I was not able to test it.
Let me know your comments on this
I've also changed the template parser so that it can handle suffixes
which are longer than 1 character. The suffix for SS-a instructions
is "SS-a". We could change this again later.
Currently only "maer" is implemented. I am not able to get this working, don't know if I am missing out something, or we need to add some more functionality for RRD.
It would be nice to verify that floating-point/general-purpose
registers are indeed expected by the instruction, but for now treat
them both the same so we can use floating-point instructions.
Currently only afi instruction is encoded, will be adding other instructions too. For encoding we are running out of characters so was planning to append the complete modes (RXa or rxa) which one do you think is better, and also thinking of just adding remaining instruction modes as well, which we don't support as of now. Let me know if you want me to add those, or we will wait for sometime before we add those.
The parse_mem_bx function now returns a function to call to add an
action to the action list to handle the evaluation of the
displacement. This allows us to delay adding said action until
after we have emitted the actions for the instruction encodings
themselves.
Code like this should now work:
int x = 24
| st r1, x(sp)
Most RX instructions don't specify the correct number of operands
so this won't work on many yet. It also won't yet emit an action
if D is a variable rather than a constant.
This means that code like this can now be generated on s390x:
| ar r2, r3
| br r14
Still need to add support for immediates, memory, labels, other
instructions and so on.
This should allow us to encode the instructions relatively naturally
and efficiently. For now I've escaped halfwords with a value <=
the maximum action. This means that 0 is escaped which probably
isn't ideal, so we may want to revisit that decision at some point.
Also sets the action list type to unsigned short (uint16_t) which
I think is the most appropriate type for s390x (x86 uses uint8_t
and other platforms use uint32_t).
I have added the number depending on the number of operands, pls check for the ones which access memory.
Also For base register and displacement, should I assume that it will be passed in the same order as it is expected, since I dont have any means to see the output, I am confused a bit for those add modes.
Since we decided to test RR first, thats in progress, but would like to add others as well.
The extra check for register is currently ignored, and trying to see what value does the encode function return. Its still to be worked out, how this value is used later, after decoding.
