How can I get involved?

The short answer: yes, you can get involved, although perhaps not as quickly as you (or OOTBC) would like.

There are three models that we have considered and believe could work.

In the first, we open-source the Mill software, and stand back.

In the second, we publish a tool set comprising asm, sim, config, and a tool chain (when one becomes usable), and let people configure and write code for Mill targets but not change the tools themselves.

In the third, we invite specific people to join the team, under NDA and with an explicit sweat-equity contract, to work on the the Mill software or hardware directly.

Of these three, the first and second require that we finish the patent filings first; not so many filings for the second approach as for the first though.

The third approach requires much more of our very scarce resources to ramp contributors; not only is the software large and non-trivial and the documentation mostly absent, but the machine itself is still a morphing moving target. Realistically we would need to get at least half time from a contributor to be worth the overhead.

The first and third approach would require serious C++-fu (not C run through a C++ compiler).

There are also a ton of smaller, or at least more easily isolated, things that need help. For example, the videos are full of topics that need expansion into white papers. If you have skill in explaining tech clearly then we’d really like to talk with you; sweat equity, on accepted delivery, all the help you want 🙂

We also need help outside the tech arena. For example, several people have suggested a kickstarter campaign, but it’s hard to figure out a rewards ladder that works for something as long-term and capital-intensive as semi. Start a topic, and see if you and others can come up with what you consider to be a viable ladder. For extra credit, write a script for the Kickstarter video. 🙂

Ivan

Hello,
I would just like to say that I have been following the talks on the Mill CPU with interest and I look forward to seeing it develop into a product. I would love to help in moving the project forward though being a university undergraduate student I don’t think I would have much to offer at this point beyond the enthusiasm of youth and some rudimentary programming and electronics skills.

On a side note I see this architecture being quite appropriate for robotics. The performance per watt trade off lends itself to power constrained environments, general purpose computation for AI and a market that is used to writing highly targeted code.

I will also find it interesting to see how the belt is implemented at the hardware level, as I’m guessing that is the most challenging aspect about the hardware implementation.

Russell

Perhaps an appropriate OSS project would be to build a mill backend for LLVM. Since this would plug into all the existing front-end compilers for free, we’d be able to see how large real world programs would look in mill asm.

Or maybe start implementing a bunch of the interesting RosettaCode examples in mill asm by hand. I don’t know if RosettaCode would accept code samples in mill asm, but at the very least they could be listed and discussed here.

Of course, both of these would require some form of an asm spec. We may be able to construct effective mill asm even without the complete specification, i.e. omit everything NFY, but I wouldn’t know if it would be useful in that state.

Involvement: I would like to offer my services in writing diagnostics for the Mill.

Diagnostics: Although Ivan mentioned test vectors automatically being generated to test the FPGA/silicon that is just a small subset of all possible failure and may not detect non compliance with the INTENDED design.

I consider that diagnostics written by a human with cunning and wild side ideas is better than fully relying on test vectors.
A human looking at the INTENDED design and with deep understanding of the hardware is likely to provide a better test coverage and early detection of inconsistencies in the tool set chain and physical implementation.

Diagnostics are both functional tests and stress tests and are run often with parts/system in an temperature chamber ranging from -40C to +125C or more. At lower temperatures the silicon is faster and often fails with logic timing hazards/tolerances not seen at room temperature. Similar for the higher temperature where the expected clock at 10GHz fails, but may manage to run error free at 8GHz.

I would not write diagnostics in C++ as the decomposition can be too vague for a carefully directed probe test.

About Me: I am still working as an embedded system designer: hardware, firmware, software. In my varied computer engineering career I often wrote CPU, memory and I/O diagnostics in assembler starting in the 1970 for the DG NOVA, PDP-11xx and at least 10 later CPU chips like the 68K. The later diagnostics code was done in C, thank goodness.
Len Spyker