Brett (ggtgp.delete@this.yahoo.com) on April 7, 2018 8:45 pm wrote:
[snip]
> So why the wait if not for Apple’s new fifth generation CPU architecture?
>
> I rate the chances of ARM64 in a Mac at zero, history says it will be something new.
>
> Apple desktops/laptops
> 1. 1976 the 6502
> 2. 1984 the 68000
> 3. 1994 PowerPC
> 4. 2006 x86 Macs
> 5. 2019 Fifth generation architecture
>
> iPhones
> 1. 2007 ARM32 iPhone
> 2. 2010 Apple A4 32bit
Not an ISA change
> 3. 2013 Apple A7 64bit
ARMv7 still supported in hardware (i.e., more an ISA extension)
> 4. 2019 Fifth generation architecture

I think it would be far more reasonable for Apple to mandate a software distribution format which provides enough information to be compiled to run decently on "any" hardware. Ideally, the distribution format would also facilitate compilation specifically for resource availability (and perhaps even use model) to provide more efficient operation and better user-interaction. With such an abstraction, somewhat radical hardware designs could be shipped, getting real-world feedback on strengths and weaknesses.

Apple-specific extensions to AArch64 could provide some benefits. Threading and transactional memory support would be obvious extensions. Providing stack pre-zeroing and hardware-assist for zero page allocation might be helpful. Better integration of accelerators might also be beneficial without requiring a new application ISA. New microarchitectural optimization opportunities exist and uncore design seems to have abundant opportunity for optimization. With significant control of the software stack, glass jaws can be present (but never encountered) and use of enhancements can be greater than when depending on application developers to use specific compiler switches and targeting specific implementations. Software optimizations which depend on data alignment and organization are difficult to use with generic memory allocation; cooperation among hardware, system software, and application software seems likely to facilitate optimization.

A novel ISA (or ISAs given that Apple supports systems with significantly different performance and workload targets) would require significant research. Conventional ISAs give little attention to pipelining. (The delay slots of MIPS and the "front end registers" of PowerPC and Itanium are exceptions.) With implementation-specific compilation, greater exposure of pipeline features is practical. Similarly, conventional ISAs hide execution width and other implementation details. Conventional ISAs generally do not provide information about intra-core and intercore communication and storage behavior. Generic interfaces facilitate some changes behind the interface and provide some isolation of concerns (reducing the amount of communication required for implementation), but such also hinders or prevents fence-crossing optimization.

(Some optimizations can be performed dynamically, but this adds overhead in performing such optimizations. Note, compile-time optimization does not exclude hardware dynamic optimization or even dynamic software optimization.)

We know a lot of the basics, but whole system design seems to be still a research topic. I would expect a new high performance general-purpose core interface to expose some aspects of the pipeline (helping in managing delay between stages), some aspects of configurability (for trading off single-thread performance, throughput, power, performance and side channel isolation, etc.), some aspects of storage organization (partitioning, hierarchy, etc.), some aspects of communication and sharing among threads, and some aspects of highly synchronized parallel execution ("single thread" parallel execution; tight synchronization among more than one instruction stream would be possible within certain constraints). What information should be communicated by software (and what by non-core hardware) is not obvious to me (the general types, yes, but how much and what specifically, no). Encoding the information is another issue (particularly since information's timeliness, mutability, and value and significance [e.g., efficiency and correctness] is not uniform). I suspect some information should be inline (at least at cache block granularity) with primary information, some near-line (e.g., DRAM row granularity) to facilitate low-overhead retrieval but facilitate choice of not fetching extra information, and some using separate channels (providing a potential bandwidth benefit along with near-line benefits if the address is quickly determined). I also suspect that the order of information within a fetch/cache block would be significant, facilitating modestly earlier availability of more timing-critical information, assuming that communication channels will be narrower than block size.

Development of system software (OS, libraries, compiler, etc.) in cooperation with hardware development (and vice versa) would be required (and difficult). Even software developers who are highly trained in optimization are biased by costs on existing hardware and usually not familiar with the interaction of tradeoffs in detailed theory (hardware developers have similar underinformed biases).

The research and development effort for a novel ISA seems likely to require at least five years. An ISA just a little better than AArch64 is probably not worth much effort even with the declining rate of manufacturing process improvement. Many optimizations can be attached to the basic AArch64 framework.