Really, you will find the Encoding talk informative. Have you watched it?embryo wrote:Why a pipeline, for example, can not deliver unpacked instructions? In case of branches there can be more than one pipeline. And caches today are relatively big, tenth of kilobytes for the fastest. Also, if the cache is so important, then why not to extend it?
The Mill: a new low-power, high-performance CPU design
-
- Member
- Posts: 96
- Joined: Sat Mar 15, 2014 3:49 pm
Re: The Mill: a new low-power, high-performance CPU design
Re: The Mill: a new low-power, high-performance CPU design
Yes, I have. But there is no clear answer.willedwards wrote:Really, you will find the Encoding talk informative. Have you watched it?
Re: The Mill: a new low-power, high-performance CPU design
instead of VLIW you might want to look into FPGA's
Re: The Mill: a new low-power, high-performance CPU design
Right, people designing a CPU specifically to maximize instruction throughput using multiple breakthroughs didn't push it to the limit where it would require another breakthrough. Also, people designing CPUs have no idea what FPGAs are.
Re: The Mill: a new low-power, high-performance CPU design
Is there an FPGA based processor with the architecture like VLIW?argus wrote:instead of VLIW you might want to look into FPGA's
Re: The Mill: a new low-power, high-performance CPU design
What I meant was that aFPGA is a lot like a VLIW where you have your entire program in one instruction running in an infinite loop.
-
- Member
- Posts: 96
- Joined: Sat Mar 15, 2014 3:49 pm
Re: The Mill: a new low-power, high-performance CPU design
The new Security talk has now been posted online: http://millcomputing.com/topic/security/
There's a lot in there for kernel architects to get their teeth into
There's a lot in there for kernel architects to get their teeth into
Re: The Mill: a new low-power, high-performance CPU design
Just finished the talk. I like it- especially the lack of privileged operations and supervisor mode. It removes a lot of the divisions between monolithic, micro, exo, etc. Feels like call gates and hardware tasks done right.
Some questions about a few fixed-size things. Stacks will often need to be bigger than one segment/stacklet. There may also be more processes/threads than available turf/thread ids- Linux's pid_t is 32 bits for example. How would these things be handled?
Stacklets could just be entry points that switch to the real stack I guess. How would that work, since call/return seems to be the only (user-available) way to mess with the stack pointer? This also goes with a question I asked on the Mill forums about continuations/coroutines.
Some questions about a few fixed-size things. Stacks will often need to be bigger than one segment/stacklet. There may also be more processes/threads than available turf/thread ids- Linux's pid_t is 32 bits for example. How would these things be handled?
Stacklets could just be entry points that switch to the real stack I guess. How would that work, since call/return seems to be the only (user-available) way to mess with the stack pointer? This also goes with a question I asked on the Mill forums about continuations/coroutines.
-
- Member
- Posts: 595
- Joined: Mon Jul 05, 2010 4:15 pm
Re: The Mill: a new low-power, high-performance CPU design
Thank you for finally decoupling the translation from the security. I've previously written a few posts here where I've expressed some hesitation about paging and I think the Mill is in the right direction when it comes to this. Now we have a new CPU where we can try out new operating system security models and not forced into one.