ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/cvsroot/libecb/ecb.pod
(Generate patch)

Comparing cvsroot/libecb/ecb.pod (file contents):
Revision 1.27 by root, Wed Jun 1 01:29:36 2011 UTC vs.
Revision 1.57 by root, Thu Oct 16 14:47:20 2014 UTC

54only a generic name is used (C<expr>, C<cond>, C<value> and so on), then 54only a generic name is used (C<expr>, C<cond>, C<value> and so on), then
55the corresponding function relies on C to implement the correct types, and 55the corresponding function relies on C to implement the correct types, and
56is usually implemented as a macro. Specifically, a "bool" in this manual 56is usually implemented as a macro. Specifically, a "bool" in this manual
57refers to any kind of boolean value, not a specific type. 57refers to any kind of boolean value, not a specific type.
58 58
59=head2 TYPES / TYPE SUPPORT
60
61ecb.h makes sure that the following types are defined (in the expected way):
62
63 int8_t uint8_t int16_t uint16_t
64 int32_t uint32_t int64_t uint64_t
65 intptr_t uintptr_t
66
67The macro C<ECB_PTRSIZE> is defined to the size of a pointer on this
68platform (currently C<4> or C<8>) and can be used in preprocessor
69expressions.
70
71For C<ptrdiff_t> and C<size_t> use C<stddef.h>.
72
73=head2 LANGUAGE/COMPILER VERSIONS
74
75All the following symbols expand to an expression that can be tested in
76preprocessor instructions as well as treated as a boolean (use C<!!> to
77ensure it's either C<0> or C<1> if you need that).
78
79=over 4
80
81=item ECB_C
82
83True if the implementation defines the C<__STDC__> macro to a true value,
84while not claiming to be C++.
85
86=item ECB_C99
87
88True if the implementation claims to be compliant to C99 (ISO/IEC
899899:1999) or any later version, while not claiming to be C++.
90
91Note that later versions (ECB_C11) remove core features again (for
92example, variable length arrays).
93
94=item ECB_C11
95
96True if the implementation claims to be compliant to C11 (ISO/IEC
979899:2011) or any later version, while not claiming to be C++.
98
99=item ECB_CPP
100
101True if the implementation defines the C<__cplusplus__> macro to a true
102value, which is typically true for C++ compilers.
103
104=item ECB_CPP11
105
106True if the implementation claims to be compliant to ISO/IEC 14882:2011
107(C++11) or any later version.
108
109=item ECB_GCC_VERSION (major, minor)
110
111Expands to a true value (suitable for testing in by the preprocessor)
112if the compiler used is GNU C and the version is the given version, or
113higher.
114
115This macro tries to return false on compilers that claim to be GCC
116compatible but aren't.
117
118=item ECB_EXTERN_C
119
120Expands to C<extern "C"> in C++, and a simple C<extern> in C.
121
122This can be used to declare a single external C function:
123
124 ECB_EXTERN_C int printf (const char *format, ...);
125
126=item ECB_EXTERN_C_BEG / ECB_EXTERN_C_END
127
128These two macros can be used to wrap multiple C<extern "C"> definitions -
129they expand to nothing in C.
130
131They are most useful in header files:
132
133 ECB_EXTERN_C_BEG
134
135 int mycfun1 (int x);
136 int mycfun2 (int x);
137
138 ECB_EXTERN_C_END
139
140=item ECB_STDFP
141
142If this evaluates to a true value (suitable for testing in by the
143preprocessor), then C<float> and C<double> use IEEE 754 single/binary32
144and double/binary64 representations internally I<and> the endianness of
145both types match the endianness of C<uint32_t> and C<uint64_t>.
146
147This means you can just copy the bits of a C<float> (or C<double>) to an
148C<uint32_t> (or C<uint64_t>) and get the raw IEEE 754 bit representation
149without having to think about format or endianness.
150
151This is true for basically all modern platforms, although F<ecb.h> might
152not be able to deduce this correctly everywhere and might err on the safe
153side.
154
155=item ECB_AMD64, ECB_AMD64_X32
156
157These two macros are defined to C<1> on the x86_64/amd64 ABI and the X32
158ABI, respectively, and undefined elsewhere.
159
160The designers of the new X32 ABI for some inexplicable reason decided to
161make it look exactly like amd64, even though it's completely incompatible
162to that ABI, breaking about every piece of software that assumed that
163C<__x86_64> stands for, well, the x86-64 ABI, making these macros
164necessary.
165
166=back
167
59=head2 GCC ATTRIBUTES 168=head2 GCC ATTRIBUTES
60 169
61A major part of libecb deals with GCC attributes. These are additional 170A major part of libecb deals with GCC attributes. These are additional
62attributes that you can assign to functions, variables and sometimes even 171attributes that you can assign to functions, variables and sometimes even
63types - much like C<const> or C<volatile> in C. 172types - much like C<const> or C<volatile> in C.
76 185
77=over 4 186=over 4
78 187
79=item ecb_attribute ((attrs...)) 188=item ecb_attribute ((attrs...))
80 189
81A simple wrapper that expands to C<__attribute__((attrs))> on GCC, and to 190A simple wrapper that expands to C<__attribute__((attrs))> on GCC 3.1+ and
82nothing on other compilers, so the effect is that only GCC sees these. 191Clang 2.8+, and to nothing on other compilers, so the effect is that only
192GCC and Clang see these.
83 193
84Example: use the C<deprecated> attribute on a function. 194Example: use the C<deprecated> attribute on a function.
85 195
86 ecb_attribute((__deprecated__)) void 196 ecb_attribute((__deprecated__)) void
87 do_not_use_me_anymore (void); 197 do_not_use_me_anymore (void);
101 #else 211 #else
102 return 0; 212 return 0;
103 #endif 213 #endif
104 } 214 }
105 215
216=item ecb_deprecated
217
218Similar to C<ecb_unused>, but marks a function, variable or type as
219deprecated. This makes some compilers warn when the type is used.
220
221=item ecb_inline
222
223This is not actually an attribute, but you use it like one. It expands
224either to C<static inline> or to just C<static>, if inline isn't
225supported. It should be used to declare functions that should be inlined,
226for code size or speed reasons.
227
228Example: inline this function, it surely will reduce codesize.
229
230 ecb_inline int
231 negmul (int a, int b)
232 {
233 return - (a * b);
234 }
235
106=item ecb_noinline 236=item ecb_noinline
107 237
108Prevent a function from being inlined - it might be optimised away, but 238Prevent a function from being inlined - it might be optimised away, but
109not inlined into other functions. This is useful if you know your function 239not inlined into other functions. This is useful if you know your function
110is rarely called and large enough for inlining not to be helpful. 240is rarely called and large enough for inlining not to be helpful.
123 } 253 }
124 254
125In this case, the compiler would probably be smart enough to deduce it on 255In this case, the compiler would probably be smart enough to deduce it on
126its own, so this is mainly useful for declarations. 256its own, so this is mainly useful for declarations.
127 257
258=item ecb_restrict
259
260Expands to the C<restrict> keyword or equivalent on compilers that support
261them, and to nothing on others. Must be specified on a pointer type or
262an array index to indicate that the memory doesn't alias with any other
263restricted pointer in the same scope.
264
265Example: multiply a vector, and allow the compiler to parallelise the
266loop, because it knows it doesn't overwrite input values.
267
268 void
269 multiply (float *ecb_restrict src,
270 float *ecb_restrict dst,
271 int len, float factor)
272 {
273 int i;
274
275 for (i = 0; i < len; ++i)
276 dst [i] = src [i] * factor;
277 }
278
128=item ecb_const 279=item ecb_const
129 280
130Declares that the function only depends on the values of its arguments, 281Declares that the function only depends on the values of its arguments,
131much like a mathematical function. It specifically does not read or write 282much like a mathematical function. It specifically does not read or write
132any memory any arguments might point to, global variables, or call any 283any memory any arguments might point to, global variables, or call any
192functions only called in exceptional or rare cases. 343functions only called in exceptional or rare cases.
193 344
194=item ecb_artificial 345=item ecb_artificial
195 346
196Declares the function as "artificial", in this case meaning that this 347Declares the function as "artificial", in this case meaning that this
197function is not really mean to be a function, but more like an accessor 348function is not really meant to be a function, but more like an accessor
198- many methods in C++ classes are mere accessor functions, and having a 349- many methods in C++ classes are mere accessor functions, and having a
199crash reported in such a method, or single-stepping through them, is not 350crash reported in such a method, or single-stepping through them, is not
200usually so helpful, especially when it's inlined to just a few instructions. 351usually so helpful, especially when it's inlined to just a few instructions.
201 352
202Marking them as artificial will instruct the debugger about just this, 353Marking them as artificial will instruct the debugger about just this,
381After processing the node, (part of) the next node might already be in 532After processing the node, (part of) the next node might already be in
382cache. 533cache.
383 534
384=back 535=back
385 536
386=head2 BIT FIDDLING / BITSTUFFS 537=head2 BIT FIDDLING / BIT WIZARDRY
387 538
388=over 4 539=over 4
389 540
390=item bool ecb_big_endian () 541=item bool ecb_big_endian ()
391 542
397 548
398On systems that are neither, their return values are unspecified. 549On systems that are neither, their return values are unspecified.
399 550
400=item int ecb_ctz32 (uint32_t x) 551=item int ecb_ctz32 (uint32_t x)
401 552
553=item int ecb_ctz64 (uint64_t x)
554
402Returns the index of the least significant bit set in C<x> (or 555Returns the index of the least significant bit set in C<x> (or
403equivalently the number of bits set to 0 before the least significant bit 556equivalently the number of bits set to 0 before the least significant bit
404set), starting from 0. If C<x> is 0 the result is undefined. A common use 557set), starting from 0. If C<x> is 0 the result is undefined.
405case is to compute the integer binary logarithm, i.e., C<floor (log2 558
559For smaller types than C<uint32_t> you can safely use C<ecb_ctz32>.
560
406(n))>. For example: 561For example:
407 562
408 ecb_ctz32 (3) = 0 563 ecb_ctz32 (3) = 0
409 ecb_ctz32 (6) = 1 564 ecb_ctz32 (6) = 1
410 565
566=item bool ecb_is_pot32 (uint32_t x)
567
568=item bool ecb_is_pot64 (uint32_t x)
569
570Return true iff C<x> is a power of two or C<x == 0>.
571
572For smaller types then C<uint32_t> you can safely use C<ecb_is_pot32>.
573
574=item int ecb_ld32 (uint32_t x)
575
576=item int ecb_ld64 (uint64_t x)
577
578Returns the index of the most significant bit set in C<x>, or the number
579of digits the number requires in binary (so that C<< 2**ld <= x <
5802**(ld+1) >>). If C<x> is 0 the result is undefined. A common use case is
581to compute the integer binary logarithm, i.e. C<floor (log2 (n))>, for
582example to see how many bits a certain number requires to be encoded.
583
584This function is similar to the "count leading zero bits" function, except
585that that one returns how many zero bits are "in front" of the number (in
586the given data type), while C<ecb_ld> returns how many bits the number
587itself requires.
588
589For smaller types than C<uint32_t> you can safely use C<ecb_ld32>.
590
411=item int ecb_popcount32 (uint32_t x) 591=item int ecb_popcount32 (uint32_t x)
412 592
593=item int ecb_popcount64 (uint64_t x)
594
413Returns the number of bits set to 1 in C<x>. For example: 595Returns the number of bits set to 1 in C<x>.
596
597For smaller types than C<uint32_t> you can safely use C<ecb_popcount32>.
598
599For example:
414 600
415 ecb_popcount32 (7) = 3 601 ecb_popcount32 (7) = 3
416 ecb_popcount32 (255) = 8 602 ecb_popcount32 (255) = 8
417 603
604=item uint8_t ecb_bitrev8 (uint8_t x)
605
606=item uint16_t ecb_bitrev16 (uint16_t x)
607
608=item uint32_t ecb_bitrev32 (uint32_t x)
609
610Reverses the bits in x, i.e. the MSB becomes the LSB, MSB-1 becomes LSB+1
611and so on.
612
613Example:
614
615 ecb_bitrev8 (0xa7) = 0xea
616 ecb_bitrev32 (0xffcc4411) = 0x882233ff
617
418=item uint32_t ecb_bswap16 (uint32_t x) 618=item uint32_t ecb_bswap16 (uint32_t x)
419 619
420=item uint32_t ecb_bswap32 (uint32_t x) 620=item uint32_t ecb_bswap32 (uint32_t x)
421 621
622=item uint64_t ecb_bswap64 (uint64_t x)
623
422These two functions return the value of the 16-bit (32-bit) value C<x> 624These functions return the value of the 16-bit (32-bit, 64-bit) value
423after reversing the order of bytes (0x11223344 becomes 0x44332211). 625C<x> after reversing the order of bytes (0x11223344 becomes 0x44332211 in
626C<ecb_bswap32>).
627
628=item uint8_t ecb_rotl8 (uint8_t x, unsigned int count)
629
630=item uint16_t ecb_rotl16 (uint16_t x, unsigned int count)
631
632=item uint32_t ecb_rotl32 (uint32_t x, unsigned int count)
633
634=item uint64_t ecb_rotl64 (uint64_t x, unsigned int count)
635
636=item uint8_t ecb_rotr8 (uint8_t x, unsigned int count)
637
638=item uint16_t ecb_rotr16 (uint16_t x, unsigned int count)
424 639
425=item uint32_t ecb_rotr32 (uint32_t x, unsigned int count) 640=item uint32_t ecb_rotr32 (uint32_t x, unsigned int count)
426 641
427=item uint32_t ecb_rotl32 (uint32_t x, unsigned int count) 642=item uint64_t ecb_rotr64 (uint64_t x, unsigned int count)
428 643
429These two functions return the value of C<x> after rotating all the bits 644These two families of functions return the value of C<x> after rotating
430by C<count> positions to the right or left respectively. 645all the bits by C<count> positions to the right (C<ecb_rotr>) or left
646(C<ecb_rotl>).
431 647
432Current GCC versions understand these functions and usually compile them 648Current GCC versions understand these functions and usually compile them
433to "optimal" code (e.g. a single C<roll> on x86). 649to "optimal" code (e.g. a single C<rol> or a combination of C<shld> on
650x86).
651
652=back
653
654=head2 FLOATING POINT FIDDLING
655
656=over 4
657
658=item uint32_t ecb_float_to_binary32 (float x) [-UECB_NO_LIBM]
659
660=item uint64_t ecb_double_to_binary64 (double x) [-UECB_NO_LIBM]
661
662These functions each take an argument in the native C<float> or C<double>
663type and return the IEEE 754 bit representation of it.
664
665The bit representation is just as IEEE 754 defines it, i.e. the sign bit
666will be the most significant bit, followed by exponent and mantissa.
667
668This function should work even when the native floating point format isn't
669IEEE compliant, of course at a speed and code size penalty, and of course
670also within reasonable limits (it tries to convert NaNs, infinities and
671denormals, but will likely convert negative zero to positive zero).
672
673On all modern platforms (where C<ECB_STDFP> is true), the compiler should
674be able to optimise away this function completely.
675
676These functions can be helpful when serialising floats to the network - you
677can serialise the return value like a normal uint32_t/uint64_t.
678
679Another use for these functions is to manipulate floating point values
680directly.
681
682Silly example: toggle the sign bit of a float.
683
684 /* On gcc-4.7 on amd64, */
685 /* this results in a single add instruction to toggle the bit, and 4 extra */
686 /* instructions to move the float value to an integer register and back. */
687
688 x = ecb_binary32_to_float (ecb_float_to_binary32 (x) ^ 0x80000000U)
689
690=item float ecb_binary32_to_float (uint32_t x) [-UECB_NO_LIBM]
691
692=item double ecb_binary32_to_double (uint64_t x) [-UECB_NO_LIBM]
693
694The reverse operation of the previos function - takes the bit representation
695of an IEEE binary32 or binary64 number and converts it to the native C<float>
696or C<double> format.
697
698This function should work even when the native floating point format isn't
699IEEE compliant, of course at a speed and code size penalty, and of course
700also within reasonable limits (it tries to convert normals and denormals,
701and might be lucky for infinities, and with extraordinary luck, also for
702negative zero).
703
704On all modern platforms (where C<ECB_STDFP> is true), the compiler should
705be able to optimise away this function completely.
434 706
435=back 707=back
436 708
437=head2 ARITHMETIC 709=head2 ARITHMETIC
438 710
448C<ecb_mod> implements the mathematical modulo operation, which is missing 720C<ecb_mod> implements the mathematical modulo operation, which is missing
449in the language. 721in the language.
450 722
451C<n> must be strictly positive (i.e. C<< >= 1 >>), while C<m> must be 723C<n> must be strictly positive (i.e. C<< >= 1 >>), while C<m> must be
452negatable, that is, both C<m> and C<-m> must be representable in its 724negatable, that is, both C<m> and C<-m> must be representable in its
453type (this typically includes the minimum signed integer value, the same 725type (this typically excludes the minimum signed integer value, the same
454limitation as for C</> and C<%> in C). 726limitation as for C</> and C<%> in C).
455 727
456Current GCC versions compile this into an efficient branchless sequence on 728Current GCC versions compile this into an efficient branchless sequence on
457many systems. 729almost all CPUs.
458 730
459For example, when you want to rotate forward through the members of an 731For example, when you want to rotate forward through the members of an
460array for increasing C<m> (which might be negative), then you should use 732array for increasing C<m> (which might be negative), then you should use
461C<ecb_mod>, as the C<%> operator might give either negative results, or 733C<ecb_mod>, as the C<%> operator might give either negative results, or
462change direction for negative values: 734change direction for negative values:
463 735
464 for (m = -100; m <= 100; ++m) 736 for (m = -100; m <= 100; ++m)
465 int elem = myarray [ecb_mod (m, ecb_array_length (myarray))]; 737 int elem = myarray [ecb_mod (m, ecb_array_length (myarray))];
466 738
739=item x = ecb_div_rd (val, div)
740
741=item x = ecb_div_ru (val, div)
742
743Returns C<val> divided by C<div> rounded down or up, respectively.
744C<val> and C<div> must have integer types and C<div> must be strictly
745positive. Note that these functions are implemented with macros in C
746and with function templates in C++.
747
467=back 748=back
468 749
469=head2 UTILITY 750=head2 UTILITY
470 751
471=over 4 752=over 4
480 for (i = 0; i < ecb_array_length (primes); i++) 761 for (i = 0; i < ecb_array_length (primes); i++)
481 sum += primes [i]; 762 sum += primes [i];
482 763
483=back 764=back
484 765
766=head2 SYMBOLS GOVERNING COMPILATION OF ECB.H ITSELF
485 767
768These symbols need to be defined before including F<ecb.h> the first time.
769
770=over 4
771
772=item ECB_NO_THREADS
773
774If F<ecb.h> is never used from multiple threads, then this symbol can
775be defined, in which case memory fences (and similar constructs) are
776completely removed, leading to more efficient code and fewer dependencies.
777
778Setting this symbol to a true value implies C<ECB_NO_SMP>.
779
780=item ECB_NO_SMP
781
782The weaker version of C<ECB_NO_THREADS> - if F<ecb.h> is used from
783multiple threads, but never concurrently (e.g. if the system the program
784runs on has only a single CPU with a single core, no hyperthreading and so
785on), then this symbol can be defined, leading to more efficient code and
786fewer dependencies.
787
788=item ECB_NO_LIBM
789
790When defined to C<1>, do not export any functions that might introduce
791dependencies on the math library (usually called F<-lm>) - these are
792marked with [-UECB_NO_LIBM].
793
794=back
795
796

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines