From owner-cvs-all Fri Feb 23 8:56:32 2001 Delivered-To: cvs-all@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id A710137B401; Fri, 23 Feb 2001 08:56:23 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f1NGu7K24650; Fri, 23 Feb 2001 08:56:07 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f1NGtQe74794; Fri, 23 Feb 2001 08:55:26 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 23 Feb 2001 08:55:26 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Bruce Evans Subject: Re: cvs commit: src/sys/alpha/alpha swtch.s Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Doug Rabson Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Feb-01 Bruce Evans wrote: > On Thu, 22 Feb 2001, John Baldwin wrote: > >> I've thought about doing that, yes. If you want, I can stick it on my todo >> list. Also, I have managed to make userret() and ast() (modulo a few >> commits >> coming up in the next 15 minutes or so) the same across all architectures. >> Do you think that given that it would be feasible to move those two >> functions >> to sys/kern/subr_trap.c and let them be MI? > > I'm not sure that ast() should be MI. It was in hardware on vaxes. There's an IPL level on teh alphas for software interrupts that we don't use at the moment as well. >> Also, as a sidenote, I think that addupc_task() should take a uniptr_t, not >> a >> uint64_t as its second argument.. > > Nah, uniptr_t (sic) only exists on vaxes where all types are the same :-). > > I think it should take a register_t or uintfptr_t. uintptr_t is only > required to work for object pointers. Instruction pointer values in > trap frames aren't even C pointers. They normally (should) have type > register_t. However, the parts of the profiling code that I cleaned > up used uintfptr_t or intfptr_t for representing instruction pointer > values. Hmm, I take it the 'f' isn't some weird variant of 'instruction', so there is no generic 'instruction address' type that we can use, so we (ab)use uintfptr_t instead? (Not that uintptr_t isn't a similar abuse for data pointers. :) > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message