Developers Try Again to Upstream Motorola 68000 Series Support in LLVM

https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Motorola-6800-Series-2020

by emptybits • 6 years ago

128 122 6 years ago

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.

snvzz9• 6 years ago

DICE's author is still active (Matt Dillon, behind Dragonfly BSD[0]). That's cool.

Other than dice, there's vbcc[1].

[0] https://www.dragonflybsd.org/

[1] http://sun.hasenbraten.de/vbcc/

pengaru• 6 years ago

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.

jerrysievert2• 6 years ago

ah, I completely mis-read that, thanks!

korethr5• 6 years ago

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.

0xmarcin• 6 years ago

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.

korethr5• 6 years ago

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?

yjftsjthsd-h• 6 years ago

Free Pascal has shockingly broad platform support:) One of the things I always found cool about it.

marktangotango• 6 years ago

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!

phire5• 6 years ago

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

korethr5• 6 years ago

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.

krallja• 6 years ago

In 2014, Rochester Electronics has re-established manufacturing capability for the 68020 microprocessor and it is still available today.

(https://en.wikipedia.org/wiki/Motorola_68020)

cbmuser9• 6 years ago

There is the Vampire 68080 which features new instructions.

See: http://apollo-core.com/index.htm?page=products

weare138• 6 years ago

Looks like NXP is still making M68k CPUs, but I don't know about dev boards.

https://www.nxp.com/products/processors-and-microcontrollers...

not2b• 6 years ago

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...

AnIdiotOnTheNet• 6 years ago

There are languages that LLVM supports that GCC doesn't.

cbmuser9• 6 years ago

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.

Zardoz84• 6 years ago

you know that GCC had support for 68k and it's a modern compiler, not ?

cbmuser9• 6 years ago

Yes, but GCC cannot be used as a backend for other languages like Rust. My primary goal is to get Rust support for m68k.

VonGuard• 6 years ago

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.

drewg1232• 6 years ago

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.

JaimeThompson3• 6 years ago

If Linus had done that we would not have Linux.

jandrese2• 6 years ago

Huh? Linus targeted the x86 architecture.

drewg1232• 6 years ago

DEC Alpha was the first non-x86 platform supported in Linux (and in FreeBSD, where I did a lot of the work). Linux was doing just fine in 1994 when DEC gave Linus an alpha at the Boston USENIX.

The key fact is that, in the mid 90s, DEC Alpha was the fastest thing around, and poised to take over the world. It was expected to be the future (until it was killed by corporate incompetence and itanic). That's why I worked on FreeBSD support, and why Linus worked on Linux support. Alpha was also valuable because it was one of the first 64-bit platforms, and found a lot of pointer/int/long bugs on both systems.

There is a big difference between supporting what you expect to be the future of computing to what you know to be the long dead past.

mumblemumble2• 6 years ago

I'd submit that Linux being more choosy about what architectures it supported was a big factor in why it overtook, and ultimately surpassed, the incumbent open source Unixes.

LargoLasskhyfv• 6 years ago

So what? Then the BSDs would have been used instead. Or something else.

rowanG077• 6 years ago

I think you deeply underestimate embedded use. There are a huge number of devices running on relatively obscure microarchitectures.

duskwuff4• 6 years ago

68k is basically dead in embedded. Most of the parts have been out of production for many years, and the ones that remain are only used for legacy applications -- they're 5V parts, making them incompatible with most newer components, and they're completely outclassed by ARM microcontrollers.

loeg8• 6 years ago

OP is talking about FreeBSD, and the only "obscure" embedded microarchitectures FreeBSD supports that he did not mention are 32-bit ARM, MIPS, PPC, and RISCV.

pabs32• 6 years ago

Even relatively common devices have obscure architectures in them, an example of this is that Allwinner ARM CPUs have an OpenRISC core for power management:

https://linux-sunxi.org/AR100

CalChris3• 6 years ago

-DLLVM_TARGETS_TO_BUILD="x86-64;arm64;ppc64"

CountSessine2• 6 years ago

What do you say to the LLVM maintainers when your branch-to-be-pulled breaks SystemZ or SPARCV8 regression tests?

That's the OP's point. Merging LLVM changes is gated by CI tests for obscure and moribund platforms.

zozbot234• 6 years ago

...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.

johncolanduoni• 6 years ago

LLVM’s architecture also makes supporting these platforms much less intrusive on the codebase than in an OS (or even other compilers), especially if they’re only for hobbyist use and aren’t doing many architecture specific optimizations.

cbmuser9• 6 years ago

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.

google2341232• 6 years ago

Practically no one is doing vulnerability research on hobby platforms.

pmarin• 6 years ago

Many people who contribute code to those legacy platforms also end contributing to the modern ones. NetBSD is a very good example.

loeg8• 6 years ago

OP is talking about FreeBSD, and largely... people don't contribute to the ones he didn't mention. They just languish.

nicoburns• 6 years ago

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.

loeg8• 6 years ago

Isn't AVR a dead-end architecture? In addition to being an 8-bit or 16-bit platform without an IOMMU? Why should a general-purpose OS target AVR?

korethr5• 6 years ago

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].

1. https://marc.info/?l=openbsd-tech&m=138973312304511&w=2

legulere• 6 years ago

You can view code that assumes a little endian system or eight bit bytes as a bug, or you can see it simply as making reasonable assumptions. In the end programming always is about making assumptions and reducing scope to prevent an explosion of complexity.

pm215• 6 years ago

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.)

StreamBright• 6 years ago

What is a hobby platform changes over time though.

https://www.researchgate.net/profile/Paul_Carpenter6/publica...

phendrenad2• 6 years ago

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.

cmrdporcupine3• 6 years ago

68k is not a long dead ISA. Coldfire (68k ISA based) MCUs are still manufactured and used in products. Yes, NXP is pushing ARM instead now, like everyone else, but there is still hardware out there that needs software.

johnklos• 6 years ago

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.

loeg8• 6 years ago

No, that's not the tradeoff.

renewiltord2• 6 years ago

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.

cbmuser9• 6 years ago

But NeoVIM builds perfectly fine on m68k:

https://buildd.debian.org/status/package.php?p=neovim&suite=...

:-)

0x00000000• 6 years ago

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.

loeg8• 6 years ago

OP mentioned arm64, which can be used in these kinds of embedded contexts (with tens of MB of RAM, an IOMMU, and mostly traditional off-the-shelf operating system).

CalChris3• 6 years ago

SPARC + MIPS are both 30+ years old. The 68000 is 41 years old and x86 is 42 years old.

SomeoneFromCA• 6 years ago

68000 is more like 80286 or even 386 though. So you should probably mention i386, not x86.

cmrdporcupine3• 6 years ago

68k is an architecture series and this compiler will target the whole series including the later models which are equivalent to Pentium, and the Coldfire processors which are still in production.

So 68k really is comparable to (32-bit) x86.

Teknoman1175• 6 years ago

It is a full 32 bit ISA though, even if the 68000 and 68010 cores had 16 bit buses. They're about twice as fast as a 286 at the same frequency.

cbmuser9• 6 years ago

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.

siraben2• 6 years ago

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.

Narishma• 6 years ago

That's an 8-bit CPU.

avian• 6 years ago

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.

http://sdcc.sourceforge.net/

siraben2• 6 years ago

I have heard of SDCC, but even on small programs such as int main() { return 4; } it generates quite a bit of code. Can it be more optimized?

loeg8• 6 years ago

SDCC is not especially great.

snvzz9• 6 years ago

There's vbcc[0], which, besides 68000, supports a bunch of architectures including 6502 and 6809.

[0] http://www.compilers.de/vbcc.html

cbmuser9• 6 years ago

There actually is a Z80 backend for LLVM:

https://github.com/jacobly0/llvm-project

ndesaulniers• 6 years ago

Neat. I've been tempted to try writing a Sharp LR35902 LLVM backend... Probably would be very close to Z80.

christkv• 6 years ago

I wonder if this is related to the vampire accelerator (new amiga).

cbmuser9• 6 years ago

Not directly but adding support for the 68080 target would definitely be possible.

metroholografix• 6 years ago

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.

loeg8• 6 years ago

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.

metalforever• 6 years ago

I hope they succeed so I can write Sega Genesis games in Rust

Developers Try Again to Upstream Motorola 68000 Series Support in LLVM

Related Stories