Re: Computer architects leaving Intel...

Liste des GroupesRevenir à c arch 
Sujet : Re: Computer architects leaving Intel...
De : cr88192 (at) *nospam* gmail.com (BGB)
Groupes : comp.arch
Date : 20. Sep 2024, 03:09:35
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vciljc$q5fh$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
User-Agent : Mozilla Thunderbird
On 9/18/2024 1:42 PM, MitchAlsup1 wrote:
On Wed, 18 Sep 2024 17:55:34 +0000, BGB wrote:
 
On 9/18/2024 9:27 AM, MitchAlsup1 wrote:
On Wed, 18 Sep 2024 4:00:43 +0000, BGB wrote:
>
On 9/17/2024 6:04 PM, MitchAlsup1 wrote:
>
Still limited to 32-bit displacement from IP.
>
How would you perform the following call::
current IP = 0x0000000000001234
target  IP = 0x7FFFFFFF00001234
>
This is a single (2-word) instruction in my ISA, assuming GOT is
32-bit displaceable and 64-bit entries.
>
>
Granted, but in plain RISC-V, there is no real better option.
>
If one wants to generate 64-bit displacement, and doesn't want to load a
constant from memory:
   LUI X6, Disp20Hi       //20 bits
   ADDI X6, X6, Disp12Hi  //12 bits
   AUIPC X7, Disp20Lo
   ADD X7, Disp12Lo
   SLLI X6, X6, 32
   ADD X7, X7, X6
>
How very much simpler is::
>
     MEM    Rd,[IP,Ri<<s,DISP64]
>
1 instruction, 3 words, 1 decode cycle, no forwarding, shorter latency.
>
>
It is simpler, but N/E in RV64G...
>
This is the whole issue of the idea:
   Remain backwards compatible with RV64G / RV64GC (in a binary sense).
 So, you like sailing with an albatross tied around your neck:: Check.
 
Likely for a custom CPU to be taken all that seriously at this point, one is going to need binary compatibility with at least one semi-popular ISA.
And, main options at this point are:
   RISC-V, which is just kinda meh;
   ARMv7 / ARMv8, which are not free;
     And, v7/v8 are nowhere near patents expiring.
   x86-64, just no.
     Doable at least as far as x86-64 and SSE2 should be in the clear.
     But, making it not perform well seems harder.
Well, or MIPS64 or SPARC64 or similar, but these are arguably worse options than RISC-V.

*and* try to allow extending it in a way such that performance can be
less poor...
 I should remind you that if you eliminate the compressed parts of
RISC-V you can fit the entire My 66000 ISA in the space remaining.
All the constants, all transcendentals, all the far-control transfers,
the efficient context switching, overhead free world switching,...
---------
The idea is that the mode switching can allow swapping out the Compressed instructions to make room for other stuff, while also leaving the compressed instructions in existence for compatibility with binaries built assuming them.
And, is less drastic than gluing together two unrelated ISA's using inter-ISA branches (say, the current situation of trying to mix RISC-V code with XG2 via magic function pointers).
But, yeah, if you want to design a version of your ISA than can also co-execute with RISC-V, not like I have any reason to complain.

>
Which is sort of the whole reason I am considering hacking around it
with an alternate encoding scheme.
>
Just put in real constants.
>
New encoding scheme can in theory do:
   LEA X7, PC, Disp64
In a single 96-bit instruction.
>
Where is the indexing register?
>
Generally the use of a displacement and index register are mutually
exclusive (and, cases that can make use of Disp AND Index are much less
common than Disp OR Index).
        COMMON ?alpha/ a(100,100), b(300,300),
 ..
        x = a(i,j)*b(j,i);
 I see large displacements with indexing all the time from ASM out
of Brian's compiler.
 
I tried adding this stuff experimentally with BGBCC in the past, in both of my ISA efforts, but seemingly my attempts didn't use them all that often (as opposed to [Rb+Disp] and [Rb+Ri*FixSc] which are used extensively).
Arguably, the main relevant cases would have been for stack-arrays or arrays inside structs.
But, if such an array is referenced multiple times in a given basic block, it would likely still be more efficient to load the address of the array into a register.
Though, if one were to go simply on usage frequency, likely auto-increment would be slightly ahead.
Say (roughly from memory):
   [Rb+Disp]        // ~ 60% (includes PC and GBR)
   [Rb+Ri*FixSc]    // ~ 30% (eg: "ptr[i]")
   [Rb]+            // ~ 6% (eg: "*ptr++")
   [Rb+Ri*Sc+Disp]  // ~ 4% (eg: "obj->arr[i]")
Well, unless someone can find a table that shows significantly different stats. Off hand, not easily finding such a table to compare with (preferably from a relatively mature target which has the relevant modes).
Can note that "*ptr++" seems most common for auto-increment, whereas "*ptr--", "*--ptr", and "*++ptr" are rarer.
Seems like no one has made tables online for the relative usage frequencies of the various x86-64 and ARM64 addressing mode...
Might be useful to have this data for "relatively mature" architectures.
Would be a pain to write an x86-64 disassembler mostly to use it just to stat up the ModR/M+SIB sequences. Does raise the question of if there is a semi-reliable way to stat this without needing to write a full disassembler.
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 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...).
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.
As-is, I am trying to come up with something that could potentially be cheaper (both in resource cost and implementation complexity) than my existing BJX2 core (and that could maybe also be made to run Linux without significant porting effort), while still allowing for better performance than RISC-V by itself.
Any fundamentally new features added would need to be "low cost" in this scenario.

Date Sujet#  Auteur
27 Aug 24 * Computer architects leaving Intel...539Thomas Koenig
27 Aug 24 +- Re: Computer architects leaving Intel...1Michael S
27 Aug 24 +- Re: Computer architects leaving Intel...1Stephen Fuld
27 Aug 24 `* Re: Computer architects leaving Intel...536John Dallman
28 Aug 24  +* Re: Computer architects leaving Intel...529BGB
28 Aug 24  i`* Re: Computer architects leaving Intel...528MitchAlsup1
28 Aug 24  i `* Re: Computer architects leaving Intel...527BGB
28 Aug 24  i  +* Re: Computer architects leaving Intel...2Robert Finch
28 Aug 24  i  i`- Re: Computer architects leaving Intel...1BGB
28 Aug 24  i  `* Re: Computer architects leaving Intel...524MitchAlsup1
29 Aug 24  i   `* Re: Computer architects leaving Intel...523BGB
29 Aug 24  i    +* Re: Computer architects leaving Intel...511MitchAlsup1
29 Aug 24  i    i`* Re: Computer architects leaving Intel...510BGB
30 Aug 24  i    i +* Re: Computer architects leaving Intel...499John Dallman
30 Aug 24  i    i i+* Re: Computer architects leaving Intel...11Thomas Koenig
30 Aug 24  i    i ii+- Re: Computer architects leaving Intel...1Michael S
30 Aug 24  i    i ii+* Re: Computer architects leaving Intel...8Anton Ertl
30 Aug 24  i    i iii+* Re: Computer architects leaving Intel...2Michael S
30 Aug 24  i    i iiii`- Re: Computer architects leaving Intel...1Anton Ertl
30 Aug 24  i    i iii`* Re: Computer architects leaving Intel...5John Dallman
30 Aug 24  i    i iii `* Re: Computer architects leaving Intel...4Brett
30 Aug 24  i    i iii  +- Re: Computer architects leaving Intel...1John Dallman
2 Sep 24  i    i iii  `* Re: Computer architects leaving Intel...2Terje Mathisen
2 Sep 24  i    i iii   `- Re: Computer architects leaving Intel...1Thomas Koenig
30 Aug 24  i    i ii`- Re: Computer architects leaving Intel...1BGB
30 Aug 24  i    i i`* Re: Computer architects leaving Intel...487Anton Ertl
30 Aug 24  i    i i +* Re: Computer architects leaving Intel...302John Dallman
30 Aug 24  i    i i i`* Re: Computer architects leaving Intel...301David Brown
30 Aug 24  i    i i i +* Re: Computer architects leaving Intel...293Anton Ertl
30 Aug 24  i    i i i i`* Re: Computer architects leaving Intel...292Bernd Linsel
31 Aug 24  i    i i i i +- Re: Computer architects leaving Intel...1Thomas Koenig
31 Aug 24  i    i i i i `* Re: Computer architects leaving Intel...290Thomas Koenig
31 Aug 24  i    i i i i  +- Re: Computer architects leaving Intel...1Thomas Koenig
31 Aug 24  i    i i i i  `* Re: Computer architects leaving Intel...288Bernd Linsel
31 Aug 24  i    i i i i   +- Re: Computer architects leaving Intel...1Thomas Koenig
31 Aug 24  i    i i i i   +* Re: Computer architects leaving Intel...2Thomas Koenig
31 Aug 24  i    i i i i   i`- Re: Computer architects leaving Intel...1Bernd Linsel
31 Aug 24  i    i i i i   `* Re: Computer architects leaving Intel...284Anton Ertl
31 Aug 24  i    i i i i    +* Re: Computer architects leaving Intel...279Thomas Koenig
31 Aug 24  i    i i i i    i+* Re: Computer architects leaving Intel...157Bernd Linsel
31 Aug 24  i    i i i i    ii+* Re: Computer architects leaving Intel...153MitchAlsup1
1 Sep 24  i    i i i i    iii`* Re: Computer architects leaving Intel...152Stephen Fuld
2 Sep 24  i    i i i i    iii `* Re: Computer architects leaving Intel...151Terje Mathisen
2 Sep 24  i    i i i i    iii  `* Re: Computer architects leaving Intel...150Stephen Fuld
3 Sep 24  i    i i i i    iii   +* Re: Computer architects leaving Intel...139David Brown
3 Sep 24  i    i i i i    iii   i+* Re: Computer architects leaving Intel...108Stephen Fuld
4 Sep 24  i    i i i i    iii   ii`* Re: Computer architects leaving Intel...107David Brown
4 Sep 24  i    i i i i    iii   ii +* Re: Computer architects leaving Intel...103Terje Mathisen
4 Sep 24  i    i i i i    iii   ii i+* Re: Computer architects leaving Intel...101David Brown
4 Sep 24  i    i i i i    iii   ii ii+* Re: Computer architects leaving Intel...97jseigh
4 Sep 24  i    i i i i    iii   ii iii`* Re: Computer architects leaving Intel...96David Brown
4 Sep 24  i    i i i i    iii   ii iii `* Re: Computer architects leaving Intel...95Brett
4 Sep 24  i    i i i i    iii   ii iii  +- Re: Computer architects leaving Intel...1Thomas Koenig
4 Sep 24  i    i i i i    iii   ii iii  +- Re: Computer architects leaving Intel...1MitchAlsup1
5 Sep 24  i    i i i i    iii   ii iii  +* Re: Computer architects leaving Intel...8BGB
5 Sep 24  i    i i i i    iii   ii iii  i`* Re: Computer architects leaving Intel...7MitchAlsup1
5 Sep 24  i    i i i i    iii   ii iii  i `* Re: Computer architects leaving Intel...6David Brown
5 Sep 24  i    i i i i    iii   ii iii  i  `* Re: Computer architects leaving Intel...5Niklas Holsti
5 Sep 24  i    i i i i    iii   ii iii  i   `* Re: Computer architects leaving Intel...4David Brown
6 Sep 24  i    i i i i    iii   ii iii  i    `* Re: Computer architects leaving Intel...3BGB
6 Sep 24  i    i i i i    iii   ii iii  i     `* Re: Computer architects leaving Intel...2David Brown
9 Sep 24  i    i i i i    iii   ii iii  i      `- Re: Computer architects leaving Intel...1BGB
5 Sep 24  i    i i i i    iii   ii iii  +* Re: Computer architects leaving Intel...83David Brown
5 Sep 24  i    i i i i    iii   ii iii  i`* Re: Computer architects leaving Intel...82Terje Mathisen
5 Sep 24  i    i i i i    iii   ii iii  i +* Re: Computer architects leaving Intel...79David Brown
5 Sep 24  i    i i i i    iii   ii iii  i i+* Re: Computer architects leaving Intel...2Thomas Koenig
7 Sep 24  i    i i i i    iii   ii iii  i ii`- Re: Computer architects leaving Intel...1Tim Rentsch
5 Sep 24  i    i i i i    iii   ii iii  i i+* Re: Computer architects leaving Intel...74Terje Mathisen
5 Sep 24  i    i i i i    iii   ii iii  i ii+* Re: Computer architects leaving Intel...16David Brown
9 Sep 24  i    i i i i    iii   ii iii  i iii`* Re: Computer architects leaving Intel...15Terje Mathisen
9 Sep 24  i    i i i i    iii   ii iii  i iii +* Re: Computer architects leaving Intel...12David Brown
9 Sep 24  i    i i i i    iii   ii iii  i iii i`* Re: Computer architects leaving Intel...11Brett
10 Sep 24  i    i i i i    iii   ii iii  i iii i +* Re: Computer architects leaving Intel...5Terje Mathisen
10 Sep 24  i    i i i i    iii   ii iii  i iii i i`* Re: Computer architects leaving Intel...4Brett
10 Sep 24  i    i i i i    iii   ii iii  i iii i i +* Re: Computer architects leaving Intel...2Michael S
11 Sep 24  i    i i i i    iii   ii iii  i iii i i i`- Re: Computer architects leaving Intel...1Brett
11 Sep 24  i    i i i i    iii   ii iii  i iii i i `- Re: Computer architects leaving Intel...1Terje Mathisen
10 Sep 24  i    i i i i    iii   ii iii  i iii i `* Re: Computer architects leaving Intel...5David Brown
10 Sep 24  i    i i i i    iii   ii iii  i iii i  +* Re: Computer architects leaving Intel...3Anton Ertl
10 Sep 24  i    i i i i    iii   ii iii  i iii i  i`* Re: Computer architects leaving Intel...2David Brown
10 Sep 24  i    i i i i    iii   ii iii  i iii i  i `- Re: Computer architects leaving Intel...1Stefan Monnier
10 Sep 24  i    i i i i    iii   ii iii  i iii i  `- Re: Computer architects leaving Intel...1BGB
9 Sep 24  i    i i i i    iii   ii iii  i iii `* Re: Computer architects leaving Intel...2Michael S
10 Sep 24  i    i i i i    iii   ii iii  i iii  `- Re: Computer architects leaving Intel...1Michael S
5 Sep 24  i    i i i i    iii   ii iii  i ii+* Re: Computer architects leaving Intel...45Bernd Linsel
6 Sep 24  i    i i i i    iii   ii iii  i iii+- Re: Computer architects leaving Intel...1David Brown
9 Sep 24  i    i i i i    iii   ii iii  i iii+* Re: Computer architects leaving Intel...2Terje Mathisen
9 Sep 24  i    i i i i    iii   ii iii  i iiii`- Re: Computer architects leaving Intel...1Tim Rentsch
14 Sep 24  i    i i i i    iii   ii iii  i iii`* Re: Computer architects leaving Intel...41Kent Dickey
14 Sep 24  i    i i i i    iii   ii iii  i iii +* Re: Computer architects leaving Intel...32Anton Ertl
14 Sep 24  i    i i i i    iii   ii iii  i iii i+* Re: Computer architects leaving Intel...29MitchAlsup1
14 Sep 24  i    i i i i    iii   ii iii  i iii ii`* Re: Computer architects leaving Intel...28Thomas Koenig
15 Sep 24  i    i i i i    iii   ii iii  i iii ii `* Re: Computer architects leaving Intel...27David Brown
16 Sep 24  i    i i i i    iii   ii iii  i iii ii  +* Re: Computer architects leaving Intel...5Thomas Koenig
16 Sep 24  i    i i i i    iii   ii iii  i iii ii  i`* Re: Computer architects leaving Intel...4David Brown
16 Sep 24  i    i i i i    iii   ii iii  i iii ii  i `* Re: Computer architects leaving Intel...3Thomas Koenig
17 Sep 24  i    i i i i    iii   ii iii  i iii ii  i  +- Re: Upwards and downwards compatible, Computer architects leaving Intel...1John Levine
17 Sep 24  i    i i i i    iii   ii iii  i iii ii  i  `- Re: Computer architects leaving Intel...1David Brown
16 Sep 24  i    i i i i    iii   ii iii  i iii ii  `* Re: Computer architects leaving Intel...21Terje Mathisen
16 Sep 24  i    i i i i    iii   ii iii  i iii ii   `* Re: Computer architects leaving Intel...20David Brown
16 Sep 24  i    i i i i    iii   ii iii  i iii ii    +* Re: Computer architects leaving Intel...14Michael S
17 Sep 24  i    i i i i    iii   ii iii  i iii ii    `* Re: Computer architects leaving Intel...5Terje Mathisen
15 Sep 24  i    i i i i    iii   ii iii  i iii i`* Re: Computer architects leaving Intel...2BGB
14 Sep 24  i    i i i i    iii   ii iii  i iii +* Re: Computer architects leaving Intel...3Thomas Koenig
16 Sep 24  i    i i i i    iii   ii iii  i iii `* Re: Computer architects leaving Intel...5Tim Rentsch
6 Sep 24  i    i i i i    iii   ii iii  i ii+* Re: Computer architects leaving Intel...3Tim Rentsch
7 Sep 24  i    i i i i    iii   ii iii  i ii`* Re: Computer architects leaving Intel...9Chris M. Thomasson
5 Sep 24  i    i i i i    iii   ii iii  i i`* Re: Computer architects leaving Intel...2MitchAlsup1
5 Sep 24  i    i i i i    iii   ii iii  i `* Re: Computer architects leaving Intel...2MitchAlsup1
7 Sep 24  i    i i i i    iii   ii iii  `- Re: Computer architects leaving Intel...1Tim Rentsch
4 Sep 24  i    i i i i    iii   ii ii`* Re: Computer architects leaving Intel...3Thomas Koenig
6 Sep 24  i    i i i i    iii   ii i`- Re: Computer architects leaving Intel...1Chris M. Thomasson
4 Sep 24  i    i i i i    iii   ii +- Re: Computer architects leaving Intel...1jseigh
13 Sep 24  i    i i i i    iii   ii `* Re: Computer architects leaving Intel...2Stephen Fuld
3 Sep 24  i    i i i i    iii   i`* Re: Computer architects leaving Intel...30Stefan Monnier
3 Sep 24  i    i i i i    iii   `* Re: Computer architects leaving Intel...10Terje Mathisen
31 Aug 24  i    i i i i    ii`* Re: Computer architects leaving Intel...3Thomas Koenig
1 Sep 24  i    i i i i    i`* Re: Computer architects leaving Intel...121David Brown
1 Sep 24  i    i i i i    +* Re: Computer architects leaving Intel...3John Dallman
3 Sep 24  i    i i i i    `- Re: Computer architects leaving Intel...1Stefan Monnier
30 Aug 24  i    i i i +- Re: Computer architects leaving Intel...1MitchAlsup1
30 Aug 24  i    i i i +* Re: Computer architects leaving Intel...4Stefan Monnier
30 Aug 24  i    i i i `* Re: Computer architects leaving Intel...2John Dallman
8 Sep 24  i    i i `* Re: Computer architects leaving Intel...184Tim Rentsch
30 Aug 24  i    i `* Re: Computer architects leaving Intel...10MitchAlsup1
31 Aug 24  i    `* Re: Computer architects leaving Intel...11Paul A. Clayton
29 Aug 24  `* Re: Computer architects leaving Intel...6Anton Ertl

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal