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

Comparing libecb/ecb.pod (file contents):
Revision 1.32 by sf-exg, Fri Jun 17 15:55:41 2011 UTC vs.
Revision 1.40 by root, Mon May 28 08:28:26 2012 UTC

…		…
53	C<uint32_t>, then the corresponding function works only with that type. If	53	C<uint32_t>, then the corresponding function works only with that type. If
54	only a generic name is used (C<expr>, C<cond>, C<value> and so on), then	54	only a generic name is used (C<expr>, C<cond>, C<value> and so on), then
55	the corresponding function relies on C to implement the correct types, and	55	the corresponding function relies on C to implement the correct types, and
56	is usually implemented as a macro. Specifically, a "bool" in this manual	56	is usually implemented as a macro. Specifically, a "bool" in this manual
57	refers to any kind of boolean value, not a specific type.	57	refers to any kind of boolean value, not a specific type.
		58
		59	=head2 TYPES / TYPE SUPPORT
		60
		61	ecb.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
		67	The macro C<ECB_PTRSIZE> is defined to the size of a pointer on this
		68	platform (currently C<4> or C<8>).
58		69
59	=head2 GCC ATTRIBUTES	70	=head2 GCC ATTRIBUTES
60		71
61	A major part of libecb deals with GCC attributes. These are additional	72	A major part of libecb deals with GCC attributes. These are additional
62	attributes that you can assign to functions, variables and sometimes even	73	attributes that you can assign to functions, variables and sometimes even
…		…
396	After processing the node, (part of) the next node might already be in	407	After processing the node, (part of) the next node might already be in
397	cache.	408	cache.
398		409
399	=back	410	=back
400		411
401	=head2 BIT FIDDLING / BITSTUFFS	412	=head2 BIT FIDDLING / BIT WIZARDRY
402		413
403	=over 4	414	=over 4
404		415
405	=item bool ecb_big_endian ()	416	=item bool ecb_big_endian ()
406		417
…		…
412		423
413	On systems that are neither, their return values are unspecified.	424	On systems that are neither, their return values are unspecified.
414		425
415	=item int ecb_ctz32 (uint32_t x)	426	=item int ecb_ctz32 (uint32_t x)
416		427
		428	=item int ecb_ctz64 (uint64_t x)
		429
417	Returns the index of the least significant bit set in C<x> (or	430	Returns the index of the least significant bit set in C<x> (or
418	equivalently the number of bits set to 0 before the least significant bit	431	equivalently the number of bits set to 0 before the least significant bit
419	set), starting from 0. If C<x> is 0 the result is undefined. For example:	432	set), starting from 0. If C<x> is 0 the result is undefined.
		433
		434	For smaller types than C<uint32_t> you can safely use C<ecb_ctz32>.
		435
		436	For example:
420		437
421	ecb_ctz32 (3) = 0	438	ecb_ctz32 (3) = 0
422	ecb_ctz32 (6) = 1	439	ecb_ctz32 (6) = 1
423		440
		441	=item int ecb_ld32 (uint32_t x)
		442
		443	=item int ecb_ld64 (uint64_t x)
		444
		445	Returns the index of the most significant bit set in C<x>, or the number
		446	of digits the number requires in binary (so that C<< 2**ld <= x <
		447	2**(ld+1) >>). If C<x> is 0 the result is undefined. A common use case is
		448	to compute the integer binary logarithm, i.e. C<floor (log2 (n))>, for
		449	example to see how many bits a certain number requires to be encoded.
		450
		451	This function is similar to the "count leading zero bits" function, except
		452	that that one returns how many zero bits are "in front" of the number (in
		453	the given data type), while C<ecb_ld> returns how many bits the number
		454	itself requires.
		455
		456	For smaller types than C<uint32_t> you can safely use C<ecb_ld32>.
		457
424	=item int ecb_popcount32 (uint32_t x)	458	=item int ecb_popcount32 (uint32_t x)
425		459
		460	=item int ecb_popcount64 (uint64_t x)
		461
426	Returns the number of bits set to 1 in C<x>. For example:	462	Returns the number of bits set to 1 in C<x>.
		463
		464	For smaller types than C<uint32_t> you can safely use C<ecb_popcount32>.
		465
		466	For example:
427		467
428	ecb_popcount32 (7) = 3	468	ecb_popcount32 (7) = 3
429	ecb_popcount32 (255) = 8	469	ecb_popcount32 (255) = 8
430		470
		471	=item uint8_t ecb_bitrev8 (uint8_t x)
		472
		473	=item uint16_t ecb_bitrev16 (uint16_t x)
		474
		475	=item uint32_t ecb_bitrev32 (uint32_t x)
		476
		477	Reverses the bits in x, i.e. the MSB becomes the LSB, MSB-1 becomes LSB+1
		478	and so on.
		479
		480	Example:
		481
		482	ecb_bitrev8 (0xa7) = 0xea
		483	ecb_bitrev32 (0xffcc4411) = 0x882233ff
		484
431	=item uint32_t ecb_bswap16 (uint32_t x)	485	=item uint32_t ecb_bswap16 (uint32_t x)
432		486
433	=item uint32_t ecb_bswap32 (uint32_t x)	487	=item uint32_t ecb_bswap32 (uint32_t x)
434		488
		489	=item uint64_t ecb_bswap64 (uint64_t x)
		490
435	These two functions return the value of the 16-bit (32-bit) value C<x>	491	These functions return the value of the 16-bit (32-bit, 64-bit) value
436	after reversing the order of bytes (0x11223344 becomes 0x44332211).	492	C<x> after reversing the order of bytes (0x11223344 becomes 0x44332211 in
		493	C<ecb_bswap32>).
		494
		495	=item uint8_t ecb_rotl8 (uint8_t x, unsigned int count)
		496
		497	=item uint16_t ecb_rotl16 (uint16_t x, unsigned int count)
		498
		499	=item uint32_t ecb_rotl32 (uint32_t x, unsigned int count)
		500
		501	=item uint64_t ecb_rotl64 (uint64_t x, unsigned int count)
		502
		503	=item uint8_t ecb_rotr8 (uint8_t x, unsigned int count)
		504
		505	=item uint16_t ecb_rotr16 (uint16_t x, unsigned int count)
437		506
438	=item uint32_t ecb_rotr32 (uint32_t x, unsigned int count)	507	=item uint32_t ecb_rotr32 (uint32_t x, unsigned int count)
439		508
440	=item uint32_t ecb_rotl32 (uint32_t x, unsigned int count)	509	=item uint64_t ecb_rotr64 (uint64_t x, unsigned int count)
441		510
442	These two functions return the value of C<x> after rotating all the bits	511	These two families of functions return the value of C<x> after rotating
443	by C<count> positions to the right or left respectively.	512	all the bits by C<count> positions to the right (C<ecb_rotr>) or left
		513	(C<ecb_rotl>).
444		514
445	Current GCC versions understand these functions and usually compile them	515	Current GCC versions understand these functions and usually compile them
446	to "optimal" code (e.g. a single C<roll> on x86).	516	to "optimal" code (e.g. a single C<rol> or a combination of C<shld> on
		517	x86).
447		518
448	=back	519	=back
449		520
450	=head2 ARITHMETIC	521	=head2 ARITHMETIC
451		522
…		…
475	change direction for negative values:	546	change direction for negative values:
476		547
477	for (m = -100; m <= 100; ++m)	548	for (m = -100; m <= 100; ++m)
478	int elem = myarray [ecb_mod (m, ecb_array_length (myarray))];	549	int elem = myarray [ecb_mod (m, ecb_array_length (myarray))];
479		550
		551	=item x = ecb_div_rd (val, div)
		552
		553	=item x = ecb_div_ru (val, div)
		554
		555	Returns C<val> divided by C<div> rounded down or up, respectively.
		556	C<val> and C<div> must have integer types and C<div> must be strictly
		557	positive. Note that these functions are implemented with macros in C
		558	and with function templates in C++.
		559
480	=back	560	=back
481		561
482	=head2 UTILITY	562	=head2 UTILITY
483		563
484	=over 4	564	=over 4

Diff Legend

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

Comparing libecb/ecb.pod (file contents): Revision 1.32 by sf-exg, Fri Jun 17 15:55:41 2011 UTC vs. Revision 1.40 by root, Mon May 28 08:28:26 2012 UTC

Diff Legend

Comparing libecb/ecb.pod (file contents):
Revision 1.32 by sf-exg, Fri Jun 17 15:55:41 2011 UTC vs.
Revision 1.40 by root, Mon May 28 08:28:26 2012 UTC