Re: Another security vulnerability

EricP wrote:

Anton Ertl wrote:

EricP <ThatWouldBeTelling@thevillage.com> writes:

It doesn't need to eat opcode space if you only support one data type,
64-bit ints, and one address mode, [register].
Other address modes can be calculated using LEA.
Since these are rare instructions to solve a particular problem,
they won't be used that often, so a few extra instructions shouldn't matter.

 You lost me here.  Do you mean that a load with address mode
[register] is considered to be a non-address load and not followed by
the data-dependent prefetcher?  So how would an address load be
encoded if the natural expression would be [register]?
 - anton

I'm pointing out that not all instructions need to be orthogonal.
There can be savings in opcode space by tempering that based on
expected frequency of occurrence.

The normal LD and ST have all their address modes and data types
because these functions occur frequently enough that we deem it
worthwhile to support these all in one instruction,
such as supporting both sign and zero extended loads
or scaled index addressing.

I note there is this class of relatively rarely used special purpose
memory access instructions that don't need to have all singing and all
dancing address modes and/or data types like the regular LD and ST.

Since I need a LEA Load Effective Address instruction anyway
which does rBase+rIndex*scale+offset calculation
(plus I have others, like where rBase is RIP or an absolute address),
then I can drop all but the [reg] address mode for these rare instructions
and in many cases drop some sign or zero extend types for loads.

It seems to me that once the core has identified an address and an offset
from that address contains another address (foo->next, foo->prev) that only those are prefetched. So this depends on placing next as the first
container in a structure and remains dependent on chasing next a lot more
often than chasing prev.
Otherwise, knowing a loaded value contains a pointer to a structure (or array)
one cannot predict what to prefetch unless one can assume the offset into the
struct (or array).
Now Note:: If there were an instruction that loaded the value known to be
a pointer and prefetched based on the received pointer, then the prefetch
is now architectural not µArchitectural and you are allowed to damage the
cache or TLB when/after the instruction retires.

For example, I use just two opcodes for Atomic Fetch Add int64 and int32
   AFADD8 rDst,rSrc,[rAddr]
   AFADD4 rDst,rSrc,[rAddr]