From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 14:57:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2161ED86; Wed, 19 Dec 2012 14:57:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE668FC18; Wed, 19 Dec 2012 14:57:19 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJEv5aD027522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 01:57:08 +1100 Date: Thu, 20 Dec 2012 01:57:05 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-Reply-To: <16664.1355926489@critter.freebsd.dk> Message-ID: <20121220012223.F1772@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> <16439.1355922282@critter.freebsd.dk> <20121220005706.I1675@besplex.bde.org> <16664.1355926489@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=BrrFWvr5 c=1 sm=1 a=5xuQJAhXp8AA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=o_YUZdvV9usA:10 a=coF_l0KmdXCzCSlSFisA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Wed, 19 Dec 2012 16:50:55 +0000 Cc: Davide Italiano , Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , Bruce Evans , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:57:21 -0000 On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > -------- > In message <20121220005706.I1675@besplex.bde.org>, Bruce Evans writes: >> On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > >>> Except that for absolute timescales, we're running out of the 32 bits >>> integer part. >> >> Except 32 bit time_t works until 2106 if it is unsigned. > > That's sort of not an option. I think it is. It is just probably not necessary since 32-bit systems will go away before 2038. > The real problem was that time_t was not defined as a floating > point number. That would be convenient too, but bad for efficiency on some systems. Kernels might not be able to use it, and then would have to use an alternative representation, which they should have done all along. >>> [1] A good addition to C would be a general multi-word integer type >>> where you could ask for any int%d_t or uint%d_t you cared for, and >>> have the compiler DTRT. In difference from using a multiword-library, >>> this would still give these types their natural integer behaviour. >> >> That would be convenient, but bad for efficiency if it were actually >> used much. > > You can say that about anything but CPU-native operations, and I doubt > it would be as inefficient as struct bintime, which does not have access > to the carry bit. Yes, I would say that about non-native. It goes against the spirit of C. OTOH, compilers are getting closer to giving full access to the carry bit. I just checked what clang does in a home-made 128-bit add function: % static void __noinline % uadd(struct u *xup, struct u *yup) % { % unsigned long long t; % % t = xup->w[0] + yup->w[0]; % if (t < xup->w[0]) % xup->w[1]++; % xup->w[0] = t; % xup->w[1] += yup->w[1]; % } % % .align 16, 0x90 % .type uadd,@function % uadd: # @uadd % .cfi_startproc % # BB#0: # %entry % movq (%rdi), %rcx % movq 8(%rdi), %rax % addq (%rsi), %rcx gcc generates an additional cmpq instruction here. % jae .LBB2_2 clang uses the carry bit set by the first addition to avoid the comparison, but still branches. % # BB#1: # %if.then % incq %rax % movq %rax, 8(%rdi) This adds 1 explicitly instead of using adcq, but this is the slow path. % .LBB2_2: # %if.end % movq %rcx, (%rdi) % addq 8(%rsi), %rax This is as efficient as possible except for the extra branch, and the branch is almost perfectly predictable. % movq %rax, 8(%rdi) % ret % .Ltmp22: % .size uadd, .Ltmp22-uadd % .cfi_endproc Bruce