On Fri, Dec 10, 2021 at 10:17 PM Norbert Lange <[email protected]> wrote:
> Hello,
>
> the question is still open whether BB is ok with taking the upstream
> zstd sources and semi-automatically export them [1]. cost is around
> 17K in binary size with a few manual code removals, ie- without
> diverting from upstream too much. That code is also available on
> github [2]
>
> upstream would be willing to support continuous testing, should we
> have some modifications that can end up there (ie. separate codepaths
> guarded by macros). So probably that would mean getting the sources
> exported *fully* automated, then check if those compile and work with
> some testing stubs. [3]
Well... code as it stands now is not written with much thought
about keeping size smaller. I can easily find places
which I'm not happy about. Look at this:
zstd_internal.h
static UNUSED_ATTR const U32 LL_bits[MaxLL+1] = {
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
1, 1, 1, 1, 2, 2, 3, 3,
4, 6, 7, 8, 9,10,11,12,
13,14,15,16
};
static UNUSED_ATTR const S16 LL_defaultNorm[MaxLL+1] = {
4, 3, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 1, 1, 1,
2, 2, 2, 2, 2, 2, 2, 2,
2, 3, 2, 1, 1, 1, 1, 1,
-1,-1,-1,-1
};
All "bits" arrays fit into 16 bit ints. All "defaultNorm"
arrays fit into 8-bit signed ints.
Also, defining arrays in .h files is wrong.
I bet with detailed review many more things like this
are to be discovered.
Anyone is willing to submit patches upstream
until it looks better?
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
