similar to: [LLVMdev] m68k backend

Hi Min! On 11/3/20 6:10 PM, Min-Yih Hsu wrote: > Showing the prerequisites to become an experimental target and eventually, > an official target. We're currently struggling on setting up the buildbot > but I believe Adrian (CC-ed) is working on that. So I hope the patches can > be sorted out while waiting for the buildbot. The m68k machine is actually already up and running, I

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

Hello! On 11/3/20 6:10 PM, Min-Yih Hsu wrote: > 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. Are there any news on this? The M68k buildbot is ready

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 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 - is there anything else? Sounds good. I'll file that bug tomorrow. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz :

Hi, To add to what Renato said: On 15/11/2020 21:59, Fāng-ruì Sòng via llvm-dev wrote: > I've looked at a few newer backends in LLVM and I think the policy is > unclear about how an experimental target is approved and reviewed. It's generally good form to tag anyone who commented in the mailing list threads on any patches, especially people who objected. If they're happy in

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.

Hello Kenneth, I don't know of any 68k backend and would certainly appreciate it if somebody took up the task! I'm working on a frontend for compatibility with the old Amos BASIC on the Amiga and was going to have to start a new backend for the classic models. That being said, I don't think 3 or 4 weeks would be enough unless you're really good with both 68k Assembly and

Hi All, We would like to contribute our supports for Motorola 68000 series CPU (also known as M68k or M680x0) into LLVM. And we want to hear feedbacks from you Here is some background for M68k: Motorola 68000 series CPU was one of the most popular CPUs used by personal computers in the ‘80, including some of the earliest Apple Macintosh. Fast-forwarding to modern days, M68k is still popular

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

Debian: (Closes: #334917) Signed-off-by: Thorsten Glaser <tg at mirbsd.de> --- usr/klibc/arch/m68k/syscall.S | 42 +++++++++++++++++++++++++++++++++------- usr/klibc/arch/m68k/vfork.S | 13 +++-------- 2 files changed, 38 insertions(+), 17 deletions(-) diff --git a/usr/klibc/arch/m68k/syscall.S b/usr/klibc/arch/m68k/syscall.S index 966c92d..f468678 100644 ---

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 -

The parts of klibc specific to the m68k architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit bc9b363b31d301ab94c115cccc2e079c0d318498 tree db9cf277429e2722b8c51f68897991f0759b1d02 parent 7ba219f9bcddda38ddc9010b54fd10431292f744 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:29 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

On Mon, 28 Sep 2020 at 19:13, Min-Yih Hsu <minyihh at uci.edu> wrote: > Thanks for all your feedback, those were extremely helpful, especially the > guidelines to split the patches. I think in my case, patch 3 ~ 6 are the > most problematic, I will rework them shortly. > Perfect, thanks! And most importantly, I'll present a roadmap regarding blockers we need to > clear

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,

found by Christian T. Steigies <cts@debian.org> usr/klibc/arch/m68k/crt0.o: In function `_start': usr/klibc/arch/m68k/crt0.S:(.text+0xe): undefined reference to `___libc_init' too many '_'. never seen jbsr, converted that to jsr. Signed-off-by: maximilian attems <maks@sternwelten.at> diff --git a/usr/klibc/arch/m68k/crt0.S b/usr/klibc/arch/m68k/crt0.S index

found by Christian T. Steigies <cts@debian.org> usr/include/arch/m68k/klibc/archstat.h:12: error: syntax error before '__dev64' better use __stdev64 defined in klibc/stathelp.h Signed-off-by: maximilian attems <maks@sternwelten.at> diff --git a/usr/include/arch/m68k/klibc/archstat.h b/usr/include/arch/m68k/klibc/archstat.h index 89c0341..dce25f9 100644 ---

Split out subsystem specific changes for easier reviews. This will be squashed with main commit. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- arch/m68k/kernel/dma.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c index cbc78b4117b5..8cf97cbadc91 100644 --- a/arch/m68k/kernel/dma.c +++

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

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 >