▲ 128 points
back
122 comments
If you're interested in the current status of the backend, please have a look at this talk on Youtube:
> https://www.youtube.com/watch?v=-6zXXPRl-QI
Slides can be found here: http://m68k.info/assets/LLVM-Backend-for-M68k-Overview-and-S...
And a Bountysource campaign to support the project here:
> https://www.bountysource.com/issues/90829856-llvm-complete-t...
Disclaimer: I'm one of the people behind this project but not the main developer. So funds are going to the developer, not me.
It would be cool if 68k support landed in LLVM. I've been wanting to do a 68k-based retrocomputer project for a while. If I ever get started on such a project, being able to use a modern compiler would be nice.
I have recently built a simple 8085 computer on a breadboard and finding a working and open-source C compiler was a huge challenge. Finally I found this one: https://github.com/ncb85/SmallC-85 but it supports ancient K&R C syntax, without such goodies like subscript operator or character literals. Still I prefer ancient C than ancient assembly language.
On the other hand there is Small Device C Compiler (SDCC) project that provides a decent compiler for Z80 CPU. There is also cc65 for 6502 CPUs.
The strangest thing is that Free Pascal seems to support 68k out of the box (https://www.freepascal.org/) and also AVR and bunch of other archs.
Free Pascal has shockingly broad platform support:) One of the things I always found cool about it.
> but it supports ancient K&R C syntax, without such goodies like subscript operator or character literals. Still I prefer ancient C than ancient assembly language
A thought occurs to me: would it be possible to use that compiler to bootstrap your way to a modern C dialect? At one point, there were no C89 compilers. So, one would have to write a C89 compiler in K&R. Or am I failing to appreciate just how much work it would be?
I vaguely recall trying to write fixed point math functions using sdcc for a gameboy homebrew project a long time ago. I’d compile and run via an emulator. Good times!
So, use gcc, which is what the BSD ports supporting m86k use. See also
https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-m...
I know about GCC. In fact, I'm the one who created the Bountysource campaign to convert the m68k backend in GCC to MODE_CC.
There are languages that LLVM supports that GCC doesn't.
One annoying thing is that nobody makes new 68k CPUs anymore. The only real source appears to be scavenged chips from China.
If you want to limit your retrocomputer design to only parts that are still manufactured, like I do: The only cpu choices appear to be: Z80, 68c02 and 68c816
In 2014, Rochester Electronics has re-established manufacturing capability for the 68020 microprocessor and it is still available today.
Which is a shame. Just from high level descriptions of the 68k architecture, compared to my own (albeit very limited) experience with x86 assembly, the 68k seems a much more elegant and easier to program architecture.
There is the Vampire 68080 which features new instructions.
Looks like NXP is still making M68k CPUs, but I don't know about dev boards.
https://www.nxp.com/products/processors-and-microcontrollers...
you know that GCC had support for 68k and it's a modern compiler, not ?
This is probably an unpopular opinion, but I hate having hobby platform support in modern projects.
I work on a OS kernel (non-Linux), and in my view, we should support x86_64, arm64, and maybe ppc64le. But instead we have all sorts of 32b legacy hobbiest platforms where there are maybe 3 machines in the world running on them. These platforms make it harder to test changes, simply by the fact that it takes regression tests longer to compile & run, you have to build/install more cross tools, etc. They make it harder to develop because all of a sudden you realize that some standard interface is not implemented on them, and you have regression test failures that you need to work around.
I'm fine with hobby platforms if they play in their own sandbox, but not when they impede development of current systems.
I seem to recall the OpenBSD folks deliberately keeping around uncommon and old architectures in part because compiling and running on those old architectures flushes out bugs. So, from that perspective, your regression tests failing on legacy hobbyist platforms is a good thing.
Or maybe I was misunderstanding the point of Theo's post back in 2014 around the discussion of their power bill[1].
I have a lot of sympathy for this view, especially since 'hobby' platforms tend also to be those whose maintainers are doing it on the side and who are thus less likely to be keeping up with internal API and similar cross-codebase improvements. But it gets complicated when the project is a foundational one like LLVM, where dropping or not accepting support for an architecture is effectively also locking the architecture out from a wide swathe of other projects (for instance, Rust, and via Rust also Firefox). I think the best way to manage this seems to be to have an official 'tier list' with criteria and consequences for being in each tier (so for instance lower-tier ports might be in a "nobody else is expected to build/test this, failures are not a blocker for commits" grouping). That doesn't solve the problems, but it does at least mean everybody knows where they stand.
(IIRC LLVM does have a tier list system but I haven't looked up the details.)
> ...I'm fine with hobby platforms if they play in their own sandbox, but not when they impede development of current systems.
LLVM has an "experimental platform" flag that obviates this problem. IIRC, the Linux kernel also has something similar wrt. highly experimental config options.
> x86_64, arm64, and maybe ppc64le
All of them commercial products and from companies in the US and the UK.
The problem with limited platform support is the lack of competition which helps to lower prices and provides more choice to the customer.
Especially considering the many vulnerabilities Intel CPUs have.
I'm aware that hobbyists platforms are something different, but you excluded many other commercial targets like MIPS, RISC-V, S390 as well.
If Linus had done that we would not have Linux.
I think you'd need to add at least a few more architectures to the list. I for one am actively intending on using AVR and Xtensa (for arduino and esp32 support). And RISC-V probably ought to be in there as an architecture of the future.
Many people who contribute code to those legacy platforms also end contributing to the modern ones. NetBSD is a very good example.
You probably have at least one MIPS device in your house (router or modem). Based on the three architectures you named it sounds like your project isn’t really aimed towards embedded systems. But those legacy architectures are dirt cheap, relatively energy efficient, and good enough for most purposes so they aren’t going away any time soon.
-DLLVM_TARGETS_TO_BUILD="x86-64;arm64;ppc64"
I think you deeply underestimate embedded use. There are a huge number of devices running on relatively obscure microarchitectures.
What is a hobby platform changes over time though.
https://www.researchgate.net/profile/Paul_Carpenter6/publica...
So you'd rather have bugs because you'd rather not worry about bad assumptions and bad practices which come from monocultures. It's a good thing many of the people in large projects don't agree with you.
I'm sympathetic and funded Neovim bounty - the first thing of which they used it for was pulling legacy support. But I think that's the model. You have a base tool that does everything and then maybe this other thing that demonstrates there are developments that are stalling because of the base tool's support of legacy platforms.
I suspect for many tools, the hobby platform guys are the same as the other patch guys.
I love hobby platforms like 68k, but I definitely agree with you.
It's become unthinkable in the open-source world to not have "one X to rule them all" (in this case X happens to be "compiler", but you see this effect with other tools).
Hobby platforms, especially long-dead ISAs like 68k, should be easy to integrate with LLVM (perhaps through a plugin system? I'm pretty sure both GCC and LLVM have that... you install `gcc` and then you install `gcc-platform-x` or something...) but requiring LLVM core maintainers to think about your obscure arch is not worth it IMO.
Direct link to the mailing list post for convenience:
https://lists.llvm.org/pipermail/llvm-dev/2020-September/145...
Normally Phoronix is more or less blogspam, but in this case Larabel has actually added some interesting context (history of the backend in LLVM and GCC). So I do not suggest changing the discussion's URL to the ML post.
This would be so cool, and could potentially target things like the Amiga and the old school Macintosh! Yay!
As a preservationist, I can confirm this would be used. Not much, but it would be used.
SPARC + MIPS are both 30+ years old. The 68000 is 41 years old and x86 is 42 years old.
68000 is more like 80286 or even 386 though. So you should probably mention i386, not x86.
I hope they succeed so I can write Sega Genesis games in Rust
Are there efforts to do this for 8-bit processors such as the Z80? Famously they are not very suited for compiling C to because of the limited number of registeres, but LLVM does aggressive register allocation that might make it practical.
Edit: Z80 is 8-bit, not 16-bit.
There actually is a Z80 backend for LLVM:
You might be interested in SDCC, a C compiler that supports Z80, among other small architectures. I'm happy to see it's still actively developed.
There's vbcc[0], which, besides 68000, supports a bunch of architectures including 6502 and 6809.
That's an 8-bit CPU.
this would be fantastic to see. with gcc dropping support, that leaves few options for legacy and hobbyist systems.
you can still download and compile dcc (http://legacy.obviously.com/dice/ and https://github.com/noname22/NeoDICE) but having first class support in llvm would be very nice.
> with gcc dropping support, that leaves few options for legacy and hobbyist systems
TFA clearly states gcc support was rescued by hobbyists in the community, it's not being dropped.
DICE's author is still active (Matt Dillon, behind Dragonfly BSD[0]). That's cool.
Other than dice, there's vbcc[1].
I wonder if this is related to the vampire accelerator (new amiga).
The vampire accelerator is not Amiga.
It's a closed -buggy- FPGA reimplementation of something like 68k (nobody outside them knows exactly what, there are rumors it's based on a ColdFire core that was leaked by mistake) with some custom extensions that are underdocumented and have nothing to do with classic Amiga systems.
The entire platform is meant to lock you into their proprietary FPGA core and is totally counter the spirit of the Amiga which was the ultimate hacker's machine.
Not directly but adding support for the 68080 target would definitely be possible.