Excerpts from Matheus Castanho's message of May 14, 2020 6:55 am: > Hi Nicholas, > > Small comment below: > > On 4/30/20 1:02 AM, Nicholas Piggin wrote: >> Add support for the scv instruction on POWER9 and later CPUs. >> >> For now this implements the zeroth scv vector 'scv 0', as identical >> to 'sc' system calls, with the exception that lr is not preserved, and >> it is 64-bit only. There may yet be changes made to this ABI, so it's >> for testing only. >> >> rfscv is implemented to return from scv type system calls. It can not >> be used to return from sc system calls because those are defined to >> preserve lr. >> >> In a comparison of getpid syscall, the test program had scv taking >> about 3 more cycles in user mode (92 vs 89 for sc), due to lr handling. >> getpid syscall throughput on POWER9 is improved by 33%, mostly due to >> reducing mtmsr and mtspr. >> >> Signed-off-by: Nicholas Piggin <npig...@gmail.com> >> --- >> Documentation/powerpc/syscall64-abi.rst | 42 ++++-- > > [...] > >> +Return value >> +------------ >> +- For the sc instruction, both a return value and a return error code are >> + returned. cr0.SO is the return error code, and r3 is the return value or >> + error code. When cr0.SO is clear, the syscall succeeded and r3 is the >> return >> + value. When cr0.SO is set, the syscall failed and r3 is the error code >> that >> + generally corresponds to errno. >> + >> +- For the scv 0 instruction, there is a return value indicates failure if it >> + is >= -MAX_ERRNO (-4095) as an unsigned comparison, in which case it is >> the >> + negated return error code. Otherwise it is the successful return value. > > I believe this last paragraph is a bit confusing (didn't quite get the > unsigned comparison with negative values). So instead of cr0.SO to > indicate failure, scv returns the negated error code, and positive in > case of success?
Yes, it will be like other major architectures and return values from -4095..-1 indicate an error with error value equal to -return value. I will try to make it a bit clearer. Thanks, Nick