Added comments to fwd_jmp
added test for RRD based test case add_rrd()---> functionality to be tested
added test for RR based test case load_test()--> test fails
These are labels which are given a numeric value. For example, the
following code would generate PC labels 0 to 4:
for (int i = 0; i < 5; i++) {
|=>i:
}
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.
A style thing. I find it easier to read this way.
i.e. do:
while(1) {
if (blah) {
...
continue;
}
... // big switch statement
}
instead of:
while(1) {
if (blah) {
...
} else {
... // big switch statement
}
}
I did this mostly to get rid of the annoying tabs/spaces mix in this
file. It has the side effect of forcing newlines before statements
which I think is a better style (and not particularly inconsistent
with the original which used both styles). Other than that I've tried
to match the original style as closely as possible.
Generated with this command:
indent -i2 -brs -cli0 -br -ce -npcs -nbc -di1 -npsl -ncs dasm_s390x.h
The masking in immediate mode might not be proper. I could understand that you had masked 12bits and then 8bits to get the displacement in place for 20-bit displacement ( cp[-2] |= n&0xfff; cp[-1] |= (n>>4)&0xff00;) But in my case I need all the 32bits, so not sure how to go about it. Currently I have just used "n" since no point in "and with 0xffff" But I am getting core dump. Please Let me know your comments on these.
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.
