similar to: [RFC] Backend for Motorola 6800 series CPU (M68k)

Its awesome to see so much progress on this! A very minor question - why is it called M680x0 and not M68K given that's what the target arch/triple is and how its usually referred to? Sorry for the bikeshedding.... Simon. On 30/09/2020 21:14, Min-Yih Hsu via llvm-dev wrote: > Hi All, > > I've composed a draft roadmap for this new target. I've decided to try >

Hello! Almost two years ago, Artyom Goncharov submitted an initial effort for a backend for the Motorola 68000 architecture [1] which was eventually not merged, unfortunately. I elaborated why I supported the idea of such a backend [2]. Recently, we started a fundraising campaign on the platform Bountysource.com to port the M68K backend in GCC to the new MODE_CC register representation which was

On Sun, 27 Sep 2020 at 20:27, John Paul Adrian Glaubitz via llvm-dev < llvm-dev at lists.llvm.org> wrote: > As many of these classic systems still have very active communities, > especially the Amiga community, > development efforts are still very strong. For example, despite being the > oldest port of the Linux > kernel, the m68k port has still multiple active kernel

Hi All, Just a quick update on the Motorola 6800 backend: Based on the feedback, "M68k" (with lowercase "k") will now be the canonical target name and "m68k" be the target triple name. I've updated all the patches under review to reflect this change. I'm also asking for everyone's help to review all the patches. /* Target independent changes */ 1.

On Tue, 29 Sep 2020 at 18:53, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > So, shall we setup a server for that or is there some existing > infrastructure > from LLVM that is used in this case? > Unfortunately, we don't have a centralised infrastructure like GCC. Each target community is responsible for maintaining their own buildbots. All we

On Sun, Nov 15, 2020 at 1:27 PM John Paul Adrian Glaubitz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 11/15/20 9:33 PM, Simon Pilgrim via llvm-dev wrote: > > As well as the actual patch reviews, has there been official approval that the > > M68k experimental backend can be added to trunk? I guess we need a > > "Backend: M68k" bugzilla component -

Hello David! On 11/16/20 11:30 AM, David Chisnall via llvm-dev wrote: > Generally, the bar for being in-tree is fairly low, the bar to being removed > from the experimental-back-ends list is much higher. An experimental back end > is not built by default and is not in any of the binary releases. > > Experimental back ends provide a probation period for the maintainer community.

Use the newly added u64_to_user_pointer a bit more frequently. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/gpu/drm/armada/armada_gem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++++--- drivers/gpu/drm/tegra/drm.c | 15 ++++++++------- drivers/gpu/drm/vc4/vc4_bo.c | 4 ++-- drivers/gpu/drm/vc4/vc4_gem.c | 10 +++++-----

Use the newly added u64_to_user_pointer a bit more frequently. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/gpu/drm/armada/armada_gem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++++--- drivers/gpu/drm/tegra/drm.c | 15 ++++++++------- drivers/gpu/drm/vc4/vc4_bo.c | 4 ++-- drivers/gpu/drm/vc4/vc4_gem.c | 10 +++++-----

Hi, after a year, I decided to hack on klibc again. I?ve reworked both the patch to add mkstemp(), discussing to use AT_RANDOM as cheap entropy source on IRC (if there will ever be another entropy consumer, I can quickly write a minimal arc4random() seeded from it, as it has only 16 octets), capable of making a working mksh (static and shared) on amd64/xen, and the m68k support code, leading to

Hi, I?ve gone through the mailing list archives and hereby want to resubmit my pending patches. Most are independent of each other, except the m68k patch which will only be complete if sigsuspend is also fixed. (It can be applied before that, though.) http://www.zytor.com/pipermail/klibc/2012-January/003173.html [PATCH] fix m68k support Resubmitted here as 0005. While there was a question from

tag 334917 = patch thanks Hi, I?ve fixed the m68k syscall of klibc and made it able to use six-argument syscalls like mmap2. However, I could not yet fully test it (only mostly; opendir() specifically fails) due to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533 @m68k porters: Please have a look at the gcc bug as well. @klibc: Please apply the patch, it?s better than what we have, and

Hmm, I'm getting nowhere pretty fast. It seems 68000 with its CISC nature is quite complex to implement for a novice. I can see how to implement simple stuff, like -- move dn, dn move dn, (an) As that just turns into stores, sets, etc. But how would you represent things like indexed access? move dn, (an,dn) move dn, offset(an) Can I only really define very simple operations for the main

Hi, I'm getting the following error when I'm trying to compile/link llvm with a backend I have. Running make on the /lib/M68K directory ends without any errors, and I have made all the required files and functions as outlined in http://llvm.org/releases/2.5/docs/WritingAnLLVMBackend.html I copied most of the files from Sparc backend and remove the content from functions mostly. Anyone has

As well as the actual patch reviews, has there been official approval that the M68k experimental backend can be added to trunk? I guess we need a "Backend: M68k" bugzilla component - is there anything else? On 13/11/2020 22:41, John Paul Adrian Glaubitz via llvm-dev wrote: > Hello! > > On 11/3/20 6:10 PM, Min-Yih Hsu wrote: >> Just a quick update on the Motorola 6800

Hi again, I'm finally getting some time to work on my m68k backend again. :) I was trying to solve the problem that loads from arbitrary addresses need to go through address registers. 68k allows flexible addressing similar to what the x86 can do, only that the adressing base has to reside in an address register: move.size[b/w/l] <Displacement>(Ax, Dx * Scale[1/2/4/8]), <Dest>

Hi list, I'm toying with the idea of writing a m680x0 backend for LLVM, and the address modes of this chip are bewildering, to say the least. Here's a rough list off wikipedia for reference: * Register direct o data register, e.g. "D0" o address register, e.g. "A6" * Register indirect o Simple address, e.g. (A0) o

m68k is the only debian arch still lacking a klibc port... So I started working on this tonight, despite not knowing anything about the m68k. Puzzling out the details, and disassembling things, I've at least got a syscall.c that looks like it might work. I don't really have time to do this bring up, but maybe someone else would like to finish the work. I guess this needs at least,

Hi Jason, I love your patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on linus/master v5.7 next-20200529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see

Hi Jason, I love your patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on linus/master v5.7 next-20200529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see