… | |
… | |
10 | |
10 | |
11 | Its homepage can be found here: |
11 | Its homepage can be found here: |
12 | |
12 | |
13 | http://software.schmorp.de/pkg/libecb |
13 | http://software.schmorp.de/pkg/libecb |
14 | |
14 | |
15 | It mainly provides a number of wrappers around GCC built-ins, together |
15 | It mainly provides a number of wrappers around many compiler built-ins, |
16 | with replacement functions for other compilers. In addition to this, |
16 | together with replacement functions for other compilers. In addition |
17 | it provides a number of other lowlevel C utilities, such as endianness |
17 | to this, it provides a number of other lowlevel C utilities, such as |
18 | detection, byte swapping or bit rotations. |
18 | endianness detection, byte swapping or bit rotations. |
19 | |
19 | |
20 | Or in other words, things that should be built into any standard C system, |
20 | Or in other words, things that should be built into any standard C |
21 | but aren't, implemented as efficient as possible with GCC, and still |
21 | system, but aren't, implemented as efficient as possible with GCC (clang, |
22 | correct with other compilers. |
22 | msvc...), and still correct with other compilers. |
23 | |
23 | |
24 | More might come. |
24 | More might come. |
25 | |
25 | |
26 | =head2 ABOUT THE HEADER |
26 | =head2 ABOUT THE HEADER |
27 | |
27 | |
… | |
… | |
235 | =over 4 |
235 | =over 4 |
236 | |
236 | |
237 | =item ecb_unused |
237 | =item ecb_unused |
238 | |
238 | |
239 | Marks a function or a variable as "unused", which simply suppresses a |
239 | Marks a function or a variable as "unused", which simply suppresses a |
240 | warning by GCC when it detects it as unused. This is useful when you e.g. |
240 | warning by the compiler when it detects it as unused. This is useful when |
241 | declare a variable but do not always use it: |
241 | you e.g. declare a variable but do not always use it: |
242 | |
242 | |
243 | { |
243 | { |
244 | ecb_unused int var; |
244 | ecb_unused int var; |
245 | |
245 | |
246 | #ifdef SOMECONDITION |
246 | #ifdef SOMECONDITION |
… | |
… | |
725 | |
725 | |
726 | These two families of functions return the value of C<x> after rotating |
726 | These two families of functions return the value of C<x> after rotating |
727 | all the bits by C<count> positions to the right (C<ecb_rotr>) or left |
727 | all the bits by C<count> positions to the right (C<ecb_rotr>) or left |
728 | (C<ecb_rotl>). |
728 | (C<ecb_rotl>). |
729 | |
729 | |
730 | Current GCC versions understand these functions and usually compile them |
730 | Current GCC/clang versions understand these functions and usually compile |
731 | to "optimal" code (e.g. a single C<rol> or a combination of C<shld> on |
731 | them to "optimal" code (e.g. a single C<rol> or a combination of C<shld> |
732 | x86). |
732 | on x86). |
733 | |
733 | |
734 | =item T ecb_rotl (T x, unsigned int count) [C++] |
734 | =item T ecb_rotl (T x, unsigned int count) [C++] |
735 | |
735 | |
736 | =item T ecb_rotr (T x, unsigned int count) [C++] |
736 | =item T ecb_rotr (T x, unsigned int count) [C++] |
737 | |
737 | |
… | |
… | |
788 | =item T ecb_le_to_host (T v) |
788 | =item T ecb_le_to_host (T v) |
789 | |
789 | |
790 | =item T ecb_host_to_be (T v) |
790 | =item T ecb_host_to_be (T v) |
791 | |
791 | |
792 | =item T ecb_host_to_le (T v) |
792 | =item T ecb_host_to_le (T v) |
|
|
793 | |
|
|
794 | =back |
793 | |
795 | |
794 | These functions work like their C counterparts, above, but use templates, |
796 | These functions work like their C counterparts, above, but use templates, |
795 | which make them useful in generic code. |
797 | which make them useful in generic code. |
796 | |
798 | |
797 | C<T> must be one of C<uint8_t>, C<uint16_t>, C<uint32_t> or C<uint64_t> |
799 | C<T> must be one of C<uint8_t>, C<uint16_t>, C<uint32_t> or C<uint64_t> |
… | |
… | |
1013 | C<n> must be strictly positive (i.e. C<< >= 1 >>), while C<m> must be |
1015 | C<n> must be strictly positive (i.e. C<< >= 1 >>), while C<m> must be |
1014 | negatable, that is, both C<m> and C<-m> must be representable in its |
1016 | negatable, that is, both C<m> and C<-m> must be representable in its |
1015 | type (this typically excludes the minimum signed integer value, the same |
1017 | type (this typically excludes the minimum signed integer value, the same |
1016 | limitation as for C</> and C<%> in C). |
1018 | limitation as for C</> and C<%> in C). |
1017 | |
1019 | |
1018 | Current GCC versions compile this into an efficient branchless sequence on |
1020 | Current GCC/clang versions compile this into an efficient branchless |
1019 | almost all CPUs. |
1021 | sequence on almost all CPUs. |
1020 | |
1022 | |
1021 | For example, when you want to rotate forward through the members of an |
1023 | For example, when you want to rotate forward through the members of an |
1022 | array for increasing C<m> (which might be negative), then you should use |
1024 | array for increasing C<m> (which might be negative), then you should use |
1023 | C<ecb_mod>, as the C<%> operator might give either negative results, or |
1025 | C<ecb_mod>, as the C<%> operator might give either negative results, or |
1024 | change direction for negative values: |
1026 | change direction for negative values: |