Início / user-625111

EnzoR's questions

Martin Hope
EnzoR
Asked: 2025-04-29 18:15:18 +0800 CST
  • 6

[RESOLVIDO] Use __sync_fetch_and_orem vez de __sync_or_and_fetch! A instrução double amoortalvez ainda seja um bug.

[Aviso] Isso pode ser um bug no GCC, mas ainda sou novo na montagem RISC-V, com certeza!

Estou tentando implementar uma função spinlock " rápidaasm() " em RISC-V (64 bits, por sinal) com C misto e usando compilação cruzada com GCC v14.2.0 e GCC 15.1.0. Este código (bem simplificado):

#define LOCK_BIT ((unsigned long)(1ul<<(8*sizeof(long)-1)))

void lock_hold(long* lock) {
  while(__sync_or_and_fetch(lock,LOCK_BIT) < 0);
  __sync_synchronize();
}

É renderizado por ambas as versões com -O3e -O2como:

lock_hold:
    li  a5,-1
    slli    a5,a5,63
.L2:
    amoor.d.aqrl    a4,a5,0(a0)
    amoor.d.aqrl    a4,a5,0(a0)
    j   .L2

que parece ser um loop infinito com 2 amoorinstruções idênticas consecutivas.

Primeiro, não estou esperando um loop infinito aí!

Se eu mudar para -O1, recebo este código:

lock_hold:
    li  a4,-1
    slli    a4,a4,63
.L2:
    amoor.d.aqrl    a5,a4,0(a0)
    or  a5,a5,a4.   #USELESS?
    blt a5,zero,.L2
    fence   rw,rw
    ret

que se parece mais com o que eu esperaria, enquanto -Osproduz este código:

lock_hold:
    li  a5,-1
    slli    a5,a5,63
.L2:
    amoor.d.aqrl    a4,a5,0(a0)
    j   .L2

novamente com um loop infinito.

Por fim, usando -O0obtenho basicamente o mesmo que -O1com algumas instruções extras.

Será que encontrei algum bug ou estou esquecendo de algo? O que estou esquecendo?

Além disso, gostaria de obter também uma resposta de " alguém que saiba muito mais do que eu ".

No código produzido por, -O1rotulei uma orinstrução como #USELESS?. Preciso mesmo executar alguma operação a5para definir o "sinalizador de sinal" após uma amoorinstrução que escreve sobre a5si mesma?

No caso, algo assim não or a5,zero,a5seria suficiente?

c
Martin Hope
EnzoR
Asked: 2025-04-08 01:40:43 +0800 CST
  • 8

Esta fonte C:

typedef struct {
  unsigned long one;
  unsigned long two;
} twin;

twin function( twin t ) {
  return (twin){ 0,0 };
}

gera esta montagem:

        .file   "p.c"
        .option nopic
        .attribute arch, "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0"
        .attribute unaligned_access, 0
        .attribute stack_align, 16
        .text
        .align  1
        .globl  function
        .type   function, @function
function:
        addi    sp,sp,-32  # <<< WHY?
        li      a0,0
        li      a1,0
        addi    sp,sp,32   # <<< WHY?
        jr      ra
        .size   function, .-function
        .ident  "GCC: (g04696df09) 14.2.0"
        .section        .note.GNU-stack,"",@progbits

quando executado riscv64-unknown-elf-gcc (g04696df09) 14.2.0com ou -O3ou -O2ou -O1mesmo -Os.

Então por que o código está criando espaço na pilha para coisas (32 bytes) que são e serão mantidas em registradores a0e a1?

Isso é um bug ou estou esquecendo de alguma coisa?

assembly