12 ms·
Developers Try Again to Upstream Motorola 68000 Series Support in LLVM
- VonGuard 6y agoThis 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.
- drewg123 6y agoThis 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.
- JaimeThompson 6y agoIf Linus had done that we would not have Linux.
- jandrese 6y agoHuh? Linus targeted the x86 architecture.
- snvzz 6y agoWhich was not a common target for UNICES.
- deleted 6y ago[deleted]
- jandrese 6y agoBut it was a common hardware platform of the day.
- JaimeThompson 6y agoCorrect as did other Unix operating systems so if Linux had stayed in his "sandbox" Linux would have been something much different if it even existed at all.
- drewg123 6y agoDEC 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.
- cesaref 6y agoYeah, I was involved in a large Ada project running on 4 socket Alpha servers back in the early 90s. It was a great platform (OSF/1 anyone?) and was very fast and powerful for it's day. As for bugs, I seem to remember that it had a rather different cache coherency model to Intel, and as you said, was strict about memory alignment.
- trasz 6y agoSome architectures are useful even if one can already tell they are probably not the future. For FreeBSD, sparc64 was important, because you could get multiprocessor sparc64 machines easier (cheaper) than x86 with the same CPU count, even if they were slower; this made it possible to do work on scalability sooner. Now the same is happening with POWER9/10.
- JaimeThompson 6y agoThe sandbox in this instance would be Linux creating a Unix compatible operating system not that Linux supported multiple platforms.
- mumblemumble 6y agoI'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 6y agoSo what? Then the BSDs would have been used instead. Or something else.
- deleted 6y ago[deleted]
- rowanG077 6y agoI think you deeply underestimate embedded use. There are a huge number of devices running on relatively obscure microarchitectures.
- duskwuff 6y ago68k 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.
- tgb 6y agoAs a curious ignorant - what's used now instead of 5V? Why was there a transition away from 5V? I'm assuming this means 5 volts and not something more arcane.
- mumblemumble 6y ago3.3V seems to be where everything is going in the hobbyist space. If your device is powered by batteries, 3.3V will let you get longer battery life than 5V. I think I recall hearing that 3.3V can reduce power consumption by as much as 50% relative to 5V. If your device is powered by USB, which is nominally 5V, 3.3V can still be nice because USB power supplies don't always supply the cleanest power, so regulating it down to 3.3V can result in a more reliable power supply.
- wongarsu 6y agoMost microcontrollers moved to 3.3V, or even 1.8V. Some of them have some 5V tolerant ports to communicate with 5V devices, but for the most part embedded now runs on and communicates over 3.3V. The reason is mostly power efficiency and the option for higher frequencies as far as I'm aware
- tssva 6y ago3.3v and 1.2v are probably the most common these days but there are other voltages in use. Lower power usage, less heat and smaller packaging are the main drivers for lower voltages.
- CalChris 6y ago-DLLVM_TARGETS_TO_BUILD="x86-64;arm64;ppc64"
- CountSessine 6y agoWhat 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.
- CalChris 6y agoI'm straining to understand how a branch-to-be-pulled for your backend will break SystemZ unless you've been modifying the shared middle end. If you have then you tell them you're going to reduce your test case and also that you're going to contact the SystemZ and SPARCV8 maintainers. Maybe your branch won't make it into the tree. Maybe it's your fault or maybe it's theirs; if it's theirs they'll WANT to know about it. Maybe it won't make it into the tree for this release but it might for the next after the bug is fixed. Development is done in parallel and the middle end always gets improved by being stretched and abused by multiple backends. There are out of tree backends which beat the hell out of GlobalISel (Apple GPU). I'm GLAD that they've done the hard work of beating GlobalISel into shape because it makes it a more stable platform for me. There are in tree backends which are models for cloning (MIPS) even though the vendor is basically an IP holding company. LLVM stands in contrast to GCC. LLVM was architected as a collection of modular and reusable compiler and toolchain technologies. And then when people actually do that it's a good thing. Right now LLVM 11 is in RC4, about a month late. There is surprisingly little if any sturm und drang on the developers' list about this slip. Work on LLVM 12 has commenced, in parallel.
- CountSessine 6y agoI'm straining to understand O_o how a branch-to-be-pulled for your backend will break SystemZ unless you've been modifying the shared middle end. OP: 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 don't think the OP said anywhere that he was exclusively developing an arch backend. If you have then you tell them you're going to reduce your test case and also that you're going to contact the SystemZ and SPARCV8 maintainers. Maybe your branch won't make it into the tree. Maybe it's your fault or maybe it's theirs; if it's theirs they'll WANT to know about it. Maybe it won't make it into the tree for this release but it might for the next after the bug is fixed. Yes - and this all goes back to what the OP complained about - that these are moribund platforms and that keeping them running is an undue burden for devs working on living archs and extending the Clang/LLVM spine. I'm GLAD that they've done the hard work of beating GlobalISel into shape because it makes it a more stable platform for me ...which is why the OP mentioned that it might be an unpopular opinion. The OP is doing work for you, extending Clang/LLVM while keeping it in working order for platforms that shouldn't be supported based on deployments, "beating [it] into shape" for you. Snarky replies like "use the right compiler options, duh" seem mean-spirited.
- zozbot234 6y 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 6y agoLLVM’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.
- cbmuser 6y 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.
- google234123 6y agoPractically no one is doing vulnerability research on hobby platforms.
- cbmuser 6y agoWell, the previous comment also suggested to exclude RISC-V, S390x and so on which are certainly not hobbyist targets.
- google234123 6y agoI would imagine there are 100 times more security researchers and graduate students looking at Intel than those two.
- loeg 6y agoOP isn't talking about Linux, and no one wants to run FreeBSD on their mainframe. In that sense, it would be a hobbyist platform for FreeBSD.
- mycall 6y agoPerhaps that makes them more secure, indirectly.
- pmarin 6y agoMany people who contribute code to those legacy platforms also end contributing to the modern ones. NetBSD is a very good example.
- loeg 6y agoOP is talking about FreeBSD, and largely... people don't contribute to the ones he didn't mention. They just languish.
- nicoburns 6y agoI 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.
- loeg 6y agoIsn'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?
- Teknoman117 6y agoFor what it's worth, AVR got accepted into LLVM and there is now Rust for AVR.
- pjmlp 6y agoIt shouldn't, this is the kind of stuff where bare metal is the best option.
- korethr 6y agoI 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 https://marc.info/?l=openbsd-tech&m=138973312304511&w=2
- legulere 6y agoYou 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 6y agoI 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 6y agoWhat is a hobby platform changes over time though. https://www.researchgate.net/profile/Paul_Carpenter6/publication/261596622/figure/fig1/AS:614203228426277@1523448869719/TOP500-Special-purpose-HPC-replaced-by-RISC-microprocessors-in-turn-displaced-by-x86.png https://www.researchgate.net/profile/Paul_Carpenter6/publica...
- phendrenad2 6y agoI 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.
- cmrdporcupine 6y ago68k 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 6y agoSo 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.
- loeg 6y agoNo, that's not the tradeoff.
- renewiltord 6y agoI'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.
- cbmuser 6y agoBut NeoVIM builds perfectly fine on m68k: > https://buildd.debian.org/status/package.php?p=neovim&suite=sid https://buildd.debian.org/status/package.php?p=neovim&suite=... :-)
- renewiltord 6y agoHaha! But not all of the ones where vim does! Right? Unless someone added it back. I haven't followed development since the early days.
- 0x00000000 6y agoYou 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.
- loeg 6y agoOP 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).
- CalChris 6y agoSPARC + MIPS are both 30+ years old. The 68000 is 41 years old and x86 is 42 years old.
- SomeoneFromCA 6y ago68000 is more like 80286 or even 386 though. So you should probably mention i386, not x86.
- cmrdporcupine 6y ago68k 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.
- Teknoman117 6y agoIt 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.
- jerrysievert 6y agothis 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/ http://legacy.obviously.com/dice/ and https://github.com/noname22/NeoDICE https://github.com/noname22/NeoDICE) but having first class support in llvm would be very nice.
- snvzz 6y agoDICE'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/ https://www.dragonflybsd.org/ [1]: http://sun.hasenbraten.de/vbcc/ http://sun.hasenbraten.de/vbcc/
- pengaru 6y 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.
- jerrysievert 6y agoah, I completely mis-read that, thanks!
- korethr 6y agoIt 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 6y agoI 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 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/ https://www.freepascal.org/) and also AVR and bunch of other archs.
- korethr 6y 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?
- duskwuff 6y ago> A thought occurs to me: would it be possible to use that compiler to bootstrap your way to a modern C dialect? You don't need to. SmallC is a cross-compiler, not a self-hosting compiler; it runs on a modern computer, not an 8085. If you wanted to modify SmallC to accept modern C syntax, you can do that without "bootstrapping" anything.
- arcticbull 6y ago
- cbmuser 6y agoIf 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 https://www.youtube.com/watch?v=-6zXXPRl-QI Slides can be found here: http://m68k.info/assets/LLVM-Backend-for-M68k-Overview-and-Status-Update.pdf 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-the-m68000-backend-so-it-can-be-merged-upstream 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.
- siraben 6y agoAre 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 6y agoThat's an 8-bit CPU.
- avian 6y agoYou 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/ http://sdcc.sourceforge.net/
- snvzz 6y agoThere's vbcc[0], which, besides 68000, supports a bunch of architectures including 6502 and 6809. [0]: http://www.compilers.de/vbcc.html http://www.compilers.de/vbcc.html
- cbmuser 6y agoThere actually is a Z80 backend for LLVM: > https://github.com/jacobly0/llvm-project https://github.com/jacobly0/llvm-project
- ndesaulniers 6y agoNeat. I've been tempted to try writing a Sharp LR35902 LLVM backend... Probably would be very close to Z80.
- christkv 6y agoI wonder if this is related to the vampire accelerator (new amiga).
- cbmuser 6y agoNot directly but adding support for the 68080 target would definitely be possible.
- metroholografix 6y agoThe 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.
- loeg 6y agoDirect link to the mailing list post for convenience: https://lists.llvm.org/pipermail/llvm-dev/2020-September/145320.html 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 6y agoI hope they succeed so I can write Sega Genesis games in Rust