Re: Computer architects leaving Intel...

On 9/20/2024 3:34 PM, MitchAlsup1 wrote:

On Fri, 20 Sep 2024 2:09:35 +0000, BGB wrote:
 

On 9/18/2024 1:42 PM, MitchAlsup1 wrote:
>
One simple option would be to assume an instruction looks like:
   [Prefix Bytes]
   [REX byte]
   OP_Byte | 0F+OP_Byte
   Mod/RM + SIB + ...

 No, the simple option is that an instruction looks like:
      +------+-----+-----+----------------+
     | major| Rd  | Rs1 | imm16          |
     +------+-----+-----+----------------+
     | mem  | Rd  | Rb  | disp16         |
     +------+-----+-----+----------------+
     | Bcnd | cnd | Rs1 | disp18         |
     +------+-----+-----+----------------+
     | 2OP  | Rd  | Rs1 |mods| 2op | Rs2 |
     +------+-----+-----+----------------+
     | 3OP  | Rd  | Rs1 | Rs3 | 3op| Rs2 |
     +------+-----+-----+----------------+
 

?...
This wasn't for a hardware decoder, but rather for a quick/dirty tool to try to get x86-64 ModR/M usage statistics from an EXE (without needing to write a full disassembler).
So, ended up mostly having some functions which gathered information by walking byte arrays and using big "switch()" blocks (built using the opcode maps from the Intel docs). The goal being "hopefully close enough" that the stats are valid.
Oddly, the stats I was getting looked like something that would more judtify the RISC-V position (highly prioritizing [Reg+Disp] ...).
Initially, it looked like [Rb+Ri*Sc+Disp] was dominant, but once I added a check to count it as [Rb+Disp] if Ri is rSP, nearly all of this went to [Rb+Disp].
I suspect mostly because this case is used to encode [rSP+Disp].
There was also the difference of [Abs32] (x86) vs [rIP+Disp32] (x86-64), but this didn't really change much.

And then use a heuristic to try to guess how to interpret the
instruction stream based on "looks better" (more likely to be aligned
with the instruction stream vs random unaligned garbage).
>
Though, such a "looks good" heuristic could itself risk skewing the
results.
>
>

I may still consider defining an encoding for this, but not yet. It is
in a similar boat as auto-increment. Both add resource cost with
relatively little benefit in terms of overall performance.
Auto-increment because if one has superscalar, the increment can usually
be co-executed. And, full [Rb+Ri*Sc+Disp], because it is just too
infrequent to really justify the extra cost of a 3-way adder even if
limited mostly to the low-order bits...

>
Myopathy--look it up.

>
>
OK.
>
Not sure how that is related (a medical condition involving muscle
defects...).

 Myopathy is NEAR SIGHTEDNESS.
 

That is called Myopia.
Apparently there is also "Myopic Apathy" as a condition effecting business management leading to them prioritizing near term stock prices over the long term viability of the business.

You are not looking far enough into the future to avoid problems in your
ISA and architecture. {I did the same in my youth. almost everyone
does.}
 

Can also note that a worthwhile design goal is to not add significant
cost over what would be needed for a plain RV64GC implementation, but,
could define a [Rb+Ri*Sc+Disp] encoding or similar if it would likely be
beneficial enough to justify its existence.

 486 showed that "[Rbase+Rindex<<scale+displacement]:segment" could all
be performed in a single cycle at a frequency competitive with the RISC
processors available at the time.

I decided to re-enable the paths in my compiler, and hack stuff to get it to compile, while adding stats (for static instruction-form usage).
But, thus far it is seemingly only ~ 0.3%...
Granted, it is currently only matching a few patterns:
   arr[idx+imm]
   obj->arr[idx]
Might make sense to try matching SP-relative array loads, ...
At present, auto-increment is at ~ 0.01%, but this is likely because there are not currently any code generation paths leading here...
But, it is curious, it appears as if (Rb, Ri) addressing might be being used more often in BGBCC than in other contexts.
Well, and/or because there may be a lower relative amount of SP-relative memory access.
I did realize that to be able to make much use of the new ISA design idea, a prerequisite would be to get RV64 code generation working in BGBCC.
This has suddenly gained a bit more priority.
Most of the work here is reworking stuff to be able to deal with the ABI differences.
...