<story><title>Developers Try Again to Upstream Motorola 68000 Series Support in LLVM</title><url>https://www.phoronix.com/scan.php?page=news_item&amp;px=LLVM-Motorola-6800-Series-2020</url></story><parent_chain><item><author>drewg123</author><text>This is probably an unpopular opinion, but I hate having hobby platform support in modern projects.&lt;p&gt;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 &amp;amp; run, you have to build&amp;#x2F;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.&lt;p&gt;I&amp;#x27;m fine with hobby platforms if they play in their own sandbox, but not when they impede development of current systems.</text></item></parent_chain><comment><author>korethr</author><text>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.&lt;p&gt;Or maybe I was misunderstanding the point of Theo&amp;#x27;s post back in 2014 around the discussion of their power bill[1].&lt;p&gt;1. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;marc.info&amp;#x2F;?l=openbsd-tech&amp;amp;m=138973312304511&amp;amp;w=2&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;marc.info&amp;#x2F;?l=openbsd-tech&amp;amp;m=138973312304511&amp;amp;w=2&lt;/a&gt;</text></comment>
<story><title>Developers Try Again to Upstream Motorola 68000 Series Support in LLVM</title><url>https://www.phoronix.com/scan.php?page=news_item&amp;px=LLVM-Motorola-6800-Series-2020</url></story><parent_chain><item><author>drewg123</author><text>This is probably an unpopular opinion, but I hate having hobby platform support in modern projects.&lt;p&gt;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 &amp;amp; run, you have to build&amp;#x2F;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.&lt;p&gt;I&amp;#x27;m fine with hobby platforms if they play in their own sandbox, but not when they impede development of current systems.</text></item></parent_chain><comment><author>pm215</author><text>I have a lot of sympathy for this view, especially since &amp;#x27;hobby&amp;#x27; 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 &amp;#x27;tier list&amp;#x27; with criteria and consequences for being in each tier (so for instance lower-tier ports might be in a &amp;quot;nobody else is expected to build&amp;#x2F;test this, failures are not a blocker for commits&amp;quot; grouping). That doesn&amp;#x27;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&amp;#x27;t looked up the details.)</text></comment>