Liste des Groupes | Revenir à c arch |
On 9/18/2024 1:42 PM, MitchAlsup1 wrote:No, the simple option is that an instruction looks like:
>
One simple option would be to assume an instruction looks like:
[Prefix Bytes]
[REX byte]
OP_Byte | 0F+OP_Byte
Mod/RM + SIB + ...
And then use a heuristic to try to guess how to interpret theMyopathy is NEAR SIGHTEDNESS.
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...).
Can also note that a worthwhile design goal is to not add significant486 showed that "[Rbase+Rindex<<scale+displacement]:segment" could all
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.
Les messages affichés proviennent d'usenet.