AARCH64 - armv8.(3|4|5)a instructions

[blacktop]

pulled from - https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/AArch64InstrInfo.td#L605

This isn't done yet, but it's a start 😉

[aquynh]

cool, but yes this is just a start, as all the actual supported code is not here yet.

[blacktop]

@aquynh by "all the actual supported code" do you mean the rest of the ARMv8.x instructions or is there more capstone specific code I need to change?

I am asking because I am a little unclear as to what all I need to include to get upgraded ARMv8 support?

I am however, committed to working with you to take this PR to completion.

Thanks for any future help/assistance.

[aquynh]

you can look at the code under https://github.com/aquynh/capstone/tree/master/arch/AArch64, the core is there.

[blacktop]

@aquynh is the other PR with ARMv8.(1|2) okay? Meaning did they change all the appropriate files?

[E3V3A]

@aquynh
I think your comments are a bit too lacking to provide the PR dude the info he/she need to fix whatever it is you want him to fix. I would love to see some more progress on the ARM stuff here, and everything people post about it, it just seem to get lost in time...

IMO and as observed, people are trying hard to help you getting this project on track but you're not being very helpful.

[blacktop]

@aquynh in trying to understand why supporting/core files need to be changed I thought I would try and see what is involved in something like "branch"

arch/AArch64/AArch64Mapping.c

	{ ARM64_INS_B, "b" },

arch/AArch64/AArch64MappingInsn.inc

{
	AArch64_BL, ARM64_INS_BL,
#ifndef CAPSTONE_DIET
	{ 0 }, { ARM64_REG_LR, 0 }, { ARM64_GRP_JUMP, ARM64_GRP_BRANCH_RELATIVE, 0 }, 1, 0
#endif
},

arch/AArch64/AArch64MappingInsnOp.inc

{    /* AArch64_BL, ARM64_INS_BL: bl    $addr */
	0,
	{ CS_AC_READ, 0 }
},

are these inc files like an intermediate representation?

I would have assumed you would need a opcode to bits mapping? or maybe that is what arch/AArch64/AArch64GenInstrInfo.inc is?

Are you running llvm to get the bytes that make up the opcodes?

[blacktop]

@aquynh are there any talks/presentations where you describe how the core works and/or how one adds new instructions/archs ?

[blacktop]

So after reading your docs PDF and links and running:

$ llvm-tblgen AArch64.td -dump-json -class=Instruction -I=/Users/blacktop/Projects/github/llvm/include | jq '.RETAB'

{
    "RETAB": {
        "!anonymous": false,
        "!fields": [
            "Inst",
            "Unpredictable",
            "SoftFail"
        ],
        "!name": "RETAB",
        "!superclasses": [
            "Instruction",
            "AArch64Inst",
            "EncodedI",
            "I",
            "Sched",
            "AuthBase",
            "AuthReturn"
        ],
        "AddedComplexity": 0,
        "AsmMatchConverter": "",
        "AsmString": "retab",
        "AsmVariantName": "",
        "CodeSize": 0,
        "Constraints": "",
        "DecoderMethod": "",
        "DecoderNamespace": "",
        "Defs": [],
        "DestructiveInstType": {
            "def": "NotDestructive",
            "kind": "def",
            "printable": "NotDestructive"
        },
        "DisableEncoding": "",
        "ElementSize": {
            "def": "ElementSizeB",
            "kind": "def",
            "printable": "ElementSizeB"
        },
        "F": {
            "def": "NormalFrm",
            "kind": "def",
            "printable": "NormalFrm"
        },
        "FastISelShouldIgnore": 0,
        "Form": [
            1,
            0
        ],
        "InOperandList": {
            "args": [],
            "kind": "dag",
            "operator": {
                "def": "ins",
                "kind": "def",
                "printable": "ins"
            },
            "printable": "(ins)"
        },
<SNIP>

and

$ echo "0x20,0x04,0xc1,0xda" | llvm-mc -disassemble -arch=arm64 -mattr=v8.4a
	.section	__TEXT,__text,regular,pure_instructions
	pacib	x0, x1

It seems like we could just use TableGen to get the new instructions etc from llvm in an automated way?

[blacktop]

@aquynh do the instructions have to added to your arch/AArch64/AArch64Mapping.c file in the same order them come out of llvm-tblgen in order for it to work since the:

/// ARM64 instruction
typedef enum arm64_insn {

is an enum?

[XVilka]

@blacktop see this PR on how to generate these files using patches for TableGen #1230

[XVilka]

@blacktop @E3V3A these patches can be generalized for most of the architectures in fact.

[XVilka]

@blacktop you might want to check the updated version of previously mentioned PR with TableGen patches #1305

[blacktop]

@XVilka thank you! I'll take a look

[XVilka]

@blacktop I think it is better to use rebase, so history wouldn't be polluted.

[blacktop]

@XVilka yeah, I messed up the history by trying a rebase before the merge from master, but this way the "Files Changed" is easier to see because it only has mine and not the others (from master) since I opened this PR

[aquynh]

very nice, this is inline with our plan at #1319.

which llvm version are you based on? could you rebase your work on llvm 7.0.1, so we are on the same page?

[aquynh]

currently Travis fails to build, can you take a look?

[blacktop]

@aquynh I have created another PR here #1343

[XVilka]

@blacktop so I think this one can be closed, right?