Hand-written 68k asm for the crypto core's hot loop(s), reached through a
runtime function-pointer seam so the portable C reference stays the
permanent fallback.
Split out of this issue: the optional AmiSSL-backed crypto provider is
tracked separately as #85, since it's meaningfully more effort/surface for
less certain value than the asm path alone.
Shipped in #86
sha1_compress() (SHA-1's 80-round block compression) - src/core/sha1_asm.s,
reached via src/core/crypto_dispatch.h / src/amiga/crypto_select.c,
overridable with ENVARC:AmiAuth/cryptoasm=off.- Not 020+-gated: restricted to plain-68000 instructions, so it's the
default on every CPU tier this project supports (validated in CI under
amitools' vamos, -C 000 and -C 020), not an opt-in accelerated path.
- Measured real-hardware speedup (Copperline, real Kickstart 3.1 ROM,
PBKDF2-HMAC-SHA1 @ 600 iterations): ~17% faster on 68000, ~20% on 68020,
~15% on 68030 - see docs/ARCHITECTURE.md.
- ChaCha20 has no asm path. A hand-written attempt was built, verified
correct, but measured ~17% slower than the C reference on real hardware -
GCC's -O2 output keeps the whole 16-word state register-resident across
all 10 rounds, while the naive asm reloaded everything from the stack every
quarter-round. Closing that gap needs a substantially more involved
register-resident rewrite, judged not worth the risk for this pass since
ChaCha20 isn't the hot loop that matters most (PBKDF2's iteration loop is,
and that's SHA-1-bound). g_chacha20_block stays on the C reference.
Research findings (from scoping this issue)
- Toolchain: the amiga-gcc docker image has a working GNU-syntax m68k
assembler (m68k-amigaos-as); a minimal hand-written asm function
assembles, links, and calls correctly against C code (leading-underscore
C symbol mangling).
- vamos (amitools) is an API-level m68k emulator (Musashi CPU core +
faked exec.library/dos.library calls) - no Kickstart/Workbench needed,
validates correctness but has no cycle-accurate timing (68030 isn't even
separately modeled). Real performance numbers came from Copperline
instead, which does model per-CPU-tier timing via timer.device EClock.
Hand-written 68k asm for the crypto core's hot loop(s), reached through a
runtime function-pointer seam so the portable C reference stays the
permanent fallback.
Split out of this issue: the optional AmiSSL-backed crypto provider is
tracked separately as #85, since it's meaningfully more effort/surface for
less certain value than the asm path alone.
Shipped in #86
sha1_compress()(SHA-1's 80-round block compression) -src/core/sha1_asm.s,reached via
src/core/crypto_dispatch.h/src/amiga/crypto_select.c,overridable with
ENVARC:AmiAuth/cryptoasm=off.default on every CPU tier this project supports (validated in CI under
amitools'
vamos,-C 000and-C 020), not an opt-in accelerated path.PBKDF2-HMAC-SHA1 @ 600 iterations): ~17% faster on 68000, ~20% on 68020,
~15% on 68030 - see
docs/ARCHITECTURE.md.correct, but measured ~17% slower than the C reference on real hardware -
GCC's
-O2output keeps the whole 16-word state register-resident acrossall 10 rounds, while the naive asm reloaded everything from the stack every
quarter-round. Closing that gap needs a substantially more involved
register-resident rewrite, judged not worth the risk for this pass since
ChaCha20 isn't the hot loop that matters most (PBKDF2's iteration loop is,
and that's SHA-1-bound).
g_chacha20_blockstays on the C reference.Research findings (from scoping this issue)
assembler (
m68k-amigaos-as); a minimal hand-written asm functionassembles, links, and calls correctly against C code (leading-underscore
C symbol mangling).
faked exec.library/dos.library calls) - no Kickstart/Workbench needed,
validates correctness but has no cycle-accurate timing (68030 isn't even
separately modeled). Real performance numbers came from Copperline
instead, which does model per-CPU-tier timing via
timer.deviceEClock.