This patch adds zero compression for bss segments. One of the reasons for this is that currently, if you select no compression, the bss segment of filo takes up 153K with just zeroes. With this patch, it always takes up a lar header + 1 byte. I left the one byte so that the checksum wouldn't be broken.
This patch could have taken out the calloc in the compression area, but since it only uses compile-time memory, I decided to keep this simple.
I've included the results from lar -l for the four interesting cases.
Myles
Signed-off-by: Myles Watson myles@pel.cs.byu.edu
Using lzma compression (with the patch): normal/payload/segment0 (152704 bytes, zeroes compressed to 1 bytes @0x50);loadaddress 0x0x10bd80 entry 0x0x109c84 normal/payload/segment1 (48488 bytes, lzma compressed to 28098 bytes @0xb0);loadaddress 0x0x100000 entry 0x0x109c84 normal/payload/segment2 (72 bytes, lzma compressed to 47 bytes @0x6ed0);loadaddress 0x0x131200 entry 0x0x109c84 normal/option_table (932 bytes @0x6f50);loadaddress 0x0 entry 0x0 normal/stage2/segment0 (191792 bytes, zeroes compressed to 1 bytes @0x7350);loadaddress 0x0xb2a0 entry 0x0x2000 normal/stage2/segment1 (28116 bytes, lzma compressed to 15008 bytes @0x73b0);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (5308 bytes, lzma compressed to 313 bytes @0xaea0);loadaddress 0x0x9de0 entry 0x0x2000 normal/initram/segment0 (432 bytes @0xb030);loadaddress 0x0 entry 0x0x42 bootblock (20480 bytes @0xfb000) Total size = 65744 bytes (0x100d0)
Using lzma compression (before the patch): normal/payload/segment0 (152704 bytes, lzma compressed to 105 bytes @0x50);loadaddress 0x0x10bd80 entry 0x0x109c84 normal/payload/segment1 (48488 bytes, lzma compressed to 28098 bytes @0x110);loadaddress 0x0x100000 entry 0x0x109c84 normal/payload/segment2 (72 bytes, lzma compressed to 47 bytes @0x6f30);loadaddress 0x0x131200 entry 0x0x109c84 normal/option_table (932 bytes @0x6fb0);loadaddress 0x0 entry 0x0 normal/stage2/segment0 (191792 bytes, lzma compressed to 110 bytes @0x73b0);loadaddress 0x0xb2a0 entry 0x0x2000 normal/stage2/segment1 (28116 bytes, lzma compressed to 15006 bytes @0x7470);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (5308 bytes, lzma compressed to 313 bytes @0xaf60);loadaddress 0x0x9de0 entry 0x0x2000 normal/initram/segment0 (432 bytes @0xb0f0);loadaddress 0x0 entry 0x0x42 bootblock (20480 bytes @0xfb000) Total size = 65955 bytes (0x101a3)
Using no compression (before the patch): normal/payload/segment0 (152704 bytes @0x50);loadaddress 0x0x10bd80 entry 0x0x109c84 normal/payload/segment1 (48488 bytes @0x25520);loadaddress 0x0x100000 entry 0x0x109c84 normal/payload/segment2 (72 bytes @0x312e0);loadaddress 0x0x131200 entry 0x0x109c84 normal/option_table (932 bytes @0x31380);loadaddress 0x0 entry 0x0 normal/stage2/segment0 (191792 bytes @0x31780);loadaddress 0x0xb2a0 entry 0x0x2000 normal/stage2/segment1 (28116 bytes @0x60500);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (5308 bytes @0x67330);loadaddress 0x0x9de0 entry 0x0x2000 normal/initram/segment0 (432 bytes @0x68840);loadaddress 0x0 entry 0x0x42 bootblock (20480 bytes @0xfb000) Total size = 448756 bytes (0x6d8f4)
Using no compression (after the patch): normal/payload/segment0 (152704 bytes, zeroes compressed to 1 bytes @0x50);loadaddress 0x0x10bd80 entry 0x0x109c84 normal/payload/segment1 (48488 bytes @0xb0);loadaddress 0x0x100000 entry 0x0x109c84 normal/payload/segment2 (72 bytes @0xbe70);loadaddress 0x0x131200 entry 0x0x109c84 normal/option_table (932 bytes @0xbf10);loadaddress 0x0 entry 0x0 normal/stage2/segment0 (191792 bytes, zeroes compressed to 1 bytes @0xc310);loadaddress 0x0xb2a0 entry 0x0x2000 normal/stage2/segment1 (28116 bytes @0xc370);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (5308 bytes @0x131a0);loadaddress 0x0x9de0 entry 0x0x2000 normal/initram/segment0 (432 bytes @0x146b0);loadaddress 0x0 entry 0x0x42 bootblock (20480 bytes @0xfb000) Total size = 104262 bytes (0x19746)
On Thu, Feb 14, 2008 at 10:13:16AM -0700, Myles Watson wrote:
I left the one byte so that the checksum wouldn't be broken.
This is important. Please add a comment in do_zeroes_compress().
+++ include/lar.h (working copy) @@ -67,6 +67,7 @@ * 0 = no compression * 1 = lzma * 2 = nrv2b
* 3 = zeroes
I would really like a more generic RLE version that copes with any repeated byte value. It will be dirt simple, not much code and no dependecies, thus always included.
Possibly lar should even try to autodetect suitable candidates for RLE compression. But note that the flashfiller file is a special case that must never be RLE compressed.
//Peter
Sorry, my mail server went down, so I'm trying to catch up.
On Thu, Feb 14, 2008 at 10:13:16AM -0700, Myles Watson wrote:
I left the one byte so that the checksum wouldn't be broken.
This is important. Please add a comment in do_zeroes_compress().
I'll do that.
+++ include/lar.h (working copy) @@ -67,6 +67,7 @@ * 0 = no compression * 1 = lzma * 2 = nrv2b
* 3 = zeroes
I would really like a more generic RLE version that copes with any repeated byte value. It will be dirt simple, not much code and no dependecies, thus always included.
Possibly lar should even try to autodetect suitable candidates for RLE compression. But note that the flashfiller file is a special case that must never be RLE compressed.
I thought about this, but since I couldn't think of a use case, I didn't know how big to make the repeating value (u8, u32), where to autodetect it, etc. Maybe for debugging someone will want to fill an area with 0xAA5555AA?
You're right that it would be easy to add, but I think without a use case it'll be hard to get the right features in.
Myles
On Fri, Feb 15, 2008 at 11:09 AM, Myles Watson mylesgw@gmail.com wrote:
You're right that it would be easy to add, but I think without a use case it'll be hard to get the right features in.
The zero patch is trivial and easy. Most importantly, it greatly reduces the cost of zero-encoded segments-- yes, they're small, but reducing 150 bytes to 1 byte is hard to ignore, and reducing an lzma decompress to a memset is neat.
The RLE patches are not so simple, though they seem so at first. Let's hold off on such features until we are certain we need them.
ron