From owner-freebsd-arch Wed Oct 31 3:24:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 6840137B401 for ; Wed, 31 Oct 2001 03:24:42 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15ytU8-0001Ed-0Y; Wed, 31 Oct 2001 11:24:40 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9VBNO789659; Wed, 31 Oct 2001 11:23:24 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 31 Oct 2001 11:23:24 +0000 (GMT) From: Doug Rabson To: Marcel Moolenaar Cc: Subject: Re: FYI: A thought on 64-bit time_t on Alpha In-Reply-To: <20011030225720.A39348@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 30 Oct 2001, Marcel Moolenaar wrote: > Gang, > > We all seem to be of the opinion that the 64-bit archs should > have a 64-bit time_t. The question that is unanswered at this > time is whether this includes the Alpha. > > What I want to avoid is that Alpha will continue to be the odd > one even if it's not anymore the only 64-bit arch (or even the > only "other" arch). For some reason I don't think it's a good > idea to have the Alpha cuddle up with i386. Not only will it > be the odd one among the 64-bit archs, it will not stop being > the odd one in the 32-bit camp. > > So, whatever we decide, let's keep in mind that it can harm the > Alpha too if we treat it as an 32-bit arch and not have time_t > be 64-bit. > > From where I'm standing, it looks that the pain of changing the > Alpha is more like a short painful sting, compared to the long > and nagging itch of not changing time_t. I'd rather have the > sting... > > Just FYI, Moving alpha to use 64bit time_t would be hard. We still need to preserve compatiblity with older systems which means rolling new syscalls for all time related calls and compat shims for the old calls. It would be exactly the same amount of work needed to move i386. The main difference with ia64, sparc64 and ppc is that there is no old code to be compatible with so we don't have to bump the syscalls. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message