Tagged: Mill Diagnostics
- erikvvParticipantDecember 31, 2013 at 2:59 amPost count: 1
I’m excited about this initiative for a new architecture.
The main source for my enthousiasm are ofcourse the talks by Ivan Godard – without going into specifics OOTB really seems to have listened to the actual problems that I hear compiler writers face when they talk about optimizing for parallelism and using vector instructions.
(on the other hand, the interview by hackaday I saw before that was so superficial it was confusing and lead me to believe there was nothing really there)
The OOTB approach seems in contrast to other in-order architectures, which feel to me more like the hardware designers saying “we know what’s good for you”. Granted these are mostly memories from before the time I had in-depth CS knowledge.
Tech is what drives me, but business is its own world. I think there is a very good chance this may actually succeed commercially and I’ll tell you why.
I don’t know if this is intentional but if there is an actual product coming out this decade that seems like the perfect timing. Previous initiatives failed because companies were still benefitting from the free ride we got from the competition in x86. The market has gotten more mature since.
Secondly OOTB reaching out to the community is unlike anything that I have seen before. Getting to businesses via community is a long-haul effort but it can be very successful.
My conclusion is, I would like to get involved. If it succeeds, I can say I was a part of it. If it fails, I’ll have learned a lot nonetheless.
Obviously OOTB is doing the hardware side of things, so I was wondering if there is any (open source?) project ongoing to build or extend software tools for the Mill. AFAIK the ISA is not revealed yet, so anything functional is impossible. But I would like to hear if anyone out there is working on *something* and might appreciate a helping hand, now or in the future.
- igodardModeratorJanuary 1, 2014 at 8:05 pmPost count: 9
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. 🙂
- alex.shpilkinParticipantMarch 21, 2014 at 1:18 pmPost count: 2
I’m afraid that writing papers using presentation videos only would be rather painful in the absence of any other reference material: essentially the only clean way would be making a complete transcript of each video and then compiling the thing into prose — with references. This strikes me as inefficient and unnecessary, given that you were talking about things that are already filed, and so are already described in prose, if not of the most readable kind. So, are there any published texts, and can we have some references then? 🙂
- Ivan GodardKeymasterMarch 22, 2014 at 8:55 pmPost count: 687
Sorry for the delay in response; I’ve been busy with the Security talk at Google, just completed.
There is a lot of material, in various degrees of up-to-date-ness – 500+ pages of filings and 450+ slides, plus the talks so far and a bit more. Dumping the lot on a newcomer would be too much support for us; our time is better spent in other ways than educating people one at a time about the Mill.
However, if you are interested in a particular sub-topic from one of the presentations, and can realistically commit the time, and can show that you already have the skill, then the relevant material from the trove could be peeled out for you.
So if this fits you, send me a suggested sub-topic and a sample of your writing and we’ll work something out.
- roliverParticipantJanuary 11, 2014 at 8:22 pmPost count: 1
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.
- Joe TaberParticipantJanuary 11, 2014 at 10:12 pmPost count: 25
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.
- Ivan GodardKeymasterJanuary 11, 2014 at 10:38 pmPost count: 687
LLVM is on our list.
There are issues though, which makes a Mill backend a non-trivial undertaking. Essentially the whole backend will be unique to the Mill, because LLVM assumes a register-based target. There are issues in the front and middle ends too – LLVM assumes that pointers are integers, for example, and it can only vectorize counting loops whereas the Mill does while-loops too.
Lastly, the Mill family member operation sets are built from individual specification of the member; nobody manually assigns bits to fields, it’s all done by configuration software. Consequently the backen will be generated in large part, the same way the present asm and sim are, which requires an understanding of the generation system. There’s no instruction set manual to work from; the bit layouts change from member to member, slot to slot, and day to day as we work on it.
We would very much like to talk with people who have already done significant work in LLVM. It’s not a port for a compiler beginner though.
- nicholaswParticipantMarch 22, 2014 at 8:39 pmPost count: 1
Hello , I too am an undergraduate student intrigued by your work.
I think the vectorisation of while loop will not be too hard, because it’s less a case of “LLVM assumes that … it can only vectorize counting loops”, but more like there is currently no middle-end pass for that. I know that that front ends can cause middle-end passes to run (e.g. LDC (the LLVM D compiler) has (among others) a pass to promote some GC allocations to the stack), and therefore I assume that it should be of comparable difficulty (i.e. doable) to cause middle-end passes to run in the presence of the mill back-end.
Of course writing said pass will be a different kettle of fish.
- spyker49ParticipantJune 13, 2014 at 8:39 pmPost count: 5
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.
- Ivan GodardKeymasterJune 13, 2014 at 9:24 pmPost count: 687
Wow, the Nova. I did a compiler for that once, Nova 1200. Language roughly as complex as early C++ in the C-front era, the compiler could compile itself in 64k of (core) memory that you shared with the OS. 🙂
Diagnostics for the Mill need to be written in C++ because they have to integrate with the specification system which is also C++, and the specification data structures, which are C++ data structures. Yes, other languages could be used, but we don’t want the maintenance headaches that language fan-out causes.
But Mill diagnostics are not actually written, they are specified, and from the specifications comes the asm code for the actual target test code. We don’t have the resources, human, money or time, to write diagnostics for a dozen family members and manually track the changes that they incur as they evolve. The same is true for hardware diagnostics, except the output is probe signals or whatever the hardware sims (or the actual hardware in time) talk.
The C++ problem aside, we welcome volunteers for the team. We don’t accept work-for-free volunteers, but we do accept sweat-equity vp;unteers where the team member is compensated by an interest in the company. It is a major cost to us ramping a new person up on the Mill, our code base, and our work, and the ramping must be intensive and productive or the new person never gets out of ramp mode. In practical terms, this means that any new person must realistically be able to commit 20 hours per week on an on-going basis.
For you or any other reader here, if the above sounds like you then contact me directly at firstname.lastname@example.org.
You must be logged in to reply to this topic.