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.
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.
added definations to macros to test operand type refeered x86 definations
no JUMP instruction found for s390x used BRANCH RELATIVE on CONDITION instead (brc)
Not sure how the condition will be checked , need to discuss this
added instructions to macros, referring macro defination of x86
for macro ins_ANDdid not find equivalent s390x replacement instruction for 'Not' hence have currently marked the place as '????'
'????' has to be replaced with s390x complement instruction
f8-f15 are callee-saved (not f0,f2,f4 and f6). There isn't space
for them in the caller's stack frame so we need to increase the
size of the interpreter's stack frame.
I believe these macros obey the C calling convention, so we need to
allocate our stack frame and save all callee-save registers. We
can tune it later if it turns out we don't need all the registers.
