Date: Thu, 3 Mar 2016 09:20:22 -0600 From: Justin Hibbits <jhibbits@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r296336 - in head/sys: dev/bhnd dev/pccard dev/pci isa kern sys x86/xen Message-ID: <CAHSQbTBgapDaFMHhdWfQbH4cw4woVeLFgsRSbWjdrSbxPViAmw@mail.gmail.com> In-Reply-To: <20160303164728.W1928@besplex.bde.org> References: <201603030507.u2357ae2098576@repo.freebsd.org> <20160303164728.W1928@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 3, 2016 at 12:18 AM, Bruce Evans <brde@optusnet.com.au> wrote: > On Thu, 3 Mar 2016, Justin Hibbits wrote: > >> Log: >> Replace all resource occurrences of '0UL/~0UL' with '0/~0'. >> >> Summary: >> The idea behind this is '~0ul' is well-defined, and casting to uintmax_t, >> on a >> 32-bit platform, will leave the upper 32 bits as 0. The maximum range of >> a >> resource is 0xFFF.... (all bits of the full type set). By dropping the >> 'ul' >> suffix, C type promotion rules apply, and the sign extension of ~0 on 32 >> bit >> platforms gets it to a type-independent 'unsigned max'. > > > Why not use the correct signed value? This value is -1, not the value, if > any, with all bits 1. All bits 1 might be a trap representation, but it > is unclear if ~0 can give a trap representation or a trap since it is > unclear if the '~' operation acts on padding bits. It is clear that all > bits 1 gives has value -0 in 1's complement if there are no no padding > bits. But -0 has the same value as +0. When converted to an unsigned > type, it loses all traces of its sign, and becomes plain (ufoo_t)0. > > I don't like the plan to change the resource range type to uintmax_t. > 64 bits is just bloat for most 32-bit systems. After fixing all the > hard-coded u_longs, you can just use a typdefed type which should be > uint32_t if possible. > > Bruce The change to uintmax_t has been on the horizon since rman was first introduced in 1998. There is a comment (was in sys/sys/rman.h, now in sys/kern/subr_rman.c) regarding switching to unsigned long long to support 36-bit addressing on IA32. My selfish reasoning for taking on the work now is supporting 36-bit addressing for PowerPC, where device resources are located at physical addresses >4GB. Yes, it could be a machine dependent typedef, but what does that buy us in the grand scheme? The data overhead is not large -- an extra 8 bytes per resource (resource_i), plus 12 (maybe up to 20 depending on how much padding is added) per resource_list_entry. The code penalty is the added code to deal with using 2 registers (on RISC architectures) for each argument in resource related calls, plus the added math. But much of this will get lost in the noise anyway. Any runtime performance penalty is negligible, and only incurred at startup. After resource provisioning it's business as usual. ARMv7, PowerPC, i386, and MIPS32 all support 36-bit addresses. New PowerPC Book-E (e6500 core) supports 40-bit physical address, as does MIPS with XPA. uint32_t typedef would be relevant in only 2 cases: i386 non-PAE, and armv4 (3, if armv7 becomes a separate arch from armv6, but I doubt that'll happen). - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTBgapDaFMHhdWfQbH4cw4woVeLFgsRSbWjdrSbxPViAmw>