diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/LZO.FAQ | 213 | ||||
| -rw-r--r-- | doc/LZO.TXT | 292 | ||||
| -rw-r--r-- | doc/LZOAPI.TXT | 285 | ||||
| -rw-r--r-- | doc/LZOTEST.TXT | 75 |
4 files changed, 865 insertions, 0 deletions
diff --git a/doc/LZO.FAQ b/doc/LZO.FAQ new file mode 100644 index 0000000..cb1f38a --- /dev/null +++ b/doc/LZO.FAQ @@ -0,0 +1,213 @@ +============================================================================ +LZO Frequently Asked Questions +============================================================================ + + +I hate reading docs - just tell me how to add compression to my program +======================================================================= + +This is for the impatient: take a look at examples/simple.c and +examples/lzopack.c and see how easy this is. + +But you will come back to read the documentation later, won't you ? + + +Can you explain the naming conventions of the algorithms ? +========================================================== + +Let's take a look at LZO1X: + + The algorithm name is LZO1X. + The algorithm category is LZO1. + Various compression levels are implemented. + + LZO1X-999 + !---------- algorithm category + !--------- algorithm type + !!!----- compression level (1-9, 99, 999) + + LZO1X-1(11) + !---------- algorithm category + !--------- algorithm type + !------- compression level (1-9, 99, 999) + !!---- memory level (memory requirements for compression) + +All compression/memory levels generate the same compressed data format, +so e.g. the LZO1X decompressor handles all LZO1X-* compression levels +(for more information about the decompressors see below). + +Category LZO1 algorithms: compressed data format is strictly byte aligned +Category LZO2 algorithms: uses bit-shifting, slower decompression + + +Why are there so many algorithms ? +================================== + +Because of historical reasons - I want to support unlimited +backward compatibility. + +Don't get misled by the size of the library - using one algorithm +increases the size of your application by only a few KiB. + +If you just want to add a little bit of data compression to your +application you may be looking for miniLZO. +See minilzo/README.LZO for more information. + + +Which algorithm should I use ? +============================== + +LZO1X seems to be best choice in many cases, so: +- when going for speed use LZO1X-1 +- when generating pre-compressed data use LZO1X-999 +- if you have little memory available for compression use LZO1X-1(11) + or LZO1X-1(12) + +Of course, your mileage may vary, and you are encouraged to run your +own experiments. Try LZO1Y and LZO1F next. + + +What's the difference between the decompressors per algorithm ? +=============================================================== + +Once again let's use LZO1X for explanation: + +- lzo1x_decompress + The 'standard' decompressor. Pretty fast - use this whenever possible. + + This decompressor expects valid compressed data. + If the compressed data gets corrupted somehow (e.g. transmission + via an erroneous channel, disk errors, ...) it will probably crash + your application because absolutely no additional checks are done. + +- lzo1x_decompress_safe + The 'safe' decompressor. Somewhat slower. + + This decompressor will catch all compressed data violations and + return an error code in this case - it will never crash. + +- lzo1x_decompress_asm + Same as lzo1x_decompress - written in assembler. + +- lzo1x_decompress_asm_safe + Same as lzo1x_decompress_safe - written in assembler. + +- lzo1x_decompress_asm_fast + Similar to lzo1x_decompress_asm - but even faster. + + For reasons of speed this decompressor can write up to 3 bytes + past the end of the decompressed (output) block. + [ technical note: because data is transferred in 32-bit units ] + + Use this when you are decompressing from one memory block to + another memory block - just provide output space for 3 extra bytes. + You shouldn't use it if e.g. you are directly decompressing to video + memory (because the extra bytes will be show up on the screen). + +- lzo1x_decompress_asm_fast_safe + This is the safe version of lzo1x_decompress_asm_fast. + + +Notes: +------ +- When using a safe decompressor you must pass the number of + bytes available in 'dst' via the parameter 'dst_len'. + +- If you want to be sure that your data is not corrupted you must + use a checksum - just using the safe decompressor is not enough, + because many data errors will not result in a compressed data violation. + +- Assembler versions are only available for the i386 family yet. + Please see also asm/i386/00README.TXT + +- You should test if the assembler versions are actually faster + than the C version on your machine - some compilers can do a very + good optimization job and they also can optimize the code + for a specific processor. + + +What is this optimization thing ? +================================= + +The compressors use a heuristic approach - they sometimes code +information that doesn't improve compression ratio. + +Optimization removes this superfluos information in order to +increase decompression speed. + +Optimization works similar to decompression except that the +compressed data is modified as well. The length of the compressed +data block will not change - only the compressed data-bytes will +get rearranged a little bit. + +Don't expect too much, though - my tests have shown that the +optimization step improves decompression speed by about 1-3%. + + +I need even more decompression speed... +======================================= + +Many RISC processors (like MIPS) can transfer 32-bit words much +faster than bytes - this can significantly speed up decompression. +So after verifying that everything works fine you can try if activating +the LZO_ALIGNED_OK_4 macro improves LZO1X and LZO1Y decompression +performance. Change the file config.h accordingly and recompile everything. + +On an i386 architecture you should evaluate the assembler versions. + + +How can I reduce memory requirements when (de)compressing ? +=========================================================== + +If you cleverly arrange your data, you can do an overlapping (in-place) +decompression which means that you can decompress to the *same* +block where the compressed data resides. This effectively removes +the space requirements for holding the compressed data block. + +This technique is essential e.g. for usage in an executable packer. + +You can also partly overlay the buffers when doing compression. + +See examples/overlap.c for a working example. + + +Can you give a cookbook for using pre-compressed data ? +======================================================= + +Let's assume you use LZO1X-999. + +1) pre-compression step + - call lzo_init() + - call lzo1x_999_compress() + - call lzo1x_optimize() + - compute an adler32 checksum of the *compressed* data + - store the compressed data and the checksum in a file + - if you are paranoid you should verify decompression now + +2) decompression step within your application + - call lzo_init() + - load your compressed data and the checksum + - optionally verify the checksum of the compressed data + (so that you can use the standard decompressor) + - decompress + +See examples/precomp.c and examples/precomp2.c for a working example. + + +How much can my data expand during compression ? +================================================ + +LZO will expand incompressible data by a little amount. +I still haven't computed the exact values, but I suggest using +these formulas for a worst-case expansion calculation: + + Algorithm LZO1, LZO1A, LZO1B, LZO1C, LZO1F, LZO1X, LZO1Y, LZO1Z: + ---------------------------------------------------------------- + output_block_size = input_block_size + (input_block_size / 16) + 64 + 3 + + [This is about 106% for a large block size.] + + Algorithm LZO2A: + ---------------- + output_block_size = input_block_size + (input_block_size / 8) + 128 + 3 + diff --git a/doc/LZO.TXT b/doc/LZO.TXT new file mode 100644 index 0000000..7426ab2 --- /dev/null +++ b/doc/LZO.TXT @@ -0,0 +1,292 @@ + + ============================================================================ + LZO -- a real-time data compression library + ============================================================================ + + Author : Markus Franz Xaver Johannes Oberhumer + <markus@oberhumer.com> + http://www.oberhumer.com/opensource/lzo/ + Version : 2.06 + Date : 12 Aug 2011 + + + Abstract + -------- + LZO is a portable lossless data compression library written in ANSI C. + It offers pretty fast compression and very fast decompression. + Decompression requires no memory. + + In addition there are slower compression levels achieving a quite + competitive compression ratio while still decompressing at + this very high speed. + + The LZO algorithms and implementations are copyrighted OpenSource + distributed under the GNU General Public License. + + + Introduction + ------------ + LZO is a data compression library which is suitable for data + de-/compression in real-time. This means it favours speed + over compression ratio. + + The acronym LZO is standing for Lempel-Ziv-Oberhumer. + + LZO is written in ANSI C. Both the source code and the compressed + data format are designed to be portable across platforms. + + LZO implements a number of algorithms with the following features: + + - Decompression is simple and *very* fast. + - Requires no memory for decompression. + - Compression is pretty fast. + - Requires 64 KiB of memory for compression. + - Allows you to dial up extra compression at a speed cost in the + compressor. The speed of the decompressor is not reduced. + - Includes compression levels for generating pre-compressed + data which achieve a quite competitive compression ratio. + - There is also a compression level which needs only 8 KiB for compression. + - Algorithm is thread safe. + - Algorithm is lossless. + + LZO supports overlapping compression and in-place decompression. + + + Design criteria + --------------- + LZO was designed with speed in mind. Decompressor speed has been + favoured over compressor speed. Real-time decompression should be + possible for virtually any application. The implementation of the + LZO1X decompressor in optimized i386 assembler code runs about at + the third of the speed of a memcpy() - and even faster for many files. + + In fact I first wrote the decompressor of each algorithm thereby + defining the compressed data format, verified it with manually + created test data and at last added the compressor. + + + Performance + ----------- + To keep you interested, here is an overview of the average results + when compressing the Calgary Corpus test suite with a blocksize + of 256 KiB, originally done on an ancient Intel Pentium 133. + + The naming convention of the various algorithms goes LZOxx-N, where N is + the compression level. Range 1-9 indicates the fast standard levels using + 64 KiB memory for compression. Level 99 offers better compression at the + cost of more memory (256 KiB), and is still reasonably fast. + Level 999 achieves nearly optimal compression - but it is slow + and uses much memory, and is mainly intended for generating + pre-compressed data. + + The C version of LZO1X-1 is about 4-5 times faster than the fastest + zlib compression level, and it also outperforms other algorithms + like LZRW1-A and LZV in both compression ratio and compression speed + and decompression speed. + + +------------------------------------------------------------------------+ + | Algorithm Length CxB ComLen %Remn Bits Com K/s Dec K/s | + | --------- ------ --- ------ ----- ---- ------- ------- | + | | + | memcpy() 224401 1 224401 100.0 8.00 60956.83 59124.58 | + | | + | LZO1-1 224401 1 117362 53.1 4.25 4665.24 13341.98 | + | LZO1-99 224401 1 101560 46.7 3.73 1373.29 13823.40 | + | | + | LZO1A-1 224401 1 115174 51.7 4.14 4937.83 14410.35 | + | LZO1A-99 224401 1 99958 45.5 3.64 1362.72 14734.17 | + | | + | LZO1B-1 224401 1 109590 49.6 3.97 4565.53 15438.34 | + | LZO1B-2 224401 1 106235 48.4 3.88 4297.33 15492.79 | + | LZO1B-3 224401 1 104395 47.8 3.83 4018.21 15373.52 | + | LZO1B-4 224401 1 104828 47.4 3.79 3024.48 15100.11 | + | LZO1B-5 224401 1 102724 46.7 3.73 2827.82 15427.62 | + | LZO1B-6 224401 1 101210 46.0 3.68 2615.96 15325.68 | + | LZO1B-7 224401 1 101388 46.0 3.68 2430.89 15361.47 | + | LZO1B-8 224401 1 99453 45.2 3.62 2183.87 15402.77 | + | LZO1B-9 224401 1 99118 45.0 3.60 1677.06 15069.60 | + | LZO1B-99 224401 1 95399 43.6 3.48 1286.87 15656.11 | + | LZO1B-999 224401 1 83934 39.1 3.13 232.40 16445.05 | + | | + | LZO1C-1 224401 1 111735 50.4 4.03 4883.08 15570.91 | + | LZO1C-2 224401 1 108652 49.3 3.94 4424.24 15733.14 | + | LZO1C-3 224401 1 106810 48.7 3.89 4127.65 15645.69 | + | LZO1C-4 224401 1 105717 47.7 3.82 3007.92 15346.44 | + | LZO1C-5 224401 1 103605 47.0 3.76 2829.15 15153.88 | + | LZO1C-6 224401 1 102585 46.5 3.72 2631.37 15257.58 | + | LZO1C-7 224401 1 101937 46.2 3.70 2378.57 15492.49 | + | LZO1C-8 224401 1 100779 45.6 3.65 2171.93 15386.07 | + | LZO1C-9 224401 1 100255 45.4 3.63 1691.44 15194.68 | + | LZO1C-99 224401 1 97252 44.1 3.53 1462.88 15341.37 | + | LZO1C-999 224401 1 87740 40.2 3.21 306.44 16411.94 | + | | + | LZO1F-1 224401 1 113412 50.8 4.07 4755.97 16074.12 | + | LZO1F-999 224401 1 89599 40.3 3.23 280.68 16553.90 | + | | + | LZO1X-1(11) 224401 1 118810 52.6 4.21 4544.42 15879.04 | + | LZO1X-1(12) 224401 1 113675 50.6 4.05 4411.15 15721.59 | + | LZO1X-1 224401 1 109323 49.4 3.95 4991.76 15584.89 | + | LZO1X-1(15) 224401 1 108500 49.1 3.93 5077.50 15744.56 | + | LZO1X-999 224401 1 82854 38.0 3.04 135.77 16548.48 | + | | + | LZO1Y-1 224401 1 110820 49.8 3.98 4952.52 15638.82 | + | LZO1Y-999 224401 1 83614 38.2 3.05 135.07 16385.40 | + | | + | LZO1Z-999 224401 1 83034 38.0 3.04 133.31 10553.74 | + | | + | LZO2A-999 224401 1 87880 40.0 3.20 301.21 8115.75 | + +------------------------------------------------------------------------+ + + Notes: + - CxB is the number of blocks + - K/s is the speed measured in 1000 uncompressed bytes per second + - the assembler decompressors are even faster + + + Short documentation + ------------------- + LZO is a block compression algorithm - it compresses and decompresses + a block of data. Block size must be the same for compression + and decompression. + + LZO compresses a block of data into matches (a sliding dictionary) + and runs of non-matching literals. LZO takes care about long matches + and long literal runs so that it produces good results on highly + redundant data and deals acceptably with non-compressible data. + + When dealing with incompressible data, LZO expands the input + block by a maximum of 64 bytes per 1024 bytes input. + + I have verified LZO using such tools as valgrind and other memory checkers. + And in addition to compressing gigabytes of files when tuning some parameters + I have also consulted various 'lint' programs to spot potential portability + problems. LZO is free of any known bugs. + + + The algorithms + -------------- + There are too many algorithms implemented. But I want to support + unlimited backward compatibility, so I will not reduce the LZO + distribution in the future. + + As the many object files are mostly independent of each other, the + size overhead for an executable statically linked with the LZO library + is usually pretty low (just a few KiB) because the linker will only add + the modules that you are actually using. + + I first published LZO1 and LZO1A in the Internet newsgroups + comp.compression and comp.compression.research in March 1996. + They are mainly included for compatibility reasons. The LZO2A + decompressor is too slow, and there is no fast compressor anyway. + + My experiments have shown that LZO1B is good with a large blocksize + or with very redundant data, LZO1F is good with a small blocksize or + with binary data and that LZO1X is often the best choice of all. + LZO1Y and LZO1Z are almost identical to LZO1X - they can achieve a + better compression ratio on some files. + Beware, your mileage may vary. + + + Usage of the library + -------------------- + Despite of its size, the basic usage of LZO is really very simple. + + Let's assume you want to compress some data with LZO1X-1: + A) compression + * include <lzo/lzo1x.h> + call lzo_init() + compress your data with lzo1x_1_compress() + * link your application with the LZO library + B) decompression + * include <lzo/lzo1x.h> + call lzo_init() + decompress your data with lzo1x_decompress() + * link your application with the LZO library + + The program examples/simple.c shows a fully working example. + See also LZO.FAQ for more information. + + + Building LZO + ------------ + As LZO uses Autoconf+Automake+Libtool the building process under + UNIX systems should be very unproblematic. Shared libraries are + supported on many architectures as well. + For detailed instructions see the file INSTALL. + + Please note that due to the design of the ELF executable format + the performance of a shared library on i386 systems (e.g. Linux) + is a little bit slower, so you may want to link your applications + with the static version (liblzo2.a) anyway. + + For building under DOS, Win16, Win32, OS/2 and other systems + take a look at the file B/00readme.txt. + + In case of troubles (like decompression data errors) try recompiling + everything without optimizations - LZO may break the optimizer + of your compiler. See the file BUGS. + + LZO is written in ANSI C. In particular this means: + - your compiler must understand prototypes + - your compiler must understand prototypes in function pointers + - your compiler must correctly promote integrals ("value-preserving") + - your preprocessor must implement #elif, #error and stringizing + - you must have a conforming and correct <limits.h> header + - you must have <stddef.h>, <string.h> and other ANSI C headers + - you should have size_t and ptrdiff_t + + + Portability + ----------- + I have built and tested LZO successfully on a variety of platforms + including DOS (16 + 32 bit), Windows 3.x (16-bit), Win32, Win64, + Linux, *BSD, HP-UX and many more. + + LZO is also reported to work under AIX, ConvexOS, IRIX, MacOS, PalmOS (Pilot), + PSX (Sony Playstation), Solaris, SunOS, TOS (Atari ST) and VxWorks. + Furthermore it is said that its performance on a Cray is superior + to all other machines... + + And I think it would be much fun to translate the decompressors + to Z-80 or 6502 assembly. + + + The future + ---------- + Here is what I'm planning for the next months. No promises, though... + + - interfaces to .NET and Mono + - interfaces to Perl, Java, Python, Delphi, Visual Basic, ... + - improve documentation and API reference + + + Some comments about the source code + ----------------------------------- + Be warned: the main source code in the 'src' directory is a + real pain to understand as I've experimented with hundreds of slightly + different versions. It contains many #if and some gotos, and + is *completely optimized for speed* and not for readability. + Code sharing of the different algorithms is implemented by stressing + the preprocessor - this can be really confusing. Lots of marcos and + assertions don't make things better. + + Nevertheless LZO compiles very quietly on a variety of + compilers with the highest warning levels turned on, even + in C++ mode. + + + Copyright + --------- + LZO is Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, + 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 + Markus Franz Xaver Oberhumer <markus@oberhumer.com>. + + LZO is distributed under the terms of the GNU General Public License (GPL). + See the file COPYING. + + Special licenses for commercial and other applications which + are not willing to accept the GNU General Public License + are available by contacting the author. + + + diff --git a/doc/LZOAPI.TXT b/doc/LZOAPI.TXT new file mode 100644 index 0000000..5ae7353 --- /dev/null +++ b/doc/LZOAPI.TXT @@ -0,0 +1,285 @@ + +============================================================================ +LZO -- a real-time data compression library LIBRARY REFERENCE +============================================================================ + + +[ please read LZO.FAQ first ] + + +Table of Contents +================= + +1 Introduction to the LZO Library Reference +1.1 Preliminary notes +1.2 Headers +2 General +2.1 The memory model +2.2 Public integral types +2.3 Public pointer types +2.4 Public function types +3 Function reference +3.1 Initialization +3.2 Compression +3.3 Decompression +3.4 Optimization +3.5 String functions +3.6 Checksum functions +3.7 Version functions +4 Variable reference + + + +1 Introduction to the LZO Library Reference +============================================= + + +1.1 Preliminary notes +--------------------- + +- 'C90' is short for ISO 9899-1990, the ANSI/ISO standard for the C + programming language + + +1.2 Headers +----------- + +This section briefly describes the headers. + +<lzo/lzoconf.h> + + Contains definitions for the basic integral and pointer types, + provides wrappers for the library calling conventions, defines + error codes and contains prototypes for the generic functions. + This file is automatically included by all LZO headers. + +<lzo/lzo1.h> +<lzo/lzo1a.h> +<lzo/lzo1b.h> +<lzo/lzo1c.h> +<lzo/lzo1f.h> +<lzo/lzo1x.h> +<lzo/lzo1y.h> +<lzo/lzo1z.h> +<lzo/lzo2a.h> + + These files provide definitions and prototypes for the + actual (de-)compression functions. + + + +2 General +========= + + +2.1 The memory model +-------------------- + +The documentation indicates that LZO requires 32-bit integers. It's +not the integer size that really matters, though, but the memory +model. If your memory model allows to access pointers at 32-bit +offsets, then there is no problem at all - LZO works fine on my +old Atari ST, which has 16 bit integers and a flat 32-bit memory model. +Using 'huge' 32-bit pointers under 16-bit DOS is a workaround for this. + +While LZO also works with a strict 16-bit memory model, I don't officially +support this because this limits the maximum block size to 64 KiB - and this +makes the library incompatible with other platforms, i.e. you cannot +decompress larger blocks compressed on those platforms. + + +2.2 Public integral types +------------------------- + +lzo_uint + + used as size_t, must be 32 bits or more for compatibility reasons + +lzo_uint32 + + *must* be 32 bits or more + +lzo_bool + + can store the values 0 ("false") and 1 ("true") + +lzo_byte + + unsigned char (memory model specific) + + +2.3 Public pointer types +------------------------ + +All pointer types are memory model specific. + +lzo_voidp + + pointer to void + +lzo_bytep + + pointer to unsigned char + +lzo_bytepp + + array of pointers to unsigned char + + +2.4 Public function types +------------------------- + +lzo_compress_t + +lzo_decompress_t + +lzo_optimize_t + +lzo_callback_t + + + +3 Function reference +==================== + + +3.1 Initialization +------------------ + +int lzo_init ( void ); + + This function initializes the LZO library. It must be the first LZO + function you call, and you cannot use any of the other LZO library + functions if the call fails. + + Return value: + Returns LZO_E_OK on success, error code otherwise. + + Note: + This function is actually implemented using a macro. + + +3.2 Compression +--------------- + +All compressors compress the memory block at 'src' with the uncompressed +length 'src_len' to the address given by 'dst'. +The length of the compressed blocked will be returned in the variable +pointed by 'dst_len'. + +The two blocks may overlap under certain conditions (see examples/overlap.c), +thereby allowing "in-place" compression. + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +#include <lzo/lzo1x.h> + +int lzo1x_1_compress ( const lzo_bytep src, lzo_uint src_len, + lzo_bytep dst, lzo_uintp dst_len, + lzo_voidp wrkmem ); + + Algorithm: LZO1X + Compression level: LZO1X-1 + Memory requirements: LZO1X_1_MEM_COMPRESS (64 KiB on 32-bit machines) + + This compressor is pretty fast. + + Return value: + Always returns LZO_E_OK (this function can never fail). + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +#include <lzo/lzo1x.h> + +int lzo1x_999_compress ( const lzo_bytep src, lzo_uint src_len, + lzo_bytep dst, lzo_uintp dst_len, + lzo_voidp wrkmem ); + + Algorithm: LZO1X + Compression level: LZO1X-999 + Memory requirements: LZO1X_999_MEM_COMPRESS (448 KiB on 32-bit machines) + + This compressor is quite slow but achieves a good compression + ratio. It is mainly intended for generating pre-compressed data. + + Return value: + Always returns LZO_E_OK (this function can never fail). + + +[ ... lots of other compressors which all follow the same principle ... ] + + + +3.3 Decompression +----------------- + +All decompressors decompress the memory block at 'src' with the compressed +length 'src_len' to the address given by 'dst'. +The length of the decompressed block will be returned in the variable +pointed by 'dst_len' - on error the number of bytes that have +been decompressed so far will be returned. + +The safe decompressors expect that the number of bytes available in +the 'dst' block is passed via the variable pointed by 'dst_len'. + +The two blocks may overlap under certain conditions (see examples/overlap.c), +thereby allowing "in-place" decompression. + + +Description of return values: + + LZO_E_OK + Success. + + LZO_E_INPUT_NOT_CONSUMED + The end of the compressed block has been detected before all + bytes in the compressed block have been used. + This may actually not be an error (if 'src_len' is too large). + + LZO_E_INPUT_OVERRUN + The decompressor requested more bytes from the compressed + block than available. + Your data is corrupted (or 'src_len' is too small). + + LZO_E_OUTPUT_OVERRUN + The decompressor requested to write more bytes to the uncompressed + block than available. + Either your data is corrupted, or you should increase the number of + available bytes passed in the variable pointed by 'dst_len'. + + LZO_E_LOOKBEHIND_OVERRUN + Your data is corrupted. + + LZO_E_EOF_NOT_FOUND + No EOF code was found in the compressed block. + Your data is corrupted (or 'src_len' is too small). + + LZO_E_ERROR + Any other error (data corrupted). + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +#include <lzo1x.h> + +int lzo1x_decompress ( const lzo_bytep src, lzo_uint src_len, + lzo_bytep dst, lzo_uintp dst_len, + lzo_voidp wrkmem ); + + Algorithm: LZO1X + Memory requirements: 0 + + +[ ... lots of other decompressors which all follow the same principle ... ] + + + +4 Variable reference +==================== + +The variables are listed alphabetically. + +[ no public variables yet ] + + + +--------------------------- END OF LZOAPI.TXT ------------------------------ + diff --git a/doc/LZOTEST.TXT b/doc/LZOTEST.TXT new file mode 100644 index 0000000..93c8659 --- /dev/null +++ b/doc/LZOTEST.TXT @@ -0,0 +1,75 @@ +The test driver 'lzotest' has grown into a fairly powerful program +of it's own. Here is a short description of the various options. + +[ to be written - this is only a very first draft ] + + +Usage: +====== + +lzotest [option..] file... + + +Basic options: +============== + + -m# compression method + -b# set input block size (default 262144, max 1310720) + -n# number of compression/decompression runs + -c# number of compression runs + -d# number of decompression runs + -S use safe decompressor (if available) + -A use assembler decompressor (if available) + -F use fast assembler decompressor (if available) + -O optimize compressed data (if available) + -s DIR process Calgary Corpus test suite in directory 'DIR' + -@ read list of files to compress from stdin + -q be quiet + -L display software license + + +More about '-m': +================ + +Use '-m' to list all available methods. + +You can select methods by number: +-m71 + +You can select methods by name: +-mlzo1x-1 +-mlzo1x-999 +-mlzo1x-1(11) + +You can select some predefined method groups: +-mall +-mlzo +-mm1 +-mm99 +-mm999 +-m1x999 +-m1y999 + +You can specify multiple methods/groups separated by ',': +-m1,2,3,4 +-m1,2,3,4,lzo1x-1,m99,81 + +And finally you can use multiple '-m' options: +-m962,972 -mm99,982,m1 + + +Other options: +============== + +--max-data-length=LEN + +--dict=FILENAME +--max-dict-length=LEN + +--dump=FILENAME + +--adler32 +--crc32 +--execution-time +--totals + |