[ViewVC] Diff of: cvs/libecb/ecb.pod

Comparing libecb/ecb.pod (file contents):
Revision 1.25 by root, Tue May 31 21:52:31 2011 UTC vs.
Revision 1.34 by root, Fri Jun 17 21:16:12 2011 UTC

 refers to any kind of boolean value, not a specific type.
 =head2 GCC ATTRIBUTES
 A major part of libecb deals with GCC attributes. These are additional
-attributes that you cna assign to functions, variables and sometimes even
+attributes that you can assign to functions, variables and sometimes even
 types - much like C<const> or C<volatile> in C.
 While GCC allows declarations to show up in many surprising places,
-but not in many expeted places, the safest way is to put attribute
+but not in many expected places, the safest way is to put attribute
 declarations before the whole declaration:
    ecb_const int mysqrt (int a);
    ecb_unused int i;
     #else
        return 0;
     #endif
   }
+=item ecb_inline
+This is not actually an attribute, but you use it like one. It expands
+either to C<static inline> or to just C<static>, if inline isn't
+supported. It should be used to declare functions that should be inlined,
+for code size or speed reasons.
+Example: inline this function, it surely will reduce codesize.
+   ecb_inline int
+   negmul (int a, int b)
+   {
+     return - (a * b);
+   }
 =item ecb_noinline
 Prevent a function from being inlined - it might be optimised away, but
 not inlined into other functions. This is useful if you know your function
 is rarely called and large enough for inlining not to be helpful.
 In addition to placing cold functions together (or at least away from hot
 functions), this knowledge can be used in other ways, for example, the
 function will be optimised for size, as opposed to speed, and codepaths
 leading to calls to those functions can automatically be marked as if
-C<ecb_unlikely> had been used to reach them.
+C<ecb_expect_false> had been used to reach them.
 Good examples for such functions would be error reporting functions, or
 functions only called in exceptional or rare cases.
 =item ecb_artificial
 Evaluates C<expr> and returns it. In addition, it tells the compiler that
 the C<expr> evaluates to C<value> a lot, which can be used for static
 branch optimisations.
-Usually, you want to use the more intuitive C<ecb_likely> and
+Usually, you want to use the more intuitive C<ecb_expect_true> and
-C<ecb_unlikely> functions instead.
+C<ecb_expect_false> functions instead.
+=item bool ecb_expect_true (cond)
-=item bool ecb_likely (cond)
+=item bool ecb_expect_false (cond)
-=item bool ecb_unlikely (cond)
 These two functions expect a expression that is true or false and return
 C<1> or C<0>, respectively, so when used in the condition of an C<if> or
 other conditional statement, it will not change the program:
   /* these two do the same thing */
   if (some_condition) ...;
-  if (ecb_likely (some_condition)) ...;
+  if (ecb_expect_true (some_condition)) ...;
-However, by using C<ecb_likely>, you tell the compiler that the condition
+However, by using C<ecb_expect_true>, you tell the compiler that the
-is likely to be true (and for C<ecb_unlikely>, that it is unlikely to be
+condition is likely to be true (and for C<ecb_expect_false>, that it is
-true).
+unlikely to be true).
 For example, when you check for a null pointer and expect this to be a
-rare, exceptional, case, then use C<ecb_unlikely>:
+rare, exceptional, case, then use C<ecb_expect_false>:
   void my_free (void *ptr)
   {
-    if (ecb_unlikely (ptr == 0))
+    if (ecb_expect_false (ptr == 0))
       return;
   }
 Consequent use of these functions to mark away exceptional cases or to
 tell the compiler what the hot path through a function is can increase
 performance considerably.
+You might know these functions under the name C<likely> and C<unlikely>
+- while these are common aliases, we find that the expect name is easier
+to understand when quickly skimming code. If you wish, you can use
+C<ecb_likely> instead of C<ecb_expect_true> and C<ecb_unlikely> instead of
+C<ecb_expect_false> - these are simply aliases.
 A very good example is in a function that reserves more space for some
 memory block (for example, inside an implementation of a string stream) -
 each time something is added, you have to check for a buffer overrun, but
 you expect that most checks will turn out to be false:
   /* make sure we have "size" extra room in our buffer */
   ecb_inline void
   reserve (int size)
   {
-    if (ecb_unlikely (current + size > end))
+    if (ecb_expect_false (current + size > end))
       real_reserve_method (size); /* presumably noinline */
   }
 =item bool ecb_assume (cond)
 This can be used to teach the compiler about invariants or other
 conditions that might improve code generation, but which are impossible to
 deduce form the code itself.
-For example, the example reservation function from the C<ecb_unlikely>
+For example, the example reservation function from the C<ecb_expect_false>
 description could be written thus (only C<ecb_assume> was added):
   ecb_inline void
   reserve (int size)
   {
-    if (ecb_unlikely (current + size > end))
+    if (ecb_expect_false (current + size > end))
       real_reserve_method (size); /* presumably noinline */
     ecb_assume (current + size <= end);
   }
 =item int ecb_ctz32 (uint32_t x)
 Returns the index of the least significant bit set in C<x> (or
 equivalently the number of bits set to 0 before the least significant bit
-set), starting from 0. If C<x> is 0 the result is undefined. A common use
+set), starting from 0. If C<x> is 0 the result is undefined. For example:
-case is to compute the integer binary logarithm, i.e.,  C<floor (log2
-(n))>. For example:
   ecb_ctz32 (3) = 0
   ecb_ctz32 (6) = 1
 =item int ecb_popcount32 (uint32_t x)
 =item uint32_t ecb_bswap16 (uint32_t x)
 =item uint32_t ecb_bswap32 (uint32_t x)
+=item uint64_t ecb_bswap64 (uint64_t x)
-These two functions return the value of the 16-bit (32-bit) value C<x>
+These functions return the value of the 16-bit (32-bit, 64-bit) value
-after reversing the order of bytes (0x11223344 becomes 0x44332211).
+C<x> after reversing the order of bytes (0x11223344 becomes 0x44332211 in
+C<ecb_bswap32>).
+=item uint8_t  ecb_rotl8  (uint8_t  x, unsigned int count)
+=item uint16_t ecb_rotl16 (uint16_t x, unsigned int count)
+=item uint32_t ecb_rotl32 (uint32_t x, unsigned int count)
+=item uint64_t ecb_rotl64 (uint64_t x, unsigned int count)
+=item uint8_t  ecb_rotr8  (uint8_t  x, unsigned int count)
+=item uint16_t ecb_rotr16 (uint16_t x, unsigned int count)
 =item uint32_t ecb_rotr32 (uint32_t x, unsigned int count)
-=item uint32_t ecb_rotl32 (uint32_t x, unsigned int count)
+=item uint64_t ecb_rotr64 (uint64_t x, unsigned int count)
-These two functions return the value of C<x> after rotating all the bits
+These two families of functions return the value of C<x> after rotating
-by C<count> positions to the right or left respectively.
+all the bits by C<count> positions to the right (C<ecb_rotr>) or left
+(C<ecb_rotl>).
 Current GCC versions understand these functions and usually compile them
-to "optimal" code (e.g. a single C<roll> on x86).
+to "optimal" code (e.g. a single C<rol> or a combination of C<shld> on
+x86).
 =back
 =head2 ARITHMETIC
 C<ecb_mod> implements the mathematical modulo operation, which is missing
 in the language.
 C<n> must be strictly positive (i.e. C<< >= 1 >>), while C<m> must be
 negatable, that is, both C<m> and C<-m> must be representable in its
-type (this typically includes the minimum signed integer value, the same
+type (this typically excludes the minimum signed integer value, the same
 limitation as for C</> and C<%> in C).
 Current GCC versions compile this into an efficient branchless sequence on
-many systems.
+almost all CPUs.
 For example, when you want to rotate forward through the members of an
 array for increasing C<m> (which might be negative), then you should use
 C<ecb_mod>, as the C<%> operator might give either negative results, or
 change direction for negative values:

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing libecb/ecb.pod (file contents): Revision 1.25 by root, Tue May 31 21:52:31 2011 UTC vs. Revision 1.34 by root, Fri Jun 17 21:16:12 2011 UTC

Diff Legend

Comparing libecb/ecb.pod (file contents):
Revision 1.25 by root, Tue May 31 21:52:31 2011 UTC vs.
Revision 1.34 by root, Fri Jun 17 21:16:12 2011 UTC