Re: Ada case-statement

["Dan'l Miller" <optikos@verizon.net>]

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.  

https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing

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.”

Mill will succeed or fail on how well Mill makes astronomically-nondeterministic DRAM accesses to L1 cache, L2 cache, L3 cache, Rambus-esque serial-bus DRAM banks, and DDR-family parallel-bus DRAM banks all look deterministic to compilers trying to fill (at compile-time!) 30-subinstruction-wide instructions by figuring out (months or years a priori!) which subthread activities are ready to go whenever a datum-not-in-a-register is needed.  The problem could be solvable with an immense amount of registers.  Imagine the processor as a nano-mainframe:  load up batch-esque processing in registers, let 'er rip while predicting (all of!) the memory accesses for the next batch of processing long in advance.  If Mill fails to solve this problem, then Mill's fate is the same as Itanium's, and for precisely the same reason/fundamental-flaw.

Btw, VLIW DSPs don't have this problem, because they work on highly-predictable realtime information flows to perform a rather few highly-repetitive mathematical operations (hence leveraging the batch-processing analogy)—not general-purpose computing.  Software on VLIW DSPs actually can accurately predict precisely which memory/comm-channel data-arrival rates are needed to never cause a stall.