[Info-vax] Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign

[johnwallace4 at yahoo.co.uk]

On Friday, 5 January 2018 23:24:35 UTC, Craig A. Berry  wrote:
> On 1/5/18 4:41 PM, DaveFroble wrote:
> 
> > Now, as for Alpha, yes, OoO and such, but, the question would be, does 
> > it allow "illegal" access to memory?  If Alpha does not allow loading 
> > memory it should not into cache, then perhaps not a problem.
> 
> Alpha may not have any timer with precision sufficient to snoop the
> cache. This based on the fact that reducing timer precision is one of
> the mitigations in progress and that $GETTIM_PREC only came along in
> v8.3-1H1 and is Itanium only and even with that you only get time to the
> nearest 1ms, assuming I've understood this discussion correctly:
> 
> <http://h41379.www4.hpe.com/openvms/journal/v15/consistency_check.html>

Alpha had architected high precision timers long before they
were fashionable. Have a look at e.g. an Alpha Architecture
Handbook or other freely available document and look for 
info on e.g. the Processor Cycle Counter, and the RPCC 
instruction and its  close relative RSCC (Read Processor/System 
Cycle Counter). You should find text similar to this (apologies
for formatting here):
"The PCC register consists of two 32-bit fields. The low-order 32 bits (PCC<31:0>) are an unsigned, wrapping counter, PCC_CNT. The high-order 
32 bits (PCC<63:32>), PCC_OFF, are operating system dependent in their implementation.

PCC_CNT is the base clock register for measuring time intervals, and is suitable for timing intervals on the order of nanoseconds.

PCC_CNT increments once per N CPU cycles, where N is an implementation-specific
integer in the range 1..16. The cycle counter frequency is the number of times the processor cycle counter gets incremented per second. "


A Wizard answer (see below for extract) even referred to 
RPCC in 1999:
http://h41379.www4.hpe.com/wizard/wiz_2734.html

Whether these cycle counter things were or are accessible in any 
relevant way for the current nightmare is a differerent 
(and arguably not hugely relevant) question.

Alpha didn't get speculative execution/OoO until EV6/21264.

Alpha architecturally understands the difference between 
cacheable and non-cacheable items, as do (most of?) the 
better processors and code generation tools of recent 
decades, not just for Alpha (see e.g. various discussions 
of what "volatile" might mean to a compiler and its users).

OoO brings engineering risks as well as apparent benefits. 
To work well it needs to be architected well and
designed well, and properly tested. 

I've seen scenarios where that didn't apply, leading to 
Bad Things happening. In a "modern" IT environment it's 
easy for people to ignore these Bad Things e.g. by blaming 
the OS, or cheap hardware, etc, which may well be the
right analysis much of the time. But not necessarily 
always. 

In some environments (e.g. no OS involved) the
OS cannot be blamed, and that's where I've seen a 
speculative/OoO design go wrong. That example didn't 
even need memory management or cache - but they can 
add to the fun.

x86 doesn't have a documented architecture and 
behaviours or anything close to that. And it's
not known for running trustworthy OSes on 
trustworthy hardware. Misbehaviour is expected and inevitable and
largely ignored.

AMD64 appears to have a documented architecture 
and behaviours.

Alpha did/does have a documented architecture, and
implementations have documented behaviours (as did, 
fwiw, various PDP11s and similar - this isn't rocket
science).

Architecture, documentation, and *understanding* isn't 
a luxury if people really want stuff to behave properly.

Meanwhile, here's a bit of that answer from the Wizard,
just in case it falls off the HP website:

  The Alpha Architecture requires that Alpha systems implement process and
  system cycle counters, which can be useful in certain environments.
  (rpcc, rscc)  You will need to consult the Architecture manual for the
  format and use of the counter.
 
  An example of reading the process cycle counter (from C) follows:
 
#include [c_asm.h]
unsigned long cycles;
 
cycles = asm("rpcc %v0;"
             "sll  %v0, 32, %t1;"
             "addq %v0, %t1, %v0;"
             "srl  %v0, 32, %v0");
 
  Replace [ and ] with the equivilent angle brackets.
.................
Have a lot of fun.