Hi all,
Short version
I get decoding conflicts during generation of disassembler tables for
my modified PowerPC backend:
001100..........................
................................
ADDIC 001100__________________________
E_LBZ 001100__________________________
Which methods can be used to resolve this kind of error?
Long version:
I'm trying to implement support for the PowerPC Variable Length
Encoding (VLE) instruction set. This is an instruction set which
re-encodes many of the normal PPC instructions for improved code
density. There exists both cores which are only able to run VLE
instructions and cores which can run a mix of VLE and non-VLE code.
There exists instructions in the VLE instruction set which have the
same encoding as non-VLE instructions.
In my implementation I'm trying to reuse as much as possible from the
existing PPC backend. My first goal is to target a VLE only core and
my strategy so far has been to mark my VLE instructions with a
predicate to require VLE support from the sub target.
Example:
def HasVLE : Predicate<"PPCSubTarget->hasVLE()">,
AssemblerPredicate<"FeatureVLE", "VLE Instruction
set">;
let Predicates = [HasVLE] in {
If I have understood this correct the predicate will work for CodeGen
and the assembler but not for the disassembler. This has worked for
the instructions added up until now when I added an instruction whose
encoding conflicts with a non-VLE instruction and I receive an error
during generation of disassembler tables.
My question is how to resolve this decoding conflict?
One option I considered would be to remove all non-VLE instructions
but I would like to avoid that. Another option would perhaps be to set
a custom DecoderMethod but if possible I would rather do this in
TableGen.
Any pointers for how to proceed with this is appreciated.
- David
David,
If the VLE instructions overlap with the regular ones, you'll want to put
into into a different decoder namespace. You can put:
let DecoderNamespace = "VLE" in {
...
}
around the relevant definitions and that should take care of the decoding
conflicts.
Then, in the disassembler, you'll want something like:
if ((STI.getFeatureBits() & PPC::FeatureVLE) != 0) {
DecodeStatus result decodeInstruction(DecoderTableVLE32, MI, Inst,
Address, this, STI);
if (result != MCDisassembler::Fail)
return result;
MI.clear();
}
before
return decodeInstruction(DecoderTable32, MI, Inst, Address, this, STI);
(but I suppose they're not all 32-bits, so I presume it will be more
complicated ;) )
-Hal
----- Original Message -----> From: "David Wiberg" <dwiberg at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Wednesday, July 9, 2014 2:49:55 PM
> Subject: [LLVMdev] How to resolve decoding conflict?
>
> Hi all,
>
> Short version
> I get decoding conflicts during generation of disassembler tables for
> my modified PowerPC backend:
> 001100..........................
> ................................
> ADDIC 001100__________________________
> E_LBZ 001100__________________________
>
> Which methods can be used to resolve this kind of error?
>
> Long version:
> I'm trying to implement support for the PowerPC Variable Length
> Encoding (VLE) instruction set. This is an instruction set which
> re-encodes many of the normal PPC instructions for improved code
> density. There exists both cores which are only able to run VLE
> instructions and cores which can run a mix of VLE and non-VLE code.
> There exists instructions in the VLE instruction set which have the
> same encoding as non-VLE instructions.
>
> In my implementation I'm trying to reuse as much as possible from the
> existing PPC backend. My first goal is to target a VLE only core and
> my strategy so far has been to mark my VLE instructions with a
> predicate to require VLE support from the sub target.
>
> Example:
> def HasVLE : Predicate<"PPCSubTarget->hasVLE()">,
> AssemblerPredicate<"FeatureVLE", "VLE Instruction
set">;
>
> let Predicates = [HasVLE] in {
>
> If I have understood this correct the predicate will work for CodeGen
> and the assembler but not for the disassembler. This has worked for
> the instructions added up until now when I added an instruction whose
> encoding conflicts with a non-VLE instruction and I receive an error
> during generation of disassembler tables.
>
> My question is how to resolve this decoding conflict?
> One option I considered would be to remove all non-VLE instructions
> but I would like to avoid that. Another option would perhaps be to
> set
> a custom DecoderMethod but if possible I would rather do this in
> TableGen.
>
> Any pointers for how to proceed with this is appreciated.
>
> - David
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
2014-07-09 22:07 GMT+02:00 Hal Finkel <hfinkel at anl.gov>:> David, > > If the VLE instructions overlap with the regular ones, you'll want to put into into a different decoder namespace. You can put: > > let DecoderNamespace = "VLE" in { > > ... > > } > > around the relevant definitions and that should take care of the decoding conflicts. > > Then, in the disassembler, you'll want something like: > > if ((STI.getFeatureBits() & PPC::FeatureVLE) != 0) { > DecodeStatus result > decodeInstruction(DecoderTableVLE32, MI, Inst, Address, this, STI); > if (result != MCDisassembler::Fail) > return result; > > MI.clear(); > } > > before > > return decodeInstruction(DecoderTable32, MI, Inst, Address, this, STI); > > (but I suppose they're not all 32-bits, so I presume it will be more complicated ;) ) > > -Hal >Hi Hal, Thank you, this seems like a good idea which I will try. - David> ----- Original Message ----- >> From: "David Wiberg" <dwiberg at gmail.com> >> To: llvmdev at cs.uiuc.edu >> Sent: Wednesday, July 9, 2014 2:49:55 PM >> Subject: [LLVMdev] How to resolve decoding conflict? >> >> Hi all, >> >> Short version >> I get decoding conflicts during generation of disassembler tables for >> my modified PowerPC backend: >> 001100.......................... >> ................................ >> ADDIC 001100__________________________ >> E_LBZ 001100__________________________ >> >> Which methods can be used to resolve this kind of error? >> >> Long version: >> I'm trying to implement support for the PowerPC Variable Length >> Encoding (VLE) instruction set. This is an instruction set which >> re-encodes many of the normal PPC instructions for improved code >> density. There exists both cores which are only able to run VLE >> instructions and cores which can run a mix of VLE and non-VLE code. >> There exists instructions in the VLE instruction set which have the >> same encoding as non-VLE instructions. >> >> In my implementation I'm trying to reuse as much as possible from the >> existing PPC backend. My first goal is to target a VLE only core and >> my strategy so far has been to mark my VLE instructions with a >> predicate to require VLE support from the sub target. >> >> Example: >> def HasVLE : Predicate<"PPCSubTarget->hasVLE()">, >> AssemblerPredicate<"FeatureVLE", "VLE Instruction set">; >> >> let Predicates = [HasVLE] in { >> >> If I have understood this correct the predicate will work for CodeGen >> and the assembler but not for the disassembler. This has worked for >> the instructions added up until now when I added an instruction whose >> encoding conflicts with a non-VLE instruction and I receive an error >> during generation of disassembler tables. >> >> My question is how to resolve this decoding conflict? >> One option I considered would be to remove all non-VLE instructions >> but I would like to avoid that. Another option would perhaps be to >> set >> a custom DecoderMethod but if possible I would rather do this in >> TableGen. >> >> Any pointers for how to proceed with this is appreciated. >> >> - David >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory