On 2021-09-02 Liao Hua wrote:
> +#define LZMA_FILTER_ARM64         LZMA_VLI_C(0x0a)

Is this ID 0x0A in actual use somewhere? Can it be used in the official
.xz format for something else than the filter you submitted?

On 2021-09-08 Lasse Collin wrote:
> On 2021-09-02 Liao Hua wrote:
> > We have some questions about xz bcj filters.
> > 1. Why ARM and ARM-Thumb bcj filters are little endian only?  
> Perhaps it's an error. Long ago when I wrote the docs, I knew that the
> ARM filters worked on little endian code but didn't know how big
> endian ARM was done.

I read about this and if I have understood correctly, in the past big
endian ARM could use big endian instruction encoding too but nowadays
instructions are always in little endian order, even if data access is
big endian. The endianness in the docs is about instruction encoding.
The filters don't care about data access.

The mention of endianness has been removed in 5.3.4alpha (and thus
5.4.0) since it is more confusing than useful.

The PowerPC filter is indeed big endian only. Little endian PowerPC
would need a new filter. Filtering little endian PowerPC code would
have comparable improvement in compression as the current big endian
filter does.

> > 2. Why there is no arm64 bcj filter? Are there any technical risks?
> > Or other considerations?  
> It just hasn't been done, no other reason.

There will probably be a new ARM64 filter in 5.4.0. The exact design is
still not frozen. Different parameters work a little better or worse in
different situations. It doesn't seem practical to make a tunable
filter since few people would try different settings and it would make
the code slower and a little bigger (which matters in XZ Embedded).

With ARM64 it is good to use --lzma2=lc=2,lp=2 instead of the default
lc=3,lp=0. This alone can give a little over 1 % smaller file.

Lasse Collin

Reply via email to