[bind10-dev] numeric/integer size on CC channel

[fujiwara at jprs.co.jp]

We all know assembly languages.

Almost all C++ codes use Element only by configurations and commands
(and sending statistics).  At configuration or command parsing, C++
codes copy Element values into normal variables.
Configurations and commands rarely happen.

Using int64_t on Element does not affect performance, I think.
(Except sending statistics data).

Specifying integer size on CC channel is important.
We did not specify it.

We can choose int32_t or int64_t.

However, do we need to consider performances on old 32bit CPU ?
# Recent C++ compilers on 32bit CPU support 64bit integers.

Python3 already support 64bit or more integers.

--
Kazunori Fujiwara, JPRS <fujiwara at jprs.co.jp>

> From: Mukund Sivaraman <muks at isc.org>
> 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