11 ms·
LLVM Meets the Truly Alien: Mill CPU Architecture [video]
- nly 11y agoLinking to a 2.3 GB file on HN is perhaps not the best move.
- jdc 11y agohttp://jsbin.com/jikisugifu/edit?output http://jsbin.com/jikisugifu/edit?output
- nly 11y agoStill loads it off llvm.org
- killercup 11y agoIndeed! Here's the 465MB SD version! http://llvm.org/devmtg/2015-04/Videos/SD/day%202/Ivan_1.mp4 http://llvm.org/devmtg/2015-04/Videos/SD/day%202/Ivan_1.mp4
- deleted 11y ago[deleted]
- iso8859-1 11y agoI put it on YouTube: https://www.youtube.com/watch?v=QyzlEYspqTI https://www.youtube.com/watch?v=QyzlEYspqTI EDIT: Updated with complete video link
- nly 11y agoWhy is it 7 minutes short?
- iso8859-1 11y agoSeems my download was truncated at 2485374429 bytes, a mere 137934 over the 2 GB mark for some reason. I'll fix it and post the new link. EDIT: The link was updated.
- dang 11y agoPlease do. If there's a complete copy on YouTube we'll change the post to that URL. Edit: I've changed the URL to the truncated one temporarily, because even a truncated most-of is probably better than a large file download. http://llvm.org/devmtg/2015-04/Videos/SD/day%202/Ivan_1.mp4 http://llvm.org/devmtg/2015-04/Videos/SD/day%202/Ivan_1.mp4 is a URL for the whole thing.
- aidenn0 11y agoDoes anybody know The Mill's plan for commercialization?
- analognoise 11y agoGenerate buzz, get bought, never produce anything.
- knz42 11y agoPatents count I believe ;)
- kjs3 11y agoGenerate buzz, file patents, get bought, never produce anything.
- kinghajj 11y agoThey've publicly stated that they intend to produce their own chips, though. Regarding licensing the architecture (a la ARM), Ivan said during a talk that Intel's quarterly dividend was as much as ARM's yearly revenue. So I don't think that selling the entire company is even on their radar right now, unless you're really cynical and doubt that declared intention.
- kjs3 11y agoYou forgot "have a legion of sycophants/sockpuppets that systematically downmod any post that's less than a furious jerkoff over how amazing Mill is".
- chc 11y agoIt's a middlebrow dismissal. It should be downvoted. That's not sycophancy, it's just Hacker News' losing battle to keep the conversation stimulating and worthwhile.
- 11y ago
- state 11y agoIt's so unusual to find projects like this. I have so much respect for these guys. It's always fun to see what they're working on. Lots of the technical specifics are over my head, but I really appreciate their tone and approach.
- igravious 11y agoPrevious discussion (with a member of their team chiming in): https://news.ycombinator.com/item?id=9856334 https://news.ycombinator.com/item?id=9856334 Seems like a _fascinating_ architecture. I don't get the double program counter bit, also seems like too much cognitive overhead to me. The belt (queue of un-named slots) idea and function call for free with multiple return results, such that regular ops and user defined functions work the same way, that sure is clever. Godard mentions that the CPU space has seen little to no innovation. But what about Transmeta? They were doing some cool stuff, no? And the DEC Alpha, that was super interesting. Probably lots more besides. I'm sure if I bothered to check that Wikipedia would have a CPU graveyard page :) Thing is, x86 has been the only game in town for a long time with Motorola challenging in the past and ARM challenging now. Maybe time for a three horse race?
- TheOtherHobbes 11y agoAlpha was amazing, and the DEC chip people were best-in-the-world talented. If DEC had made some smarter choices about personal computing we might have had 10 or 20GHz desktops now. Otherwise, CPU design is almost the poster-child for technical debt. The problems are more social and economic than technical. Once an architecture dominates the market it's almost impossible to replace it with something better. The best hope is to do what ARM are doing and sneak up on the market sideways, starting from a segment with much less competition.
- Scaevolus 11y agoDEC would be able able to violate the laws of physics? The GHz barrier isn't caused by lack of talent, it's caused by basic thermal limits of silicon chips.
- faragon 11y agoThose CPUs look like having a huge potential, but there is no really working compiler for them. In my opinion, they could try to engage Fabrice Bellard, the genious behind QEMU and TCC. Or people with experience on Mali GPU architecture, which shares many points with the Mill CPU approach.
- TazeTSchnitzel 11y agoThey'll get there. They aren't burning through money, they don't have any: they're not a properly formed company, just volunteers. It'll get done when it gets done.
- Joky 11y agoCan you elaborate on the common point with the Mali? You may not know that Ivan has some compiler background, he is not really a newbie here! And the main problem right now is not a crappy compiler but no silicon...
- tormeh 11y agoI would fix the silicon problem last, if I were them. Once manufacturing begins, the company will be bleeding money and customers better not be waiting for something else before buying.
- Someone 11y agoAs to finding instruction boundaries with a variable-length instruction format: you could use the trick they use to start two instruction streams from a single address by using it for a stream of fixed-length instruction sizes running down that can be used to find the border in the stream of variable-length instructions running in the ’normal’ direction. You could have: offset : -----000000000111111 offset : 54321012345678901234 contents: 64212iijkkllllmmmmmm (digits are instruction lengths, letters are instructions) So, reading offsets -1, -2, -3, etc. you read off the sizes of the instructions you can read in offsets 1, 2, 3, etc. If you have 4 decode units, you can replace the sizes of the instructions by their offsets, resetting the offset every 4th instruction. With instruction sizes of 1-4 bytes, you could store instruction sizes in 2 bits per instruction. That would lower the pressure on your cache for the extra information you store. There also would be more space in your instruction set because you no longer would have to worry about creating an instruction that has a prefix that also is a valid instruction. For example, you could use 0x01 both for INC and ADD IMMEDIATE VALUE, where it means the former if the instruction length is 1, the latter if it is longer, with the size of the immediate determined by the size of the instruction. Would that be a net win? I wouldn’t know, but it seems simpler (but ’simpler’ looks like a negative in their worldview) than creating those two streams that somehow must work together to do what a single statement sequence in the source code does.
- igravious 11y agoI don't really understand your solution, but then again I did not understand the Mill's solution. Can you explain it again? All I will say is that they seem to have really tried to simplify and regularize the Mill _except_ in the opcode stream / decode step where they say that two streams is optimal! Seems like it would be a nightmare and introduce all sorts of complexities. Was the only bit of the talk I didn't grok, whereas most others bits had me nodding my head and thinking "oh, neat".
- mike_hearn 11y agoThe Mill is designed to be fast, not simple. The split streams is more complicated but increases speed (or lowers power draw I guess).
- luckydude 11y agoThe Mill CPU is going on and on as going to be awesome some day. I spoke with one their guys at Greg Chesson's wake, it seemed open ended. Yup, you have good ideas. How about you ship? Then we can see if the ideas meet reality and work. I'm friends with one the guys who did the P6. Which became the basis for pretty much any x86 chip. He shipped stuff. Ideas are easy, execution is hard, I have yet to see the Mill people execute. I'd be crazy happy if they stepped up and made me look stupid because they shipped a kick ass chip.
- javajosh 11y agoI know right? Even a crappy CPU based on the Mill concept would be good. You could at least perform computational efficiency (ops/watt) style benchmarks. I'm sort of curious what the endgame is, myself.
- uxcn 11y agoAs I understand, they aren't seeking venture capital backing, so progress is slow. I know they have (had) plans to implement a Mill on an FPGA, but even going to a usable ASIC will probably be a challenge. It's a major architectural change as well. Most existing systems rely on virtual memory, which the Mill doesn't support.
- adwn 11y ago> Most existing systems rely on virtual memory, which the Mill doesn't support. I believe you're mistaken. The Mill does support virtual memory; the main differences to most systems are that its caches use virtual addresses (the TLB is between the L2 cache and the DRAM), and that it's a single-address-space architecture.
- quux 11y agoI'm a little confused about how the "pointerness" of pointers is getting lost in LLVM. The mill can't be the only architecture that encodes extra data in the high bits of pointers right? The 64 bit objective-C runtime and Xbox 360 come to mind as systems where this is done. Clearly LLVM can generate good code 64 bit Objective-C... Am I missing something?