Re: [Etherboot-developers] lzhuf compression program hangs

[Markus G. <ma...@gu...>]

> Hmm, nobody has tried lzhuf with images that large, because no Etherboot
> image is that large. So you are on unchartered territory. Remember that
> you can't pick any arbitrary algorithm, it has to be the inverse of the
> one on loader.S. Also the loader.S implementation may have size
> limitations too. I don't know if these limits can be raised.

loader.S is heavily optimized for size. This results in several
limitations. I know that there is no way it will uncompress more
than 64kB, because of using offsets and segment registers. It might
even be restricted to less memory, but I haven't checked that. When
I wrote it, the target was to be able to uncompress 32kB images.

If you find a solution to the restricted addressing modes you can
increase the uncompressed size to more than 64kB, but I am not sure
whether there is a limit on the compressed size. Also, please note
that loader.S does not include code to reset the frequencies in case
of an integer overrun. This problem can theoretically occur as soon
as after the first 64kB; in real life it will probably hit a little
bit later.

Please include the extra code, only if you have a real problem with
the current limitations. Increasing the size of the uncompressor
is noticeably more expensive than increasing the size of the
compressed data. For every byte that loader.S grows, you lose several
bytes of compressed code. I don't think there are that many people
out there still using 8kB ROMs (that was the original reason why I
wrote the compressor), but 16kB ROMs are probably still used by
several of the people on this list.


Markus

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...