8000 Research ZX0 instead of Exomizer decompression · Issue #2317 · ghaerr/elks · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Research ZX0 instead of Exomizer decompression #2317
Open
@asiekierka

Description

@asiekierka

If you want to play with LZ4_8088, the first step would be compressing executables with it, and see how small they get. Using Exomizer, we're seeing about a ~28-33% decrease in size.

Out of curiosity, I checked a few compressors: Exomizer (as used by ELKS), LZ4 (as suggested by Vutshi), and ZX0 (my personal go-to on retro platforms, but using the salvador compression tool):

-rw-r--r-- 1 asie asie 31482 Apr 21 19:37 ash.exo
-rwxr-xr-x 1 asie asie 37565 Apr 21 19:21 ash.lz4
-rw-r--r-- 1 asie asie 31367 Apr 21 19:38 ash.zx0
-rwxr-xr-x 1 asie asie  4755 Apr 21 19:49 login.exo
-rwxr-xr-x 1 asie asie  5620 Apr 21 19:21 login.lz4
-rw-r--r-- 1 asie asie  4655 Apr 21 19:50 login.zx0

ZX0 turns out to be an interesting alternative choice:

  • it presents compression ratios similar to or narrowly beating Exomizer...
  • however, it requires a different (per-file) "gap" between compressed and decompressed data. For example, login requires 35 bytes reserved, while ash requires 3 bytes reserved. What this means is that, for example, the amount of memory reserved for in-place decompression of login has to be 35 bytes larger than the size of the uncompressed login binary;
  • however, it may also provide faster decompression speeds, owing to an optimized native 8088/8086 decompressor existing in under 100 bytes!

As such, I think it deserves further evaluation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0