Date: Sat, 28 Jun 2003 08:30:32 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: deischen@freebsd.org Cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 Message-ID: <20030628153032.GA577@dhcp01.pn.xcllnt.net> In-Reply-To: <Pine.GSO.4.10.10306281003210.24063-100000@pcnet5.pcnet.com> References: <20030628063503.GA37411@dhcp01.pn.xcllnt.net> <Pine.GSO.4.10.10306281003210.24063-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 28, 2003 at 10:06:02AM -0400, Daniel Eischen wrote: > > > > I've started runtime testing and ran into ILP32/LP64 bugs. Attached > > a patch that solve the first problems without affecting i386. The > > patch is intended to illustrate the problem more than it suggest a > > solution. I'm more than happy to test alternative solutions. > > Note that the use of uint32_t instead of unsigned int is mostly > > to mirror the use of fuword32/suword32... > > I don't have any problem with the patch. Is there another > solution you'd rather see, perhaps using 64bit values? I was thinking about using long. fuword/suword is defined in terms of long, so technically it's a bug to have them operate on int. But using long will yield 64-bit fields on 64-bit platforms, and it may just be a waste of space. Although internal alignment and padding may already take up as much space (tm_flags, km_version, km_flags are examples of this). I'm divided on the issue. I prefer using long for it being the best native type, but don't like the immediate consequence of it being too variable for use in interface types (take for example the 64-bit long on i386 that bde is playing with). With the patch I favored the fixed width property on uint32_t. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030628153032.GA577>