[bind10-dev] numeric/integer size on CC channel
Mukund Sivaraman
muks at isc.org
Thu Jun 20 09:45:50 UTC 2013
On Thu, Jun 20, 2013 at 05:34:03PM +0900, fujiwara at jprs.co.jp wrote:
> Question
>
> 1. Do all systems have int64_t and uint64_t (64bit integers) ?
>
> 2. Is there performance problem to use int64_t ?
It is possible for pure 32-bit platforms (that do not have native 64-bit
instructions) to do 64-bit arithmetic using multiple instructions that
use 32-bit operands. In this case, two registers typically hold the
value.
For example, if we're adding (a) 0x123456789abcdef0 with (b)
0xfedcba9876543210 on a 32-bit x86 platform:
uint64_t a = 0x123456789abcdef0;
uint64_t b = 0xfedcba9876543210;
a += b;
Example 32-bit x86 instructions used could be (using intel syntax):
clc ; clear carry flag
mov eax, 12345678h ; registers eax:ebx hold operand a
mov ebx, 9abcdef0h
mov ecx, fedcba98h ; registers ecx:edx hold operand b
mov edx, 76543210h
add ebx, edx ; add lower dwords (= 0x11111100 + carry bit set)
adc eax, ecx ; add upper dwords and add carry bit to it
; (= 0x11111111 + carry bit set)
;; with our sample operands, it still causes 64-bit overflow, so the
;; carry bit is set again.
;;
;; The result is:
;; eax = 0x11111111
;; ebx = 0x11111100
;; carry set.
;; so the result of addition is: 0x1 11111111 11111100
Compilers for 32-bit platforms which implement int64_t do it with an
approach like this. It's not guaranteed that int64_t is available on a
particular compiler.
64-bit multiplication also involves similar code, but a bit more
lengthy.
On 32-bit platforms:
* They use multiple instructions which is slower than native register
sized arithmetic operations.
* The operation is not atomic.
For many generations now, x86 processors provide guarantees that some
instructions that work on aligned register-size operands in memory are
atomic. Much of software do not make use of these guarantees as it's not
portable across all x86 vendors, but you cannot make use of these when
it's no longer a single instruction. Example is to increment a uint64_t
value at some aligned location in memory.
It would require explicit lock instructions when reading/writing
uint64_t sized operands stored in memory if there may be contention for
it.
Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130620/6c7d6c7a/attachment.bin>
More information about the bind10-dev
mailing list