[HN Gopher] What's new for RISC-V in LLVM 16
       ___________________________________________________________________
        
       What's new for RISC-V in LLVM 16
        
       Author : zdw
       Score  : 71 points
       Date   : 2023-03-19 03:44 UTC (19 hours ago)
        
 (HTM) web link (muxup.com)
 (TXT) w3m dump (muxup.com)
        
       | cdcarter wrote:
       | I've been slowly working through the Stephen Mraz "Build a RISC-V
       | OS In Rust" project to familiarize myself with RISC-V and it's
       | been a pretty enlightening experience.
       | 
       | One issue that I've run into though, which is also noticeable in
       | this article, is that a lot of things like ISA extensions are
       | specified in either repos that don't show a diff vs the main
       | spec, or are just inline in the massive PDF. What's the point of
       | linking specifically to the "Ztso" extension if it's just going
       | to download the main ISA specification.
       | 
       | Wasm faces a similar issue, with lots of fork repos for
       | extensions that don't at all outline how the extension operates
       | or changes the core.
       | 
       | It makes me long for "HTML (single page)" in the GNU tradition.
        
         | asb wrote:
         | Yes, linking to specific specifications can be a pain once
         | they've been added to the main ISA doc. Perhaps I'd be better
         | off linking to the raw .tex, but that's not always particularly
         | readable or as I think you suggest, not bother linking at all
         | if the link isn't directly to the mentioned extension.
        
       | snvzz wrote:
       | It's great to see that support for the most important ISA is
       | getting good.
        
         | azinman2 wrote:
         | Most important for who? Basically the winner if the western
         | toolchains support RISC-V will be China.
        
       | andrekandre wrote:
       | > The ISA spec includes commentary on this decision (page 23),
       | noting some disadvantages of adding such instructions to the
       | specification and noting microarchitectural techniques exist to
       | convert short forward branches into predicated code internally.
       | In the case of the SiFive 7 series, this is achieved using macro-
       | op fusion where a branch over a single ALU instruction is fused
       | and executed as a single conditional instruction.
       | 
       | i wonder how far can macro-op fusion be taken?
       | 
       | would it be possible to implement something like push/pop all
       | registers where the hardware decoder gobbles up several
       | consecutive load (or store) instructions and executes an
       | (accelerated) batch under the covers?
       | 
       | (maybe thats a trick they already do i suppose....)
        
         | Veliladon wrote:
         | It probably already does that. It probably goes even further.
         | 
         | Intel CPUs since the Core uarch have a stack engine. This
         | basically does the addition or subtraction of the stack pointer
         | in a special piece of hardware straight after the decode stage.
         | It can also do this multiple times per clock. The result after
         | decode is that each PUSH/POP/PUSHQ/POPQ will decode down to a
         | single uop. Combined with multiple decoding pipes and a
         | superscaler load/store unit the CPU basically packs a stream of
         | PUSH(Q)/POP(Q) instructions into a tight little ball of uops
         | which are executed at lightning speed. On Alder Lake for
         | instance it can do 3 loads and 4 stores per clock.
         | 
         | This is also faster than putting an instruction like PUSHA/POPA
         | through a uarch decoder so nobody uses those instructions
         | anymore. They're not even available in the x64 ISA. As shown,
         | modern CPUs are so good at decoding a stream of individual
         | PUSH(Q)/POP(Q) instructions there's literally no point.
        
         | [deleted]
        
       | jeffbee wrote:
       | What does it mean for LLVM to support Zawrs? The feature is
       | similar to x86 UMWAIT. To exploit UMWAIT I have to insert
       | assembly code. Are there higher-level language constructs that
       | can trigger these features? If not, what does LLVM support mean?
       | Only that the compiler backend can see the instruction without
       | freaking out?
        
         | asb wrote:
         | Yes, just that it will assemble the instructions. I was double
         | checking as I was sure I'd qualified this when appropriate with
         | "assembler/disassembler" but it seems I didn't - apologies.
         | I'll tweak the wording to make this clearer. (EDIT: fixed).
        
       ___________________________________________________________________
       (page generated 2023-03-19 23:02 UTC)