Mill Computing, Inc. › Forums › The Mill › Architecture › MILL and OSS
- AuthorPosts
- #3202 |
Are you planning to open source the specializer / loader (at least the one for planned Linux port).
I guess the VCs might oppose given that it would contain lots of custom optimizations (which form bulk of value proposition for the architecture). On the other hand trying to patent static optimization / Ops scheduling algos might not work outside of the US.
Requiring bin blobs to support the architecture won’t win a lot of enthusiasm in the OSS community and that might be needed to get the things off the ground. One persistent conspiracy theory concerning existing commodity CPUs is “features” undisclosed to the consumer that allow Three Letter Agencies to do unfriendly things with your computer. An open source specializer, operating in place of the closed out of order computing manager, would make the Mill favorable to people concerned with secret features on their computers.
Back doors are more of a potential issue with micro-coded architectures because it’s a lot easier to embed a door in software (which at heart is what microcode is) undetectably than in hardware. It’s also easier to do in a bizarrely complicated design like OOO than one that is way simpler.
I hope we are never approached with a demand to inject something.
We expect that we will publish the tool chain and the rest of the reference software. The situation with the specification tools is unclear, as they would not be of use to users of Mill chips but might be of considerable use to vendors of competing chips.
What you could do is release an open-source specializer for that community that takes out some of the magic to placate the VCs, but is OSS. It has been said that the user will be able to write their own specializer ( https://millcomputing.com/topic/meltdown-and-spectre/#post-3172 ). It shouldn’t matter if there are binary blobs on the MOBO if they aren’t being called. It’s not like the specializer will be Intel’s Management Engine (a “feature” of Intel MOBOs that is a SOC that covertly runs MINIX 3)?
I can see, though, how such a thing (a bare-bones skeleton specializer) is really only useful to two groups: superusers who want to replace it, and competitors.
Yep.
So I assume that means that the open-source specializer generator will itself be written in ordinary C++ and be able to generate x86 or ARM code that can do the specialization, right? Because if the only way to generate conASM for a specializer is the closed-source specializer, you’re going to have an obvious trusting trust problem.
Of course, adding complex, self-hiding backdoor code in the specializer and debugger would probably make specialization and debugging very slow, which would make most genASM JIT very slow–and as you often note, you’re in it for the money.
Thomas D:
Also, students. Regardless of the Mill architecture’s commercial success (or failure), I can’t imagine it won’t be studied. It’s too different and has too many good ideas to ignore from that PoV.If the Mill is half as good as it looks on the presentations, and if/when they manage to get it out the door, I can’t imagine it failing.
It would certainly be an interesting case study in the classroom. It shows that there is still plenty of room for innovation in CPU architecture
I hope we are never approached with a demand to inject something.
This sounds like a great opportunity for a warrant canary. 😉
- AuthorPosts
You must be logged in to reply to this topic.