Add explicit RISC-V scalar fallback support#13
Open
carlosqwqqwq wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Turbo-Run-Length-Encodingalready has a generic scalar implementation, butriscv64was still only covered implicitly and could fall back to host-oriented assumptions in two places:makefiledid not recognizeriscv64/riscv32, so cross builds could still inherit x86-oriented defaults such as-march=nativeand-mssse3;include_/conf.hrelied on architecture checks that, under a forced-RISC-V validation build on MinGW, could still be short-circuited by host macros before reaching a RISC-V-safe unaligned-access path.In addition, a few write sites assumed helpers like
ctou16/ctou32were lvalues, which does not hold once the RISC-V path uses memcpy-style accessors.This patch makes the existing scalar path explicit and verifiable for RISC-V without adding RVV intrinsics or changing the current x86 / ARM optimized paths.
What changed
makefile:riscv64/riscv32from the compiler name;-march=nativeand-mssse3for RISC-V targets.include_/conf.h:ctou16/32/64,ctof32/64,stou8/16/32/64,stof32/64, andltou32/64;__riscv_xlen == 64as a 64-bit target for__WORDSIZE.include_/time_.h:_WIN32-specific assumptions.trle_.h:ctou16/ctou32as lvalues withstou16/stou32.trled.c:stou32/stou64/T2(stou, USIZE)so the scalar RISC-V path remains valid.README.md:riscv64currently uses the scalar fallback path.Verification
gmakeriscv64dry-run successfully:gmake -n ARCH=riscv64 CC=riscv64-linux-gnu-gccriscv64dry-run:-march=native;-mssse3.conf.h:gcc -E -dM -D__riscv=1 -D__riscv_xlen=64 -U__x86_64__ -U__amd64__ -U__aarch64__ -U__ARM_NEON -U__AVX2__ -U__AVX__ -U__SSE4_1__ -U__SSSE3__ -U__SSE3__ -U__SSE2__ -U__SSE__ -U__LP64__ -U_LP64 -U_WIN64 -U_M_X64 macro_probe.cctou16/32/64,stou8/16/32/64, and__WORDSIZE 64are defined under forced__riscv.gcc -c -D__riscv=1 -D__riscv_xlen=64 -U__x86_64__ -U__amd64__ -U__aarch64__ -U__ARM_NEON -U__AVX2__ -U__AVX__ -U__SSE4_1__ -U__SSSE3__ -U__SSE3__ -U__SSE2__ -U__SSE__ -U__LP64__ -U_LP64 -U_WIN64 -U_M_X64 trlec.c -o NULgcc -c -D__riscv=1 -D__riscv_xlen=64 -U__x86_64__ -U__amd64__ -U__aarch64__ -U__ARM_NEON -U__AVX2__ -U__AVX__ -U__SSE4_1__ -U__SSSE3__ -U__SSE3__ -U__SSE2__ -U__SSE__ -U__LP64__ -U_LP64 -U_WIN64 -U_M_X64 trled.c -o NULgcc -c -D__riscv=1 -D__riscv_xlen=64 -U__x86_64__ -U__amd64__ -U__aarch64__ -U__ARM_NEON -U__AVX2__ -U__AVX__ -U__SSE4_1__ -U__SSSE3__ -U__SSE3__ -U__SSE2__ -U__SSE__ -U__LP64__ -U_LP64 -U_WIN64 -U_M_X64 trle.c -o NULgmake ARCH=riscv64 "CC=gcc -D__riscv=1 -D__riscv_xlen=64 -U__x86_64__ -U__amd64__ -U__aarch64__ -U__ARM_NEON -U__AVX2__ -U__AVX__ -U__SSE4_1__ -U__SSSE3__ -U__SSE3__ -U__SSE2__ -U__SSE__ -U__LP64__ -U_LP64 -U_WIN64 -U_M_X64"riscv64executable indockcross/linux-riscv64:20260515-5fd14ac:trlewithmake ARCH=riscv64 CC=/usr/xcc/riscv64-unknown-linux-gnu/bin/riscv64-unknown-linux-gnu-gcc;trlewithfileandreadelf -h, which reported a realRISC-VELF (Machine: RISC-V);-march=nativeor-mssse3;trle -e 1 sample.binunderqemu-riscv64and got a successful encode/decode round-trip with noERRORoutput;qemu-riscv64on the same sample file and again saw noERROR, coveringtrle,srle,mrle, and the memcpy baseline path.Notes
riscv64.