Commit Graph

5 Commits

Author SHA1 Message Date
Min-Yih Hsu f6d7fc801b [M68k][test][NFC] Scrubing some tests
Remove unecessary labels and assembly directives. NFC.
2021-05-05 17:48:28 -07:00
Min-Yih Hsu 5b3dd2a490 [M68k][AsmParser] Fix invalid register name parsing logics
Adjust sanity check in register parsing function to allow register
name with more than 2 characters (e.g. ccr).

Differential Revision: https://reviews.llvm.org/D101733
2021-05-05 17:13:02 -07:00
Min-Yih Hsu abac6023bb [M68k][AsmParser] Support negative integer constants
Parsing negative integer constants as expressions.

Differential Revision: https://reviews.llvm.org/D101732
2021-05-05 17:11:59 -07:00
Min-Yih Hsu 34da083a8c [M68k][test] Initial migration of MC tests
As the context depicted by bug 49865[1], we are migrating tests under
`test/CodeGen/M68k/Encoding`, which was originally used to test
instruction encoding using MIR file as input, into `test/MC/M68k`. We
are also adding test directives for AsmParser using the same set of
inputs.

Currently we are converting the original MIR test files into assembly
code as well as translating the original LIT "RUN" statement into one
that only uses built-in LLVM tools (i.e. Get rid of `extract-section`).

However, since AsmParser has not completely finished, many of these
original test cases fail. Thus, this patch only migrate test files
that are passed by the current implementation of AsmParser (and
MCCodeEmitter). The remaining tests (under test/CodeGen/M68k/Encoding)
will be ported alone with the patch that fixes the related issues.

[1]: https://bugs.llvm.org/show_bug.cgi?id=49865

Differential Revision: https://reviews.llvm.org/D101410
2021-05-05 17:11:35 -07:00
Ricky Taylor 6e098e133d [M68k] Implement AsmParser
This is a work-in-progress implementation of an assembler for M68k.

Outstanding work:
- Updating existing tests assembly syntax
- Writing new tests for the assembler (and disassembler)

I've left those until there's consensus that this approach is okay (I hope that's okay!).

Questions I'm aware of:
- Should this use Motorola or gas syntax? (At the moment it uses Motorola syntax.)
- The disassembler produces a table at runtime for disassembly generated from the code beads. Is this okay? (This is less than ideal but as I mentioned in my llvm-dev post, it's quite complicated to write a table-gen parser for code beads.)

Depends on D98519

Depends on D98532

Depends on D98534

Depends on D98535

Depends on D98536

Differential Revision: https://reviews.llvm.org/D98537
2021-04-13 09:25:34 +01:00