NEnetworked·Dec 4, 2024Submission
lzsa: Byte-aligned compressor with fast decompression on 8-bit micros
1 points · Open discussionemmanuel-marty
lzsa
C2019–2024
emmanuel-marty / lzsa
lzsa
Byte-aligned, efficient lossless packer that is optimized for fast decompression on 8-bit micros
5Distinct people
6Mentions
0Explicit recommenders
263GitHub stars
What to know before exploring
What it is
Byte-aligned, efficient lossless packer that is optimized for fast decompression on 8-bit micros
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year6 dated mentions
Observed mentions: 2019-04-08 11:16:33 UTC to 2024-12-04 06:41:35 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
6 sourcesTrue.
If you're on your way down this rabbit hole, there's a bunch of old-machine-specific compression algorithms, developed by the emulator community, e.g. LZSA: https://github.com/emmanuel-marty/lzsa
In The LZ4 introduced in PostgreSQL 14 provides faster compressionThere's quite a lot of retro modern LZ activity too! LZ turns out to be amazing on old machines, often only a couple times slower than a block copy. Optimal compressors and control over the algorithm have led to some very tight demos.
https://www.brutaldeluxe.fr/products/crossdevtools/lz4/index... LZ4 Data Compression - a rather long and in-depth article looking at LZ4 on the 65816 for the Apple IIgs with a decompressor that exploits that processor's block copy.
https://github.com/emmanuel-marty/lzsa - LZSA - a LZ4-like modern LZ that's more efficient both in speed and compression to LZ4 (at least on the 8 bitters it targets) - includes a neat chart of speed/compression trade-offs on a ZX Spectrum with a variety of algorithms
In Modern LZ Compression (2019)Even x86 was basically a glorified, oversized and rather inelegant clone of the PDP-11. Though most of the inelegance was a concession to practicality, or backwards compatibility. (Do you really need the complexity of memory-memory moves?) Or maybe they modelled it after the VAX. Hmm. Intel's employees would have been using some VAXen at the time they designed the 8086. Anyway. Very similar. Both by mnemonics, and the general architecture.
This is the start of a decompression routine for LZSA compression for both architectures. (I don't think the PDP-11 code was even modelled after the 8086. Just convergent implementation?) Source here: https://github.com/emmanuel-marty/lzsa
The only difference of note is the PDP-11 doesn't have string array operations (but it doesn't really need them with addressing modes like (r1)+) and so do
Read the rest
es an explicit check for end of input, that is implicit on the x86 before it loops back to ReadToken. Otherwise there is a near one-to-one translation of each instruction, often with the same mnemonics.
ReadToken: .decode_token:
movb (r1)+,r0 mov ax,cx
mov r0,r5 lodsb
mov dx,cx
bic #177617,r0
beq NoLiterals
asr r0 mov cl,4
asr r0 shr al,cl
asr r0
asr r0
cmp #7,r0 cmp al,07H
bne m1 jne .got_literals
... ...
With that said, they had similar design goals. Minimal (but not minimalist) hardware requirements, compact and expressive instruction set suitable both for direct assembly programming (as that was still dominant in the 70s) as well as a tolerably clean target for simple compilers. System/360 did not really have these design goals. So while even if designers had drawn inspiration from the System/360 instead, the architecture of minis like the PDP-11 in the 70s, and microprocessors of the the 80s, would probably still have been different from System/360. Folks wanted a hardware stack in 1978! Of course... maybe they only wanted it because they'd gotten used to having it on machines like the PDP-11.
This is basically an ad.
The author of LZSA has a nice comparison that may help:
https://github.com/emmanuel-marty/lzsa
LZSA focuses on very fast decompression on 8-bit systems; so I suspect some of those could be used for MCUs as well, although getting to the level of integration that Segger is selling with their compression method may not be trivial.
In Smash: An efficient compression algorithm for microcontrollersByte-aligned compression using a suffix array
2 points · Open discussion