[llvm-dev] [M68k] CCR usage / instruction encoding

[Min-Yih Hsu via llvm-dev]

Hi Ricky,

On Fri, Aug 27, 2021 at 5:15 AM Ricky Taylor <rickytaylor26 at gmail.com>
wrote:

> Hi,
>
> I've been angling at migrating changes from my proof-of-concept Mega Drive
> fork
> back into mainline LLVM. There are a fair few smaller pieces (a few extra
> instruction implementations, some minor bug fixes) but the fork itself
> made some
> large changes in order to get a working demo on the hardware proper.
>
> Additionally, as it was part of a proof-of-concept (and I lack experience
> working on the LLVM backend), a lot of the original implementation is not
> going
> to have been implemented in the best way.
>
> I'm hesitant to try and migrate any of the smaller changes before some of
> the
> larger questions are answered because it might result in redundant work.
>
> The two biggest areas of concern I have are:
>
> - CCR usage
>   - At the moment, the M68k target doesn't actually support the 68000,
> because
>     it relies on saving the CCR which wasn't introduced until the 68010.
>     (You can save the SR, which includes the CCR, but that is a privileged
>     instruction.)
>   - In my PoC for the Mega Drive, I disabled allocation of the CCR and had
> the
>     code generate CCR in the immediately preceding instruction - this was
>     flaky because sometimes the instructions got split
>

I haven't looked into this problem TBH.


>
> - Instruction encoding
>   - This is the point of discussion of PR48792: Review options between
> using
>     CodeBeads v.s. TSFlags (https://bugs.llvm.org/show_bug.cgi?id=48792)
>   - The code-beads implementation is particularly painful for disassembly,
>     even the landed disassembler feels messy
>   - There is an instruction definition per set of operand permutations in
>     the M68k backend, which makes manipulating the instructions in the
>     backend outside of codegen quite difficult
>   - I wrote up some thoughts in a previous message:
>     https://lists.llvm.org/pipermail/llvm-dev/2021-February/148408.html
>
>
Sorry I missed your previous message on the mailing list. In addition to
the TSFlags solution recently I've been studying if the tablegen-ed
MCCodeEmitter (i.e. the `-gen-emitter` TG backend) can help on this
problem. Though it's mostly used by ISA that has (sorta) fixed-size
instructions, the fact is that it never puts any limitation on the size of
instructions as well as asking to have uniform size across all
instructions. What's more, despite the fact that M68k has variable-length
instructions, it has more regular sizes since it's always multiple of
words (16 bits) and more importantly, as you also mentioned in your
February post, in most cases we can determine the address mode of an
instruction operand by only looking at the first word. In other words, even
if we can't carry every encoding info using the aforementioned tablegen
solution or TSFlags, we can at least use them to specify the encoding of
the first word.

Regarding the permutation problem...I also feel the pain in terms of
maintenance, but I can't really find any other solution based on the
current tablegen design. To be fair, most of these permutations have been
factored out using multiclass or class. Which, IMAO, is still readable for
now. One really bold idea will be addressing this problem from the tablegen
language itself by adding some sort of multidimensional table that, for
instance, has two-dimension columns (corresponding to the source and
destination operands' addressing mode) and puts data (the complete
instruction definition) in the third dimension.


> I'm happy to put some effort into either of these problems, though I could
> definitely benefit from some guidance.
>
> I'm not entirely sure what the process is from here. Prepare an RFC
> for any major changes and start landing incrementally once they achieve
> some kind of consensus?
>
> Thanks,
> Ricky Taylor
>


-- 
Min-Yih Hsu
Ph.D Student in ICS Department, University of California, Irvine (UCI).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210829/e38c4960/attachment.html>