| 49813 |
ripley |
1 |
///////////////////////////////////////////////////////////////////////////////
|
|
|
2 |
//
|
|
|
3 |
/// \file range_common.h
|
|
|
4 |
/// \brief Common things for range encoder and decoder
|
|
|
5 |
///
|
|
|
6 |
// Authors: Igor Pavlov
|
|
|
7 |
// Lasse Collin
|
|
|
8 |
//
|
|
|
9 |
// This file has been put into the public domain.
|
|
|
10 |
// You can do whatever you want with this file.
|
|
|
11 |
//
|
|
|
12 |
///////////////////////////////////////////////////////////////////////////////
|
|
|
13 |
|
|
|
14 |
#ifndef LZMA_RANGE_COMMON_H
|
|
|
15 |
#define LZMA_RANGE_COMMON_H
|
|
|
16 |
|
|
|
17 |
#ifdef HAVE_CONFIG_H
|
|
|
18 |
# include "common.h"
|
|
|
19 |
#endif
|
|
|
20 |
|
|
|
21 |
|
|
|
22 |
///////////////
|
|
|
23 |
// Constants //
|
|
|
24 |
///////////////
|
|
|
25 |
|
|
|
26 |
#define RC_SHIFT_BITS 8
|
|
|
27 |
#define RC_TOP_BITS 24
|
|
|
28 |
#define RC_TOP_VALUE (UINT32_C(1) << RC_TOP_BITS)
|
|
|
29 |
#define RC_BIT_MODEL_TOTAL_BITS 11
|
|
|
30 |
#define RC_BIT_MODEL_TOTAL (UINT32_C(1) << RC_BIT_MODEL_TOTAL_BITS)
|
|
|
31 |
#define RC_MOVE_BITS 5
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
////////////
|
|
|
35 |
// Macros //
|
|
|
36 |
////////////
|
|
|
37 |
|
|
|
38 |
// Resets the probability so that both 0 and 1 have probability of 50 %
|
|
|
39 |
#define bit_reset(prob) \
|
|
|
40 |
prob = RC_BIT_MODEL_TOTAL >> 1
|
|
|
41 |
|
|
|
42 |
// This does the same for a complete bit tree.
|
|
|
43 |
// (A tree represented as an array.)
|
|
|
44 |
#define bittree_reset(probs, bit_levels) \
|
|
|
45 |
for (uint32_t bt_i = 0; bt_i < (1 << (bit_levels)); ++bt_i) \
|
|
|
46 |
bit_reset((probs)[bt_i])
|
|
|
47 |
|
|
|
48 |
|
|
|
49 |
//////////////////////
|
|
|
50 |
// Type definitions //
|
|
|
51 |
//////////////////////
|
|
|
52 |
|
|
|
53 |
/// \brief Type of probabilities used with range coder
|
|
|
54 |
///
|
|
|
55 |
/// This needs to be at least 12-bit integer, so uint16_t is a logical choice.
|
|
|
56 |
/// However, on some architecture and compiler combinations, a bigger type
|
|
|
57 |
/// may give better speed, because the probability variables are accessed
|
|
|
58 |
/// a lot. On the other hand, bigger probability type increases cache
|
|
|
59 |
/// footprint, since there are 2 to 14 thousand probability variables in
|
|
|
60 |
/// LZMA (assuming the limit of lc + lp <= 4; with lc + lp <= 12 there
|
|
|
61 |
/// would be about 1.5 million variables).
|
|
|
62 |
///
|
|
|
63 |
/// With malicious files, the initialization speed of the LZMA decoder can
|
|
|
64 |
/// become important. In that case, smaller probability variables mean that
|
|
|
65 |
/// there is less bytes to write to RAM, which makes initialization faster.
|
|
|
66 |
/// With big probability type, the initialization can become so slow that it
|
|
|
67 |
/// can be a problem e.g. for email servers doing virus scanning.
|
|
|
68 |
///
|
|
|
69 |
/// I will be sticking to uint16_t unless some specific architectures
|
|
|
70 |
/// are *much* faster (20-50 %) with uint32_t.
|
|
|
71 |
typedef uint16_t probability;
|
|
|
72 |
|
|
|
73 |
#endif
|
The R Project SVN
R