From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Mill processor (Was: Re: Ada case-statement) Date: Thu, 15 Mar 2018 19:22:26 +0200 Organization: Tidorum Ltd Message-ID: References: <365d65ea-5f4b-4b6a-be9b-1bba146394ab@googlegroups.com> <76eeca56-3246-49d2-baf3-0879741e7e12@googlegroups.com> <66524f57-b182-45ca-aa86-91b033f4fbef@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net moVvqoaOGw975gp9ZRrX7wzBNjCw6mp6R2EjtgpCZ7N4r+DC0V Cancel-Lock: sha1:j2bZg3P/VFCcRSTcIIvmoys+qU8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <66524f57-b182-45ca-aa86-91b033f4fbef@googlegroups.com> Xref: reader02.eternal-september.org comp.lang.ada:51000 Date: 2018-03-15T19:22:26+02:00 List-Id: On 18-03-15 14:21 , Dan'l Miller wrote: > On Thursday, March 15, 2018 at 2:56:55 AM UTC-5, Niklas Holsti > wrote: >> And soon we will have processors with the "Mill" architecture, >> which can execute up to five conditional jumps in _parallel_, in >> each CPU cycle... brings a whole new set of possibilities for >> case-statement codde :-) >> >> https://millcomputing.com/docs/switches/ >> >> BTW, the Mill architecture would be good at running Ada programs: >> very good at controlling the handling arithmetic errors, also good >> at subprogram calling, threading, emphasis on security >> (octet-granularity memory protection), etc. As a statically >> scehduled processor, it _could_ also be the only hope left for a >> powerful architecture with somewhat deterministic execution timing, >> for use in critical real-time systems, although the Mill developers >> currently do not describe it as a real-time processor. > > Hmmmmmm. At 30 subinstructions per wide-issue and the DSP-like > belt/bypass, Mill is apparently a VLIW DSP retort to Itanium. If you dive deeper into the Mill, you will see that the designers are very well aware of the VLIW, DSP, and Itanium predecessors, and aim to avoid their mistakes and draw-backs. Their general claim is that the Mill architecture delivers DSP-like MIPS/Watt for general (not necessarily DSP-like) applications. > Your goal of deterministic execution timing is eroded by the aspect > of Itanium that most-singlehandedly undermined the entire > multibillion-dollar EPIC/Itanium effort more than any other aspect: > > “• Load responses from a memory hierarchy which includes CPU caches > and DRAM do not have a deterministic delay. This makes static > scheduling of load instructions by the compiler very difficult.” The Mill load instructions have novel means to combat this effect: https://millcomputing.com/docs/#memory The Mill also has a scratchpad memory for local storage, avoiding some memory accesses. Cache behaviour (miss/hit/unknown classification, worst-case access times) is one aspect of complex processors that _can_ be analysed statically, although with some approximation. Works well for instruction caches, less well for data caches -- depending on the program to be analysed, of course. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .