- Add M68k as new Clang target
- Add new attribute to support M68k's ISR (Interrupt Service Routine)
Looking forward to see m68k support (and hopefully sega genesis toolchain support someday)!
This doesn't seem to match the coding style, clang-format to the rescue.
Can you make all the defineMacro inline within the cases? Clarity seems more useful here.
Can you remove the comment and add the enum back whenever you introduce CK_68060 support?
- Addressed all the feedbacks
- Fixed minor issues that would retrieve the wrong TargetCodeGenInfo instance
currently we don't have any plan for that
stack pointer is aliased to a7, but I'll add pc into the list.
Seems to work after I fixed a minor issue in getting the correct TargetCodeGenInfo. Will remove this comment.
If we're in SysV psABI land, then the stack is 32-bit aligned.
If we're in actual ABI used by everyone out there, i.e. GCC's default, then it's only 16-bit aligned, and your integer types also have the wrong alignment, so you will get ABI incompatibility with GCC-built binaries as provided by distributions like Debian.
GCC's -mcpu excludes any M prefix and is just the number.
Where are these coming from? GCC only defines __m68k__.
- Addressed feedbacks
- Now M68k tries to use ABI that is compatible with GCC
we also support -mcpu with just number via m68k::getM68kTargetCPU
Also I found this page: https://sourceforge.net/p/predef/wiki/Architectures
Yes, and as you can see none of those three are defined by GCC. Defining M68k is particularly bad as it will collide with the C++ namespace used by this very backend so you won't be able to build Clang with Clang on m68k! And the others are just a waste of time. Defining fewer macros is best, that way people don't come to rely on non-standard ones and instead use the single option that exists everywhere (__m68k__).
- Addressed feedback
- Remove redundant target macro definitions
good point :-)