Re: Summary on what's blocking full Rust support on m68k
John Paul Adrian Glaubitz <[email protected]> Mon, 18 May 2026 15:03:24 +0200
| Newsgroups | gmane.os.netbsd.ports.m68k,gmane.linux.debian.ports.68k,gmane.linux.ports.m68k |
|---|---|
| Message-ID | <6efb67b12fd971c6d38a692d7b391ce4a75b0f4a.camel@physik.fu-berlin.de> |
Hi, On Thu, 2026-04-23 at 09:39 +0200, John Paul Adrian Glaubitz wrote: > Once the alignment issue has been sorted out, the next issue to address i= s the lack of the > M68k backend in LLVM to handle 32-bit offsets for variables and jumps [4]= . Currently, the > backend will always generate 16-bit offsets which is not enough to compil= e all Rust code, > although some Rust code compiles also with 16-bit offsets. >=20 > I have created a rough patch to add support for 32-bit offsets with the h= elp of Gemini but > the patch has multiple problems as outlined in the GitHub issue in [4]. O= ne of the problems > is that it creates the 32-bit offsets in an inefficient way as if the tar= get was a ColdFire > CPU. However, the original 680x0 CPUs can actually use more efficient cod= e to address 32-bit > variables and jumps. The inefficient way would still be used when ColdFir= e support gets added > to LLVM though [5]. I have used Google Gemini Code Assist now [1] in order to create a patch to= add support for 32-bit relocations to the LLVM M68k backend. This time, the code makes use of the = full capabilities of 68020+ CPUs and does not the inefficient four-instruction method to impleme= nt 32-bit accesses. I'm hesitant to send this in for review as this was basically written by Ge= mini under my supervision with a lot of testing of build tests. Adrian > [1] https://github.com/llvm/llvm-project/issues/181481#issuecomment-44769= 33700 --=20 .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913