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 X-Received: by 10.36.101.12 with SMTP id u12mr2723473itb.30.1521116474071; Thu, 15 Mar 2018 05:21:14 -0700 (PDT) X-Received: by 10.157.1.9 with SMTP id 9mr434935otu.8.1521116473959; Thu, 15 Mar 2018 05:21:13 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!peer01.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!r195-v6no832310itc.0!news-out.google.com!a25-v6ni1590itj.0!nntp.google.com!e10-v6no834087itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 15 Mar 2018 05:21:13 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <365d65ea-5f4b-4b6a-be9b-1bba146394ab@googlegroups.com> <76eeca56-3246-49d2-baf3-0879741e7e12@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <66524f57-b182-45ca-aa86-91b033f4fbef@googlegroups.com> Subject: Re: Ada case-statement From: "Dan'l Miller" Injection-Date: Thu, 15 Mar 2018 12:21:14 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 1686492026 X-Received-Bytes: 4371 Xref: reader02.eternal-september.org comp.lang.ada:50994 Date: 2018-03-15T05:21:13-07:00 List-Id: 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= =20 > execute up to five conditional jumps in _parallel_, in each CPU cycle...= =20 > brings a whole new set of possibilities for case-statement codde :-) >=20 > https://millcomputing.com/docs/switches/ >=20 > BTW, the Mill architecture would be good at running Ada programs: very=20 > good at controlling the handling arithmetic errors, also good at=20 > subprogram calling, threading, emphasis on security (octet-granularity=20 > memory protection), etc. As a statically scehduled processor, it _could_= =20 > also be the only hope left for a powerful architecture with somewhat=20 > deterministic execution timing, for use in critical real-time systems,=20 > although the Mill developers currently do not describe it as a real-time= =20 > processor. Hmmmmmm. At 30 subinstructions per wide-issue and the DSP-like belt/bypass= , Mill is apparently a VLIW DSP retort to Itanium. =20 https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing Your goal of deterministic execution timing is eroded by the aspect of Itan= ium that most-singlehandedly undermined the entire multibillion-dollar EPIC= /Itanium effort more than any other aspect: =E2=80=9C=E2=80=A2 Load responses from a memory hierarchy which includes CP= U caches and DRAM do not have a deterministic delay. This makes static sche= duling of load instructions by the compiler very difficult.=E2=80=9D Mill will succeed or fail on how well Mill makes astronomically-nondetermin= istic DRAM accesses to L1 cache, L2 cache, L3 cache, Rambus-esque serial-bu= s DRAM banks, and DDR-family parallel-bus DRAM banks all look deterministic= to compilers trying to fill (at compile-time!) 30-subinstruction-wide inst= ructions by figuring out (months or years a priori!) which subthread activi= ties are ready to go whenever a datum-not-in-a-register is needed. The pro= blem could be solvable with an immense amount of registers. Imagine the pr= ocessor as a nano-mainframe: load up batch-esque processing in registers, = let 'er rip while predicting (all of!) the memory accesses for the next bat= ch of processing long in advance. If Mill fails to solve this problem, the= n Mill's fate is the same as Itanium's, and for precisely the same reason/f= undamental-flaw. Btw, VLIW DSPs don't have this problem, because they work on highly-predict= able realtime information flows to perform a rather few highly-repetitive m= athematical operations (hence leveraging the batch-processing analogy)=E2= =80=94not general-purpose computing. Software on VLIW DSPs actually can ac= curately predict precisely which memory/comm-channel data-arrival rates are= needed to never cause a stall.