search for: rv64

.../?p=libs/klibc/klibc.git;a=commit;h=f1c1f4f99e60ac0f855a0582b4aebebfbb0804dc Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Tue, 17 Jul 2018 02:55:19 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 18 Jan 2019 03:10:14 +0000 [klibc] Add RISC-V (RV64) port RISC-V is pretty boring. I've cribbed most of this from the MIPS and AArch64 ports. I ran into difficulty with initialisation of the gp,register, which I think has to be process-global - the psABI says that signal handlers can rely on it, and they could come from any module. This mean...

...wbacks or challenges to adding __int128_t support to GCC for RV32. Looking at Clang, it seems (by my reading) that Wasm32 is the only 32-bit target supporting __int128_t (though x86-64 with 32-bit ABI and Mips64 with 32-bit ABI also support it). Given that `long double` is 128 bits on both RV32 and RV64, __int128_t wouldn't be the only 128-bit type. Best, Alex

Hi all: I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem when adding soft float routine for rv32, RISC-V ABI required 128 bits bits for long double, but it's implemented by int128_t, however rv32 don't support __int128_t. Of cause, it not hard thing to support __int128_t by overriding TargetInfo::hasInt128Type for LLVM, but its will cause some ABI

...this release? > > There are also at least a couple of fairly important patches that it > would be good to get back-ported into the release branch if possible > > r352171 | asb | 2019-01-24 21:11:34 -0800 (Thu, 24 Jan 2019) | 12 lines > [RISCV] Custom-legalise i32 SDIV/UDIV/UREM on RV64M > > r352169 | asb | 2019-01-24 21:04:00 -0800 (Thu, 24 Jan 2019) | 24 lines > [RISCV] Custom-legalise 32-bit variable shifts on RV64 > > > Others that would be good, but perhaps not so important to get in: > > r352240 | asb | 2019-01-25 13:06:47 -0800 (Fri, 25 Jan 2019) | 7...

...ere, but if SV uses an immediate to define vscale, that implies the value of vscale is known at compile-time and thus regular (fixed-width) vector types can be used? > now, we mmmiiiight be able to get away with assuming that vscale is > equal to the absolute maximum possible setting (64 for RV64, 32 for > RV32), then use / play-with the "runtime active VL get/set" > intrinsics. > > i'm kiinda wary of saying "absolutely yes that's the way forward" for > us, particularly without some input from Jacob here. Note that there isn't a requirement to...

As previously discussed in an RFC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, the RISC-V backend has i64 as the only legal integer type for the RV64 target. Thanks to variable-sized register class support, this means there is no need for duplication of either patterns or instruction definitions for RV32 and RV64. It's worth noting that RV64I is a different base ISA to RV32I. Rather than adding 64-bit operations, it re-defines the operations...

...dded so the static analyzer skips yacc/bison-generated files. [r326135](http://reviews.llvm.org/rL326135). ## Other project commits * Initial PPC64 instruction emulation landed in LLDB. [r326224](http://reviews.llvm.org/rL326224). * Support was added for building compiler-rt for RISC-V RV32 and RV64. [r326420](http://reviews.llvm.org/rL326420). * lld now accepts both `--foo bar` and `--foo=bar` command line option styles. [r326506](http://reviews.llvm.org/rL326506).

...ther expanded backend docs, generated code quality improvements I've mapped out a number of TODO items here <https://github.com/lowRISC/riscv-llvm/issues>, which I hope can help to co-ordinate efforts. Where possible, this indicates the current preferred approach (e.g. we plan to provide RV64 support building upon Krzysztof's variable-sized register class work). I've submitted a RISC-V BoF session proposal for the upcoming LLVM Dev Meeting. If accepted, this should provide a great opportunity to further discuss and co-ordinate work between the multiple parties who have expressed...

Thanks @Robin and @Graham for giving some background on scalable vectors and clarifying some of the details! Apologies if I'm repeating things here, but it is probably good to emphasize the conceptually different, but complementary models for scalable vectors: 1. Vectors of unknown, but constant size throughout the program. 2. Vectors of changing size throughout the program. Where (2)

...o defaults [klibc] Install headers with consistent mode [klibc] dash: mkbuiltins: Fix sort order harder [klibc] gzip: Fix silent fallback to decompression [klibc] run-init: Add dry-run mode [klibc] rename, renameat: Use renameat2() system call [klibc] Add RISC-V (RV64) port [klibc] x86_64: Reduce ld max-page-size option again [klibc] Never clean files in quilt status directory [klibc] x86_64: Use -Ttext-segment to avoid address collision [klibc] i386: Use -Ttext-segment to avoid address collision [klibc] Disable PIE [klibc] Ma...

...nchez-beato (1): [klibc] Add support for reboot syscall argument Baptiste Jonglez (1): [klibc] nfsmount: support nfsvers= and vers= options Ben Hutchings (6): [klibc] run-init: Add dry-run mode [klibc] rename, renameat: Use renameat2() system call [klibc] Add RISC-V (RV64) port [klibc] x86_64: Reduce ld max-page-size option again [klibc] Never clean files in quilt status directory [klibc] x86_64: Use -Ttext-segment to avoid address collision Benjamin Drung (2): [klibc] ipconfig: Implement classless static routes [klibc] mount_main: Fix...

Dear testers, 8.0.0-rc1 was just tagged (from the branch at r351980). It took a little longer than planned, but it's looking good. Please run the test script, share your results, and upload binaries. I'll get the source tarballs and docs published as soon as possible, and binaries as they become available. Thanks, Hans

New architectures only define the renameat2() system call, which was added in Linux 3.15. Define rename() and renameat() as wrappers for it if necessary. Signed-off-by: Ben Hutchings <ben at decadent.org.uk> --- --- a/usr/klibc/Kbuild +++ b/usr/klibc/Kbuild @@ -59,7 +59,8 @@ klib-y += vsnprintf.o snprintf.o vsprint inet/inet_ntoa.o inet/inet_aton.o inet/inet_addr.o \

...gled with the standard 32-bit representations. The standard is structured to allow implementers to choose appropriate subsets to support, for instance a micro-controller might support 'RV32I' (32-bit RISC-V with the integer instructions) and an application core running Linux might implement RV64IMAFD (commonly shortened to RV64G: 64-bit with integer instructions, the multiply extension, atomics, and single and double precision floating point). A generous portion of the opcode space is left reserved for implementers or researchers to add their own instructions. In line with the proposed po...

...48fd40/riscv-spec.pdf>, which incorporates work from the Memory Consistency Model Task Group to define the memory model. RISC-V implements a weak memory model. For those not familiar, RISC-V is a modular ISA, with standard extensions indicated by single letters. Baseline 'RV32I' or 'RV64I' instruction sets don't support atomic operations beyond fences. However the RV32A and RV64A instruction set extensions introduce AMOs (Atomic Memory Operations) and LR/SC (load-linked/store-conditional on other architectures). 32-bit atomic operations are supported natively on RV32, and b...