An ARM killer from IIT-M?

Re:An ARM killer from IIT-M? by bonzini on Monday November 13, 2017 @04:04AM (#15685238)

That's what some people were doing with SuperH; I don't know how the project has progressed.

[If you wanted to resurrect the Alpha, though, please do not resurrect the crazy memory consistency semantics, where you need to put a full memory barrier between

    r0 = load(&x);
    r1 = load(r0);

[ Parent | on HN ]

Re:An ARM killer from IIT-M? by KMag on Monday November 13, 2017 @07:59PM (#15691711)

Do you have any pointers to good documentation on the Alpha memory semantics?

The memory semantics are of course so lax so that the processor doesn't need to check the computed addresses of all in-flight stores before issuing a concurrent memory operation. My understanding is that it's mostly a footgun for assembly programmers, but I'd love to see any estimates of the speed and power efficiency benefits of the lax memory semantics.

[ Parent | on HN ]

Re:An ARM killer from IIT-M? by gsmadhusudan on Tuesday November 14, 2017 @07:52AM (#15694554)

This is one of the raging debates within the RISC-V group and elsewhere. Is weak memory semantics really worth it or can x86 style TSO be implemented optimally.Lot of anecdotal evidence but no conclusive experiment. As part of our work we hope to try multiple memory models in our I-class and get some definitive answers.RISC-V by the way supports ARM/PPC style weak memory model or optionally an x86 style TSO.

[ Parent | on HN ]

Re:An ARM killer from IIT-M? by bonzini on Tuesday November 14, 2017 @05:15PM (#15699702)

ARM/PPC is fine, but Alpha took it too far in my opinion (and also didn't have a read memory barrier instruction---nowadays acquire and release memory barriers would probably be preferrable).

[ Parent | on HN ]

Re:An ARM killer from IIT-M? by wbl on Monday November 13, 2017 @10:34AM (#15687158)

How else will I be able to bank the lower-level cache for the absolute highest in performance?

[ Parent | on HN ]