From owner-freebsd-ia64 Sun Oct 21 1:17: 1 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 1428437B403 for ; Sun, 21 Oct 2001 01:16:57 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9L8GqM23436 for ; Sun, 21 Oct 2001 01:16:52 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 8290D380A; Sun, 21 Oct 2001 01:16:52 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Marcel Moolenaar Cc: Doug Rabson , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011020130244.A25443@kayak.xcllnt.net> Date: Sun, 21 Oct 2001 01:16:52 -0700 From: Peter Wemm Message-Id: <20011021081652.8290D380A@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcel Moolenaar wrote: > On Sat, Oct 20, 2001 at 02:46:01PM +0100, Doug Rabson wrote: > > > > I have run all our code through GAS' dependancy checker FWIW. It still > > missed some problems though. > > > > I run our hazard checker on sbin/umount (random pick): > 50 unlikely hazards > 128 potential hazards > 28 certain hazards > > Normally you can ignore the unlikely and potential hazards, because they > are mostly caused by insufficient static information. > > 27 of the 28 certain hazards are no hazards at all, because our > hazard checker was disassembling data. > > Which leaves: > HAZARD (certain) WAW Dependency between 400000000003e500.0 and 400000000003e5 10.2 on p6 > > According to ski this gives: > 400000000003e500 cmp.ge p6=r0,r33 MIB > nop.i 0x0 > ! (p6) br.ret.spnt.few b0 > 400000000003e510 nop.m 0x0 MII > mov.i r14=ar.lc > cmp.ltu p6=17,r33 > > This is clearly a hazard. Is it? The ia64 manual I have suggests that this special case is allowed.. volume 1, section 3.4.1.. It talks about how branches that use predicates set in the same bundle are allowed.. Speculation deals with it. But I get a brain implosion when reading that stuff. :-) > Since bin/csh seems to hang, I repeated the exercise for bin/csh: > 145 certain hazards, of which 143 look like bogus hazards. This leaves: > 1) HAZARD (certain) WAW Dependency between 40000000000d1940.2 and 40000000000 d1960.0 on p6 > 2) HAZARD (certain) WAW Dependency between 400000000013dec0.0 and 40000000001 3ded0.2 on p6 > > Ad 1) Same problem as above: > 40000000000d1940 adds r15=66,r0 MII > break.i 0x100000;; > cmp.ne p6=r0,r10 > 40000000000d1950 nop.m 0x0 MIB > nop.i 0x0 > ! (p6) br.cond.sptk.few 0x4000000000153a70 > 40000000000d1960 cmp.ne p6=r9,r0;; MMI > ! (p6) mov r8=r0 > nop.i 0x0 > > Ad 2) Same problem here: > 400000000013dec0 cmp.ge p6=r0,r33 MIB > nop.i 0x0 > ! (p6) br.ret.spnt.few b0 > 400000000013ded0 nop.m 0x0 MII > mov.i r14=ar.lc > cmp.ltu p6=17,r33 > > This looks like a (structural) compiler bug in GCC-2.9-ia64-final > that GAS isn't catching. We should keep our eyes open for this in > GCC 3.x. I think the reason csh isn't happy is that it depends a lot on setjmp/longjmp and sigsetjmp/siglongjmp.. Doug just committed those functions to libc.. > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ia64" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 1:52:24 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 113C937B406 for ; Sun, 21 Oct 2001 01:52:20 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 15vELC-00063U-0A; Sun, 21 Oct 2001 08:52:18 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9L8p3765340; Sun, 21 Oct 2001 09:51:03 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 21 Oct 2001 09:49:11 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: Marcel Moolenaar , Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011021081652.8290D380A@overcee.netplex.com.au> Message-ID: <20011021094627.F549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 21 Oct 2001, Peter Wemm wrote: > > > > Which leaves: > > HAZARD (certain) WAW Dependency between 400000000003e500.0 and 400000000003e5 > 10.2 on p6 > > > > According to ski this gives: > > 400000000003e500 cmp.ge p6=r0,r33 > MIB > > nop.i 0x0 > > ! (p6) br.ret.spnt.few b0 > > 400000000003e510 nop.m 0x0 > MII > > mov.i r14=ar.lc > > cmp.ltu p6=17,r33 > > > > This is clearly a hazard. > > Is it? The ia64 manual I have suggests that this special case is > allowed.. volume 1, section 3.4.1.. It talks about how branches > that use predicates set in the same bundle are allowed.. Speculation > deals with it. But I get a brain implosion when reading that stuff. :-) A branch can use a predicate that is set in the previous instruction without a stop. This is a special case. > I think the reason csh isn't happy is that it depends a lot on setjmp/longjmp > and sigsetjmp/siglongjmp.. Doug just committed those functions to libc.. Its worse than that. Now csh is dying after taking a signal in the userret from a syscall which has returned ERESTART. We don't save enough information in the sparse trapframe to cope with this so I'm reworking the syscall entry code to save more information. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 2: 1:35 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id A876037B401 for ; Sun, 21 Oct 2001 02:00:27 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9L90Ro01034; Sun, 21 Oct 2001 02:00:27 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9L916700599; Sun, 21 Oct 2001 02:01:06 -0700 (PDT) (envelope-from marcel) Date: Sun, 21 Oct 2001 02:01:06 -0700 From: Marcel Moolenaar To: Peter Wemm Cc: Doug Rabson , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] Message-ID: <20011021020106.A540@dhcp01.pn.xcllnt.net> References: <20011020130244.A25443@kayak.xcllnt.net> <20011021081652.8290D380A@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011021081652.8290D380A@overcee.netplex.com.au> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Oct 21, 2001 at 01:16:52AM -0700, Peter Wemm wrote: > > > > Which leaves: > > HAZARD (certain) WAW Dependency between 400000000003e500.0 and 400000000003e5 > 10.2 on p6 > > > > According to ski this gives: > > 400000000003e500 cmp.ge p6=r0,r33 > MIB > > nop.i 0x0 > > ! (p6) br.ret.spnt.few b0 > > 400000000003e510 nop.m 0x0 > MII > > mov.i r14=ar.lc > > cmp.ltu p6=17,r33 > > > > This is clearly a hazard. > > Is it? The ia64 manual I have suggests that this special case is > allowed.. volume 1, section 3.4.1.. It talks about how branches > that use predicates set in the same bundle are allowed.. Speculation > deals with it. But I get a brain implosion when reading that stuff. :-) :-) It's not the branch that's causing the hazard. It's the second compare (cmp.ltu) that's causing a hazard with the first compare (cmp.ge). If the first compare yields false, the branch is not taken and the second compare will define p6 in the same instruction group. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 3: 6:32 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 4807437B403 for ; Sun, 21 Oct 2001 03:06:26 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9LA6QM23968 for ; Sun, 21 Oct 2001 03:06:26 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 291A038CC; Sun, 21 Oct 2001 03:06:26 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Marcel Moolenaar Cc: Doug Rabson , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011021020106.A540@dhcp01.pn.xcllnt.net> Date: Sun, 21 Oct 2001 03:06:26 -0700 From: Peter Wemm Message-Id: <20011021100626.291A038CC@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcel Moolenaar wrote: > On Sun, Oct 21, 2001 at 01:16:52AM -0700, Peter Wemm wrote: > > > > > > Which leaves: > > > HAZARD (certain) WAW Dependency between 400000000003e500.0 and 4000000000 03e5 > > 10.2 on p6 > > > > > > According to ski this gives: > > > 400000000003e500 cmp.ge p6=r0,r33 > > MIB > > > nop.i 0x0 > > > ! (p6) br.ret.spnt.few b0 > > > 400000000003e510 nop.m 0x0 > > MII > > > mov.i r14=ar.lc > > > cmp.ltu p6=17,r33 > > > > > > This is clearly a hazard. > > > > Is it? The ia64 manual I have suggests that this special case is > > allowed.. volume 1, section 3.4.1.. It talks about how branches > > that use predicates set in the same bundle are allowed.. Speculation > > deals with it. But I get a brain implosion when reading that stuff. :-) > > :-) > > It's not the branch that's causing the hazard. It's the second compare > (cmp.ltu) that's causing a hazard with the first compare (cmp.ge). > If the first compare yields false, the branch is not taken and the > second compare will define p6 in the same instruction group. Doh! I actually looked at that, but the leading ! threw me. For some reason I let it convince me that was what was being flagged. :-) binutils-2.11.2 flags a disturbing number of dependency violations in code produced by the old compiler. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 4: 1:15 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id 7285137B406 for ; Sun, 21 Oct 2001 04:01:10 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 15vGLs-0007vK-0V; Sun, 21 Oct 2001 12:01:08 +0100 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9LAxq765670; Sun, 21 Oct 2001 11:59:52 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 21 Oct 2001 11:58:00 +0100 (BST) From: Doug Rabson To: Marcel Moolenaar Cc: Peter Wemm , Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011021020106.A540@dhcp01.pn.xcllnt.net> Message-ID: <20011021115633.U549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 21 Oct 2001, Marcel Moolenaar wrote: > On Sun, Oct 21, 2001 at 01:16:52AM -0700, Peter Wemm wrote: > > > > > > Which leaves: > > > HAZARD (certain) WAW Dependency between 400000000003e500.0 and 400000000003e5 > > 10.2 on p6 > > > > > > According to ski this gives: > > > 400000000003e500 cmp.ge p6=r0,r33 > > MIB > > > nop.i 0x0 > > > ! (p6) br.ret.spnt.few b0 > > > 400000000003e510 nop.m 0x0 > > MII > > > mov.i r14=ar.lc > > > cmp.ltu p6=17,r33 > > > > > > This is clearly a hazard. > > > > Is it? The ia64 manual I have suggests that this special case is > > allowed.. volume 1, section 3.4.1.. It talks about how branches > > that use predicates set in the same bundle are allowed.. Speculation > > deals with it. But I get a brain implosion when reading that stuff. :-) > > :-) > > It's not the branch that's causing the hazard. It's the second compare > (cmp.ltu) that's causing a hazard with the first compare (cmp.ge). > If the first compare yields false, the branch is not taken and the > second compare will define p6 in the same instruction group. Aah, I see the problem now. What is the function name which contains this code? -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 6:53:18 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id 4F24437B407; Sun, 21 Oct 2001 06:53:16 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 15vJ2Q-0000fN-0K; Sun, 21 Oct 2001 13:53:14 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9LDpw767954; Sun, 21 Oct 2001 14:51:58 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 21 Oct 2001 14:50:06 +0100 (BST) From: Doug Rabson To: "David O'Brien" Cc: Marcel Moolenaar , Subject: Re: Dual-Itanium Lion boots ok. In-Reply-To: <20011018092105.B18621@dragon.nuxi.com> Message-ID: <20011021144912.Q549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 18 Oct 2001, David O'Brien wrote: > On Wed, Oct 17, 2001 at 09:58:06PM -0700, Marcel Moolenaar wrote: > > On Wed, Oct 17, 2001 at 03:05:36PM -0700, David O'Brien wrote: > > > On Mon, Oct 15, 2001 at 11:40:55PM -0700, Marcel Moolenaar wrote: > > > > CPU: Itanium (800.09-Mhz) > > > > Origin = "GenuineIntel" Model = 0 Revision = 6 > > > > Features = 0x0 > > > > > > Any word on fixing the kernel so it works under Ski again? > > > (or a native version :-)) > > > > What's the problem? > > Peter posted output of the problem to this mailing list on Monday. > Surely you have SKI installed somewhere that you (or DFR) could try it > yourselves. :-)) nudge, nudge... Try booting http://people.freebsd.org/~dfr/kernel.ski and see how well that works. If you still have problems, you might need to get Marcel's prototype FreeBSD version of SKI. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 9:54:50 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 55E1C37B403 for ; Sun, 21 Oct 2001 09:54:47 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9LGsYN02281; Sun, 21 Oct 2001 09:54:34 -0700 (PDT) (envelope-from obrien) Date: Sun, 21 Oct 2001 09:54:34 -0700 From: "David O'Brien" To: Doug Rabson Cc: Marcel Moolenaar , ia64@FreeBSD.org Subject: Re: Dual-Itanium Lion boots ok. Message-ID: <20011021095434.A1772@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20011018092105.B18621@dragon.nuxi.com> <20011021144912.Q549-100000@salmon.nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011021144912.Q549-100000@salmon.nlsystems.com>; from dfr@nlsystems.com on Sun, Oct 21, 2001 at 02:50:06PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Oct 21, 2001 at 02:50:06PM +0100, Doug Rabson wrote: > Try booting http://people.freebsd.org/~dfr/kernel.ski and see how well > that works. If you still have problems, you might need to get Marcel's > prototype FreeBSD version of SKI. $ cat ia64.cmd iar fr pa b enter_virtual_mode c b ssc c s 8 bD b ia64_init c $ xski -i ia64.cmd skiload Console: ia64 SKI console FreeBSD/ia64 ia64 SKI boot, Revision 0.1 (root@overcee.netplex.com.au, Mon Oct 15 00:48:15 PDT 2001) / /boot/kernel/kernel data=0x3279a0+0x88720 syms=[0x8+0x2b2d8+0x8+0x23c62] Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. ok 0000e 0000e not found ok boot Entering /boot/kernel/kernel at 0xe00000000050a000... No system table! Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #23: Sun Oct 21 14:42:00 BST 2001 dfr@herring.nlsystems.com:/usr/src/sys/ia64/compile/SKI CPU: Itanium (733.41-Mhz) Origin = "Hewlett-Packard" Model = 0 Revision = 0 Features = 0x1 real memory = 67108864 (65536K bytes) avail memory = 60743680 (59320K bytes) Preloaded elf kernel "/boot/kernel/kernel" at 0xe000000000902000. Timecounter "IA64 ITC" frequency 733409028 Hz Mounting root from ufs:/dev/sscdisk0c sscdisk0c: raw partition size != slice size sscdisk0c: start 0, end 196607, size 196608 sscdisk0cc: start 0, end 24575, size 24576 fatal kernel trap: trap vector = 0x1e (Unaligned Reference) cr.iip = 0xe000000000596f40 cr.ipsr = 0x121008006010 (mfl,ic,i,rt,cpl=0,it,ri=1,bn) cr.isr = 0x20400000000 (r,ei=1) cr.ifa = 0x41 cr.iim = 0x0 curthread = 0xe00000000088ee40 pid = 0, comm = swapper Stopped at nanouptime+0x71: ld4 r14=[r14] db> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 9:59:57 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 4F7C537B403 for ; Sun, 21 Oct 2001 09:59:56 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9LGxf002378; Sun, 21 Oct 2001 09:59:41 -0700 (PDT) (envelope-from obrien) Date: Sun, 21 Oct 2001 09:59:41 -0700 From: "David O'Brien" To: Peter Wemm Cc: Marcel Moolenaar , Doug Rabson , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] Message-ID: <20011021095941.A2340@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20011021020106.A540@dhcp01.pn.xcllnt.net> <20011021100626.291A038CC@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011021100626.291A038CC@overcee.netplex.com.au>; from peter@wemm.org on Sun, Oct 21, 2001 at 03:06:26AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Oct 21, 2001 at 03:06:26AM -0700, Peter Wemm wrote: > binutils-2.11.2 flags a disturbing number of dependency violations in code > produced by the old compiler. Do we have a working makes-it-to-single-user simulator environment again? So I can work on this? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 10: 1:29 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7B0F937B413 for ; Sun, 21 Oct 2001 10:00:13 -0700 (PDT) Received: (from fenner@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f9LH04t36448 for freebsd-ia64@freebsd.org; Sun, 21 Oct 2001 10:00:04 -0700 (PDT) (envelope-from fenner) Date: Sun, 21 Oct 2001 10:00:04 -0700 (PDT) From: Message-Id: <200110211700.f9LH04t36448@freefall.freebsd.org> To: freebsd-ia64@freebsd.org Subject: FreeBSD ports: 1 unfetchable distfiles: emulators/ski Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear freebsd-ia64@freebsd.org, You are listed as the FreeBSD port maintainer for 1 port whose distfiles [or main web pages] are not fetchable from their MASTER_SITES. Could you please visit http://people.freebsd.org/~fenner/portsurvey/freebsd-ia64@freebsd.org.html and correct the problems listed there? The individual port with a problem is emulators/ski. Note that the main port web page, as listed in the WWW: line of the pkg-descr, is checked just as though it was a port distfile. This is an unfortunate side effect of the architecture of the distfile survey reporting system, but if you see a distfile being reported as not fetchable that's not actually a distfile, see if it's from the pkg-descr. If you have already corrected the problems and submitted a PR, please accept my thanks and apologies for the delay in getting the fixes into the tree. This reminder is created automatically and does not (yet) have a way to know if a PR fixing the problem has been submitted. Please do *NOT* submit your response to me directly; I do not always have time to commit your fix; please instead submit a PR via 'send-pr' so it doesn't get lost. Problems are usually of two types: 1. The software package has been upgraded and the version in the port has been removed. The best solution to this problem is to upgrade the port to the most current version of the software package. If you are a FreeBSD committer, then you can just upgrade the port directly. If not, you should create the new port on your own system, test it (and maybe even run "portlint" on it), and then use "send-pr" to submit a "diff -uNr old-port new-port". If you added or deleted any files, please make an explicit note of it. 2. The mirror site being used no longer contains the software package in question, or no longer exists. Solutions include: a) If there are other mirror sites, just remove the bad site from the list. (Make sure that what appears to be a bad site isn't actually a problem of type 1, upgrade) b) If the README or other support files in the software documentation mention where to get the software package, use one of those sites. c) Use ftpsearch (http://ftpsearch.ntnu.no/ftpsearch) or other search engines to find another place to get the original DISTFILES. Make sure that you don't pick a FreeBSD distfiles mirror -- if you can't find any other places where the file exists, it can be a LOCAL_PORT or you can simply comment out the MASTER_SITES= line, with a comment explaining why. Once you have a solution, use "send-pr" to submit a "diff -u" of the Makefile. Note that this isn't an urgent issue, as people who try to build the port now will just fall back to the FreeBSD distfiles mirror. Please just put it on your list to do and get to it when you have time. These messages will continue to arrive twice a month until the fix is committed, as a reminder. Thanks, Bill "distfiles" Fenner. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 12:58:49 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id D7B1237B401 for ; Sun, 21 Oct 2001 12:58:46 -0700 (PDT) Received: (from marcel@localhost) by kayak.xcllnt.net (8.11.4/8.11.4) id f9LJwZN02680; Sun, 21 Oct 2001 12:58:35 -0700 (PDT) (envelope-from marcel) Date: Sun, 21 Oct 2001 12:58:35 -0700 From: Marcel Moolenaar To: Doug Rabson Cc: Peter Wemm , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] Message-ID: <20011021125835.A2668@kayak.xcllnt.net> References: <20011021020106.A540@dhcp01.pn.xcllnt.net> <20011021115633.U549-100000@salmon.nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011021115633.U549-100000@salmon.nlsystems.com> User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Oct 21, 2001 at 11:58:00AM +0100, Doug Rabson wrote: > > > > > > > > According to ski this gives: > > > > 400000000003e500 cmp.ge p6=r0,r33 > > > MIB > > > > nop.i 0x0 > > > > ! (p6) br.ret.spnt.few b0 > > > > 400000000003e510 nop.m 0x0 > > > MII > > > > mov.i r14=ar.lc > > > > cmp.ltu p6=17,r33 > > > > > > Aah, I see the problem now. What is the function name which contains this > code? The function is bzero(). Ouch... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 14: 1:34 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 06D5837B401; Sun, 21 Oct 2001 14:01:32 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 15vPis-0009ff-0U; Sun, 21 Oct 2001 22:01:30 +0100 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9LL0E768689; Sun, 21 Oct 2001 22:00:14 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 21 Oct 2001 21:58:21 +0100 (BST) From: Doug Rabson To: "David O'Brien" Cc: Marcel Moolenaar , Subject: Re: Dual-Itanium Lion boots ok. In-Reply-To: <20011021095434.A1772@dragon.nuxi.com> Message-ID: <20011021215645.N549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 21 Oct 2001, David O'Brien wrote: > fatal kernel trap: > > trap vector = 0x1e (Unaligned Reference) > cr.iip = 0xe000000000596f40 > cr.ipsr = 0x121008006010 (mfl,ic,i,rt,cpl=0,it,ri=1,bn) > cr.isr = 0x20400000000 (r,ei=1) > cr.ifa = 0x41 > cr.iim = 0x0 > curthread = 0xe00000000088ee40 > pid = 0, comm = swapper > > Stopped at nanouptime+0x71: ld4 r14=[r14] > db> Wait! I remember this one. This is where the SSC call to read the clock trashes some entries in the GOT. You either need to get Marcel's latest copy of SKI or you can stub out the clock code in ski_fake_efi_get_time(). -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 14: 3:50 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id F21CD37B406 for ; Sun, 21 Oct 2001 14:03:46 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 15vPl2-000LWw-0A; Sun, 21 Oct 2001 21:03:44 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9LL2T768915; Sun, 21 Oct 2001 22:02:29 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 21 Oct 2001 22:00:36 +0100 (BST) From: Doug Rabson To: Marcel Moolenaar Cc: Peter Wemm , Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011021125835.A2668@kayak.xcllnt.net> Message-ID: <20011021220023.A549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 21 Oct 2001, Marcel Moolenaar wrote: > On Sun, Oct 21, 2001 at 11:58:00AM +0100, Doug Rabson wrote: > > > > > > > > > > According to ski this gives: > > > > > 400000000003e500 cmp.ge p6=r0,r33 > > > > MIB > > > > > nop.i 0x0 > > > > > ! (p6) br.ret.spnt.few b0 > > > > > 400000000003e510 nop.m 0x0 > > > > MII > > > > > mov.i r14=ar.lc > > > > > cmp.ltu p6=17,r33 > > > > > > > > > Aah, I see the problem now. What is the function name which contains this > > code? > > The function is bzero(). Ouch... This ought to fix it: Index: bzero.S =================================================================== RCS file: /home/ncvs/src/lib/libc/ia64/string/bzero.S,v retrieving revision 1.3 diff -u -r1.3 bzero.S --- bzero.S 2001/09/22 18:27:01 1.3 +++ bzero.S 2001/10/21 21:02:03 @@ -32,7 +32,7 @@ cmp.le p6,p0=in1,r0 // bail if len <= 0 (p6) br.ret.spnt.few rp - + ;; mov r14=ar.lc // save ar.lc cmp.ltu p6,p0=17,in1 // check for small -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 14:34:40 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 74C4037B403 for ; Sun, 21 Oct 2001 14:34:35 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9LLYZM25461 for ; Sun, 21 Oct 2001 14:34:35 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 1DFE43803; Sun, 21 Oct 2001 14:34:35 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Doug Rabson Cc: Marcel Moolenaar , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011021220023.A549-100000@salmon.nlsystems.com> Date: Sun, 21 Oct 2001 14:34:35 -0700 From: Peter Wemm Message-Id: <20011021213435.1DFE43803@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Doug Rabson wrote: > On Sun, 21 Oct 2001, Marcel Moolenaar wrote: > > > On Sun, Oct 21, 2001 at 11:58:00AM +0100, Doug Rabson wrote: > > > > > > > > > > > > According to ski this gives: > > > > > > 400000000003e500 cmp.ge p6=r0,r33 > > > > > MIB > > > > > > nop.i 0x0 > > > > > > ! (p6) br.ret.spnt.few b0 > > > > > > 400000000003e510 nop.m 0x0 > > > > > MII > > > > > > mov.i r14=ar.lc > > > > > > cmp.ltu p6=17,r33 > > > > > > > > > > > > Aah, I see the problem now. What is the function name which contains this > > > code? > > > > The function is bzero(). Ouch... > > This ought to fix it: > > Index: bzero.S > =================================================================== > RCS file: /home/ncvs/src/lib/libc/ia64/string/bzero.S,v > retrieving revision 1.3 > diff -u -r1.3 bzero.S > --- bzero.S 2001/09/22 18:27:01 1.3 > +++ bzero.S 2001/10/21 21:02:03 > @@ -32,7 +32,7 @@ > > cmp.le p6,p0=in1,r0 // bail if len <= 0 > (p6) br.ret.spnt.few rp > - > + ;; > mov r14=ar.lc // save ar.lc > > cmp.ltu p6,p0=17,in1 // check for small Interestingly, before this change: peter@overcee[2:19pm]~src/lib/libc/ia64/string-136> ia64-unknown-linux-cpp bzero.S | ia64-unknown-linux-as -x -o bzero.o bzero.S: Assembler messages: bzero.S:38: Warning: Use of 'cmp.ltu' violates WAW dependency 'PR%, % in 1 - 62' (impliedf), specific resource number is 6 bzero.S:38: Warning: Only the first path encountering the conflict is reported bzero.S:33: Warning: This is the location of the conflicting usage bzero.S:38: Warning: Use of 'cmp.ltu' violates WAW dependency 'PR%, % in 1 - 62' (impliedf), specific resource number is 6 bzero.S:38: Warning: Only the first path encountering the conflict is reported bzero.S:33: Warning: This is the location of the conflicting usage peter@overcee[2:19pm]~src/lib/libc/ia64/string-137> That's using the ia64-final assembler.. Using the binutils snapshot that David built a while back from 2.11.2: peter@overcee[2:19pm]~src/lib/libc/ia64/string-137> ia64-unknown-linux-cpp bzero.S | ia64-as -x -o bzero.o bzero.S: Assembler messages: bzero.S:38: Warning: Use of 'cmp.ltu' violates WAW dependency 'PR%, % in 1 - 15' (impliedf), specific resource number is 6 bzero.S:38: Warning: Only the first path encountering the conflict is reported bzero.S:33: Warning: This is the location of the conflicting usage bzero.S:38: Warning: Use of 'cmp.ltu' violates WAW dependency 'PR%, % in 1 - 15' (impliedf), specific resource number is 6 bzero.S:38: Warning: Only the first path encountering the conflict is reported bzero.S:33: Warning: This is the location of the conflicting usage [this we know about] bzero.S:56: Warning: Use of 'tbit.nz' violates RAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 32 bzero.S:56: Warning: Only the first path encountering the conflict is reported bzero.S:53: Warning: This is the location of the conflicting usage [this is a new one] bzero.S:60: Warning: Use of 'tbit.nz' violates RAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 32 bzero.S:60: Warning: Only the first path encountering the conflict is reported bzero.S:57: Warning: This is the location of the conflicting usage [this is new too] peter@overcee[2:20pm]~src/lib/libc/ia64/string-138> 52: 3: tbit.nz p6,p0=in0,0 ;; 53: (p6) st1 [in0]=r0,1 54: (p6) add in1=-1,in1 55: 56: tbit.nz p6,p0=in0,1 ;; 57: (p6) st2 [in0]=r0,2 58: (p6) add in1=-2,in1 59: 60: tbit.nz p6,p0=in0,2 ;; 61: (p6) st4 [in0]=r0,4 62: (p6) add in1=-4,in1 63: 64: ;; This certainly looks like a real violation.. the way I read the description of st1/st2 etc is that it not only writes to the memory location, but it also adds the size to the general register.. ie: in0 is modified and then we to a tbit.nz on the same general register without a stop. I changed it to this locally and it went away: 3: tbit.nz p6,p0=in0,0 ;; (p6) st1 [in0]=r0,1 (p6) add in1=-1,in1 ;; tbit.nz p6,p0=in0,1 ;; (p6) st2 [in0]=r0,2 (p6) add in1=-2,in1 ;; tbit.nz p6,p0=in0,2 ;; (p6) st4 [in0]=r0,4 (p6) add in1=-4,in1 ;; but that hardly seems efficient. could we copy in0 to somewhere else in order to avoid the RAW? the bits we're interested in are not going to change by the st1/2/4 adds. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Oct 21 21:29: 1 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 8C14537B405 for ; Sun, 21 Oct 2001 21:28:56 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9M4Suo03511; Sun, 21 Oct 2001 21:28:56 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9M4Tam61584; Sun, 21 Oct 2001 21:29:36 -0700 (PDT) (envelope-from marcel) Date: Sun, 21 Oct 2001 21:29:36 -0700 From: Marcel Moolenaar To: Peter Wemm Cc: Doug Rabson , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] Message-ID: <20011021212935.C28459@dhcp01.pn.xcllnt.net> References: <20011021220023.A549-100000@salmon.nlsystems.com> <20011021213435.1DFE43803@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011021213435.1DFE43803@overcee.netplex.com.au> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Oct 21, 2001 at 02:34:35PM -0700, Peter Wemm wrote: > > 52: 3: tbit.nz p6,p0=in0,0 ;; > 53: (p6) st1 [in0]=r0,1 > 54: (p6) add in1=-1,in1 > 55: > 56: tbit.nz p6,p0=in0,1 ;; > 57: (p6) st2 [in0]=r0,2 > 58: (p6) add in1=-2,in1 > 59: > 60: tbit.nz p6,p0=in0,2 ;; > 61: (p6) st4 [in0]=r0,4 > 62: (p6) add in1=-4,in1 > 63: > 64: ;; [snip] > but that hardly seems efficient. could we copy in0 to somewhere else in > order to avoid the RAW? the bits we're interested in are not going to change > by the st1/2/4 adds. The code is inherently sequential in that the result of the postinc is used by subsequent tbit instructions. One way to increase ILP is to do an aligned ld8, zero-out the bytes that need to be zeroed in the temporary register and write the result back. in0 (ptr) and in1 (size) can be updated without there being an immediate use for them. The code will be endianness sensitive though. Something like: and t0 = 0xf8, in0;; // sign-extension ld8 t1 = [t0];; // Zero-out the bytes in t1 that need zeroed st8 [t0] = t1 in0 can be updated by a simple add: add in0 = 8, t0 in1 can be updated by the following sequence: or t2 = 7, in0 mov t3 = in1 ;; sub in1 = t3, t2 Both updates can be performed concurrently with the zeroing of t1. The zeroing of t1 can be sequence of predicated dep instructions. Just a thought, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Oct 22 1:47:42 2001 Delivered-To: freebsd-ia64@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 7D8A837B406 for ; Mon, 22 Oct 2001 01:47:36 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15vakA-000MZA-0Y; Mon, 22 Oct 2001 09:47:34 +0100 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9M8kH770790; Mon, 22 Oct 2001 09:46:17 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 22 Oct 2001 09:44:23 +0100 (BST) From: Doug Rabson To: Marcel Moolenaar Cc: Peter Wemm , Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011021212935.C28459@dhcp01.pn.xcllnt.net> Message-ID: <20011022094201.L549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 21 Oct 2001, Marcel Moolenaar wrote: > On Sun, Oct 21, 2001 at 02:34:35PM -0700, Peter Wemm wrote: > > > > 52: 3: tbit.nz p6,p0=in0,0 ;; > > 53: (p6) st1 [in0]=r0,1 > > 54: (p6) add in1=-1,in1 > > 55: > > 56: tbit.nz p6,p0=in0,1 ;; > > 57: (p6) st2 [in0]=r0,2 > > 58: (p6) add in1=-2,in1 > > 59: > > 60: tbit.nz p6,p0=in0,2 ;; > > 61: (p6) st4 [in0]=r0,4 > > 62: (p6) add in1=-4,in1 > > 63: > > 64: ;; > > [snip] > > > but that hardly seems efficient. could we copy in0 to somewhere else in > > order to avoid the RAW? the bits we're interested in are not going to change > > by the st1/2/4 adds. > > The code is inherently sequential in that the result of the > postinc is used by subsequent tbit instructions. One way to > increase ILP is to do an aligned ld8, zero-out the bytes > that need to be zeroed in the temporary register and write > the result back. in0 (ptr) and in1 (size) can be updated > without there being an immediate use for them. The code > will be endianness sensitive though. Something like: > > and t0 = 0xf8, in0;; // sign-extension > ld8 t1 = [t0];; > // Zero-out the bytes in t1 that need zeroed > st8 [t0] = t1 > > in0 can be updated by a simple add: > > add in0 = 8, t0 > > in1 can be updated by the following sequence: > > or t2 = 7, in0 > mov t3 = in1 ;; > sub in1 = t3, t2 > > Both updates can be performed concurrently with the zeroing > of t1. The zeroing of t1 can be sequence of predicated dep > instructions. > > Just a thought, I'm not too worried about performance here - this is just cleaning up the pointer so that we can do an aligned store in the main loop. I'm just going to add the stops as Peter suggested. We can revisit this (and all the other string code) and work on performance later. The whole lot probably needs rewriting. Perhaps Intel has some sample code... -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Oct 22 2:23:42 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 8000A37B401 for ; Mon, 22 Oct 2001 02:23:34 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9M9NYM27099 for ; Mon, 22 Oct 2001 02:23:34 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 1F3F138CC; Mon, 22 Oct 2001 02:23:34 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Doug Rabson Cc: Marcel Moolenaar , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011022094201.L549-100000@salmon.nlsystems.com> Date: Mon, 22 Oct 2001 02:23:34 -0700 From: Peter Wemm Message-Id: <20011022092334.1F3F138CC@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Doug Rabson wrote: > On Sun, 21 Oct 2001, Marcel Moolenaar wrote: > > > On Sun, Oct 21, 2001 at 02:34:35PM -0700, Peter Wemm wrote: > > > > > > 52: 3: tbit.nz p6,p0=in0,0 ;; > > > 53: (p6) st1 [in0]=r0,1 > > > 54: (p6) add in1=-1,in1 > > > 55: > > > 56: tbit.nz p6,p0=in0,1 ;; > > > 57: (p6) st2 [in0]=r0,2 > > > 58: (p6) add in1=-2,in1 > > > 59: > > > 60: tbit.nz p6,p0=in0,2 ;; > > > 61: (p6) st4 [in0]=r0,4 > > > 62: (p6) add in1=-4,in1 > > > 63: > > > 64: ;; > > > > [snip] > > > > > but that hardly seems efficient. could we copy in0 to somewhere else in > > > order to avoid the RAW? the bits we're interested in are not going to ch ange > > > by the st1/2/4 adds. > > > > The code is inherently sequential in that the result of the > > postinc is used by subsequent tbit instructions. One way to > > increase ILP is to do an aligned ld8, zero-out the bytes > > that need to be zeroed in the temporary register and write > > the result back. in0 (ptr) and in1 (size) can be updated > > without there being an immediate use for them. The code > > will be endianness sensitive though. Something like: > > > > and t0 = 0xf8, in0;; // sign-extension > > ld8 t1 = [t0];; > > // Zero-out the bytes in t1 that need zeroed > > st8 [t0] = t1 > > > > in0 can be updated by a simple add: > > > > add in0 = 8, t0 > > > > in1 can be updated by the following sequence: > > > > or t2 = 7, in0 > > mov t3 = in1 ;; > > sub in1 = t3, t2 > > > > Both updates can be performed concurrently with the zeroing > > of t1. The zeroing of t1 can be sequence of predicated dep > > instructions. > > > > Just a thought, > > I'm not too worried about performance here - this is just cleaning up the > pointer so that we can do an aligned store in the main loop. I'm just > going to add the stops as Peter suggested. We can revisit this (and all > the other string code) and work on performance later. The whole lot > probably needs rewriting. Perhaps Intel has some sample code... Heh. There was another one in vfork(). This might have been what broke csh (a heavily dependent on vfork()). I've modified my ia64-final gcc specs file to fix the -D__linux__ etc crap and also put in -x into the asm flags so that gcc/gas will warn about dependency violations. The relevant lines: *asm_final: -x %| *link: %{shared:-shared} %{!shared: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /usr/libexec/ld-elf.so.1}} %{static:-static}} *predefines: -D__ia64 -D__ia64__ -D__FreeBSD__=5 -D_LONGLONG -Dunix -D__LP64__ -D__ELF__ -Asystem(FreeBSD) -Acpu(ia64) -Amachine(ia64) There's bunches of other stuff that is out of sync. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Oct 22 3: 6:53 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 9B12637B403 for ; Mon, 22 Oct 2001 03:06:49 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 15vbyn-0008H0-0A; Mon, 22 Oct 2001 10:06:45 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9MA5T776268; Mon, 22 Oct 2001 11:05:29 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 22 Oct 2001 11:05:29 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: Marcel Moolenaar , Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011022092334.1F3F138CC@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 22 Oct 2001, Peter Wemm wrote: > Doug Rabson wrote: > > I'm not too worried about performance here - this is just cleaning up the > > pointer so that we can do an aligned store in the main loop. I'm just > > going to add the stops as Peter suggested. We can revisit this (and all > > the other string code) and work on performance later. The whole lot > > probably needs rewriting. Perhaps Intel has some sample code... > > Heh. There was another one in vfork(). This might have been what broke > csh (a heavily dependent on vfork()). Hmm. Csh is a bit happier with the latest set of changes to exception.s but it still faults often. I thought there might still be a problem with signal delivery. The one case I examined this morning was due to a completely trashed set of registers - gp was pointing into the user stack. I'll try again with the modified vfork and see if it helps. > > I've modified my ia64-final gcc specs file to fix the -D__linux__ etc crap > and also put in -x into the asm flags so that gcc/gas will warn about > dependency violations. The relevant lines: Thats a really good idea - I'll do the same in my copy. Incidentally, I've experimented with using gcc 3.0.2 to build kernels and they work pretty well, at least in SKI. I haven't tried a gcc 3.0.2 kernel on the SDV yet. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Oct 22 5:35:28 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id A58D437B409 for ; Mon, 22 Oct 2001 05:35:15 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9MCZFM27580 for ; Mon, 22 Oct 2001 05:35:15 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 4B9DE3808; Mon, 22 Oct 2001 05:35:15 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Doug Rabson Cc: Marcel Moolenaar , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: Date: Mon, 22 Oct 2001 05:35:15 -0700 From: Peter Wemm Message-Id: <20011022123515.4B9DE3808@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Doug Rabson wrote: > On Mon, 22 Oct 2001, Peter Wemm wrote: > > > Doug Rabson wrote: > > > I'm not too worried about performance here - this is just cleaning up the > > > pointer so that we can do an aligned store in the main loop. I'm just > > > going to add the stops as Peter suggested. We can revisit this (and all > > > the other string code) and work on performance later. The whole lot > > > probably needs rewriting. Perhaps Intel has some sample code... > > > > Heh. There was another one in vfork(). This might have been what broke > > csh (a heavily dependent on vfork()). > > Hmm. Csh is a bit happier with the latest set of changes to exception.s > but it still faults often. I thought there might still be a problem with > signal delivery. The one case I examined this morning was due to a > completely trashed set of registers - gp was pointing into the user stack. > > I'll try again with the modified vfork and see if it helps. I didn't get much joy. It sort-of works, but still gets bus errors. Does exception.s report the cause of the bus-errors? Or does it just deliver them? I may have a slightly older kernel than userland.. I've just rebuilt my box running fully partitioned and everything. I've just finished a manual world build, my results were: libkvm - missing kvm_ia64.c (I added one that had stubs for crashdump reading) savecore - no ok() macros pnpinfo - no outb() routines crunchide/exec_aout.h - it seems we dont define the a.out format sufficiently for this to be happy on ia64. Oh dear, what a shame. :-) sysinstall - wanted machine/uc_device.h (i386 only, will fix). pam - all dlopen()'s still seem to be broken gprof - fails to build truss/kdump - the usual include file mixups. I didn't put much effort into resolving this. It probably works with a DESTDIR=/ia64 at build. libc_r - failed to find some atomic.S file pppctl - needs libc_r ppp - needs NOI4B due to the bogus placement of some MI headers in sys/i386/include perl - I didn't even try to cross build this. Aside from perl, libc_r, gprof, pnpinfo, truss/kdump, and the cc/binutils toolchain I managed to get a complete system build.. even the damn games. :-) libpam error messages: .... Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_setcred Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_acct_mgmt Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_open_session Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_close_session Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_chauthtok Oct 22 13:03:34 ia64 telnetd[309]: auth_pam: Module is unknown Even sshd etc are happy! :-) peter@overcee[5:17am]~-133> ssh ia64 uname -a FreeBSD ia64.wemm.org 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Mon Oct 22 01:14:37 PDT 2001 peter@overcee.netplex.com.au:/home/src/sys/ia64/compile/SMALL ia64 I could even run sysinstall on it! :-) ntpdate causes a console complaint about not being able to set the TODR. ps doesn't report arguments correctly (I can fix this). # ps -ax PID TT STAT TIME COMMAND 0 ?? DLs 0:00.02 (swapper) 1 ?? ILs 0:00.03 (init) ... 304 ?? Is 0:01.15 (sshd) 327 ?? S 0:00.29 (sshd) 335 ?? Is 0:00.02 (rwhod) 328 p0 Ss 0:00.09 (sh) 344 p0 R+ 0:00.01 (ps) 272 d0 Is+ 0:00.03 (getty) I'd like to pick off a few pending minor commits from the process, and then start tinkering with something like the EFI native partitioning format. Oh, It has been invaluable to have FreeBSD/i386 installed.. I've had EFI and FreeBSD/i386 on the primary drive (Boot Legacy C:) and FreeBSD/ia64 on its own disk on da1. I've installed this build via writes over NFS from my build box (eek!). This is very convenient since you can just run fdisk / sysinstall / newfs etc and create filesystems that the ia64 kernel is quite happy with. ONE CAVEAT!!! DO NOT INSTALL boot1 AS-IS ON ***ANY*** PARTITION. The fake fdisk label for dangerously dedicated mode locks up EFI. The only way to recover is to either blow away the boot1 on another machine, or do a hot-plug after EFI has started and boot from CD or floppy and let freebsd reprobe and find the drives. You can make a working boot1 by zeroing out the bogus fdisk table. Have I mentioned how much I **HATE** the dangerously dedicated boot support crud lately? :-) Also, dont bother installing RELENG_4 on it. It cannot enumerate the pci busses, so it wont find the scsi controller etc unless it is moved to the 5V pci slot closest to the cpu. (and then you wont see any other pci cards). My SDV has a busted onboard ethernet, so I have to use a second card. > > I've modified my ia64-final gcc specs file to fix the -D__linux__ etc crap > > and also put in -x into the asm flags so that gcc/gas will warn about > > dependency violations. The relevant lines: > > Thats a really good idea - I'll do the same in my copy. Incidentally, I've > experimented with using gcc 3.0.2 to build kernels and they work pretty > well, at least in SKI. I haven't tried a gcc 3.0.2 kernel on the SDV yet. And of course take out the overrides in sys/conf/Makefile.ia64. Overall, I'm really pleased at how well it seems to be running. We're getting to the point where the only showstopper for self-hosting is lack of integrated compiler. (That is, aside from the other things on your TODO list that you posted a few days ago) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Oct 22 6:14:51 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id CE72037B403 for ; Mon, 22 Oct 2001 06:14:43 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 15veug-000DoX-0W; Mon, 22 Oct 2001 14:14:42 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9MDDQ776875; Mon, 22 Oct 2001 14:13:26 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 22 Oct 2001 14:13:26 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: Marcel Moolenaar , Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011022123515.4B9DE3808@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 22 Oct 2001, Peter Wemm wrote: > Doug Rabson wrote: > > On Mon, 22 Oct 2001, Peter Wemm wrote: > > > > > Doug Rabson wrote: > > > > I'm not too worried about performance here - this is just cleaning up the > > > > pointer so that we can do an aligned store in the main loop. I'm just > > > > going to add the stops as Peter suggested. We can revisit this (and all > > > > the other string code) and work on performance later. The whole lot > > > > probably needs rewriting. Perhaps Intel has some sample code... > > > > > > Heh. There was another one in vfork(). This might have been what broke > > > csh (a heavily dependent on vfork()). > > > > Hmm. Csh is a bit happier with the latest set of changes to exception.s > > but it still faults often. I thought there might still be a problem with > > signal delivery. The one case I examined this morning was due to a > > completely trashed set of registers - gp was pointing into the user stack. > > > > I'll try again with the modified vfork and see if it helps. > > I didn't get much joy. It sort-of works, but still gets bus errors. > Does exception.s report the cause of the bus-errors? Or does it just > deliver them? > > I may have a slightly older kernel than userland.. I've just rebuilt > my box running fully partitioned and everything. > > I've just finished a manual world build, my results were: > > libkvm - missing kvm_ia64.c (I added one that had stubs for crashdump reading) Damn - I thought I had committed that already. I stubbed out half of it too, mainly the va->pa conversion parts. > savecore - no ok() macros Hmm. What does ok() do? > pnpinfo - no outb() routines This needs an equivalent to the alpha libio library which maps selected parts of the PIO region and does something like the functions in cpufunc.h. > crunchide/exec_aout.h - it seems we dont define the a.out format > sufficiently for this to be happy on ia64. Oh dear, what a shame. :-) Hah. > sysinstall - wanted machine/uc_device.h (i386 only, will fix). > pam - all dlopen()'s still seem to be broken I have fixed PAM. It was casting the dlopen() returned handle to an int. I'm currently trying to feed patches back to the vendor via MarkM. > gprof - fails to build Bah. > truss/kdump - the usual include file mixups. I didn't put much effort > into resolving this. It probably works with a DESTDIR=/ia64 at build. Ktrace and kdump work pretty well for me. > libc_r - failed to find some atomic.S file Libc_r has some much larger issues. It kind of relies on being able to use setjmp/longjmp to switch threads. The ia64 setjmp does *not* support this. You can only jump back up your own stack for register-stack efficiency reasons. The Linux guys are using the (posix std?) makecontext, switchcontext functions which construct and use instances of ucontext_t for thread switching. We need something similar. > pppctl - needs libc_r > ppp - needs NOI4B due to the bogus placement of some MI headers in > sys/i386/include > perl - I didn't even try to cross build this. > > Aside from perl, libc_r, gprof, pnpinfo, truss/kdump, and the cc/binutils > toolchain I managed to get a complete system build.. even the damn games. :-) :-) > > libpam error messages: > .... > Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_setcred > Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_acct_mgmt > Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_open_session > Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_close_session > Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_chauthtok > Oct 22 13:03:34 ia64 telnetd[309]: auth_pam: Module is unknown Index: pam_handlers.c =================================================================== RCS file: /home/ncvs/src/contrib/libpam/libpam/pam_handlers.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 pam_handlers.c --- pam_handlers.c 2001/05/03 09:36:04 1.1.1.2 +++ pam_handlers.c 2001/10/13 13:37:20 @@ -13,6 +13,11 @@ #include #include #include +#include +#include + +#include "pam_private.h" + #ifdef PAM_DYNAMIC # ifdef PAM_SHL # include @@ -20,10 +25,6 @@ # include # endif /* PAM_SHL */ #endif /* PAM_DYNAMIC */ -#include -#include - -#include "pam_private.h" /* FreeBSD doesn't define this */ #ifndef RTLD_NOW > > Even sshd etc are happy! :-) > > peter@overcee[5:17am]~-133> ssh ia64 uname -a > FreeBSD ia64.wemm.org 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Mon Oct 22 01:14:37 PDT 2001 peter@overcee.netplex.com.au:/home/src/sys/ia64/compile/SMALL ia64 > > I could even run sysinstall on it! :-) > > ntpdate causes a console complaint about not being able to set the TODR. I haven't bothered to implement the eficlock_set() method yet. Feel free to handle it yourself. The sparc64 folks are planning to generalise the clock_if.m stuff so that sparc64, alpha and ia64 can use the same interfaces for clock stuff. > > ps doesn't report arguments correctly (I can fix this). Top gets a bit confused too. It reports garbage process sizes for /bin/sh process for some reason. > Overall, I'm really pleased at how well it seems to be running. > We're getting to the point where the only showstopper for self-hosting > is lack of integrated compiler. (That is, aside from the other things > on your TODO list that you posted a few days ago) I'll update the TODO list and repost it soon. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Oct 22 16:36:17 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 5DAEE37B405 for ; Mon, 22 Oct 2001 16:36:13 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9MNaDM29053 for ; Mon, 22 Oct 2001 16:36:13 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 038A93808; Mon, 22 Oct 2001 16:36:13 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Doug Rabson Cc: Marcel Moolenaar , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: Date: Mon, 22 Oct 2001 16:36:12 -0700 From: Peter Wemm Message-Id: <20011022233613.038A93808@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org as (2.9 and 2.11.2) report: pmap.s:1230: Warning: Use of 'ld8' violates RAW dependency 'DTC' (data) pmap.s:1230: Warning: Only the first path encountering the conflict is reported pmap.s:1213: Warning: This is the location of the conflicting usage pmap.s:3463: Warning: Use of 'ld8' violates RAW dependency 'DTC' (data) pmap.s:3463: Warning: Only the first path encountering the conflict is reported pmap.s:3457: Warning: This is the location of the conflicting usage pmap.s:3467: Warning: Use of 'st8' violates RAW dependency 'DTC' (data) pmap.s:3467: Warning: Only the first path encountering the conflict is reported pmap.s:3457: Warning: This is the location of the conflicting usage .LBB17: .loc 0 208 0 #APP ptc.e r16;; // 1213 #NO_APP ;; .loc 0 209 0 .LBE17: .file 0 "../../../ia64/ia64/pmap.c" .loc 0 508 0 add r16 = r16, r18 .loc 0 506 0 adds r14 = 1, r15 ;; sxt4 r15 = r14 ;; cmp.gtu p6, p7 = r17, r15 (p6) br.cond.dptk .L635 .L641: .loc 0 510 0 ld8 r14 = [r23] // 1230 ;; .... .LBB93: .loc 0 235 0 #APP ptc.l r35,r14;; // 3457 #NO_APP .loc 0 236 0 .LBE93: .file 0 "../../../ia64/ia64/pmap.c" .loc 0 1192 0 ld8 r14 = [r34] // 3463 ;; and r14 = -2, r14 ;; st8 [r34] = r14 // 3467 .loc 0 1193 0 .L847: ;; This corresponds to the code: for (j = 0; j < pmap_ptc_e_count2; j++) { ia64_ptc_e(addr); addr += pmap_ptc_e_stride2; // 1230 ^^^^^^ } addr += pmap_ptc_e_stride1; and: static void pmap_clear_pte(struct ia64_lpte *pte, vm_offset_t va) { if (pte->pte_p) { pmap_remove_vhpt(va); ia64_ptc_l(va, PAGE_SHIFT << 2); pte->pte_p = 0; // 3463/3467 ^^^^^^^^^^^^^^^ } } I haven't finished looking for the info about this.. Is this real? It seems that gas is complaining about an instruction that it thinks should be there but is missing. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Oct 22 16:57:32 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 45EEE37B403 for ; Mon, 22 Oct 2001 16:57:28 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9MNvRM29098 for ; Mon, 22 Oct 2001 16:57:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 6AD023808; Mon, 22 Oct 2001 16:57:27 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Doug Rabson , Marcel Moolenaar , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011022233613.038A93808@overcee.netplex.com.au> Date: Mon, 22 Oct 2001 16:57:27 -0700 From: Peter Wemm Message-Id: <20011022235727.6AD023808@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Peter Wemm wrote: > as (2.9 and 2.11.2) report: > pmap.s:1230: Warning: Use of 'ld8' violates RAW dependency 'DTC' (data) > pmap.s:1230: Warning: Only the first path encountering the conflict is report ed > pmap.s:1213: Warning: This is the location of the conflicting usage > pmap.s:3463: Warning: Use of 'ld8' violates RAW dependency 'DTC' (data) > pmap.s:3463: Warning: Only the first path encountering the conflict is report ed > pmap.s:3457: Warning: This is the location of the conflicting usage > pmap.s:3467: Warning: Use of 'st8' violates RAW dependency 'DTC' (data) > pmap.s:3467: Warning: Only the first path encountering the conflict is report ed > pmap.s:3457: Warning: This is the location of the conflicting usage [..] > I haven't finished looking for the info about this.. Is this real? > It seems that gas is complaining about an instruction that it thinks > should be there but is missing. It seems gas is expecting a srlz.d, but it looks like it isn't necessary in these cases.. The first bit of code is straight from 16.2.2.2.2 in volume 2, and the final critical_exit() has the srlz.d. I assume this isn't necessary since we know that we're not going to be accessing the user areas during this loop. However, pmap_clear_pte() (the second one) appears to work on kernel mappings.. This could be trouble, right? eg: /* * Remove a page from the kva */ void pmap_kremove(vm_offset_t va) { struct ia64_lpte *pte; pte = pmap_find_kpte(va); pmap_clear_pte(pte, va); } Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Oct 22 20: 2:55 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 866A837B401 for ; Mon, 22 Oct 2001 20:02:52 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9N32qo06168; Mon, 22 Oct 2001 20:02:52 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9N33YZ00679; Mon, 22 Oct 2001 20:03:34 -0700 (PDT) (envelope-from marcel) Date: Mon, 22 Oct 2001 20:03:34 -0700 From: Marcel Moolenaar To: Peter Wemm Cc: Doug Rabson , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] Message-ID: <20011022200334.B566@dhcp01.pn.xcllnt.net> References: <20011022233613.038A93808@overcee.netplex.com.au> <20011022235727.6AD023808@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011022235727.6AD023808@overcee.netplex.com.au> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Oct 22, 2001 at 04:57:27PM -0700, Peter Wemm wrote: > Peter Wemm wrote: > > as (2.9 and 2.11.2) report: > > pmap.s:1230: Warning: Use of 'ld8' violates RAW dependency 'DTC' (data) > > pmap.s:1230: Warning: Only the first path encountering the conflict is report > ed > > pmap.s:1213: Warning: This is the location of the conflicting usage > > pmap.s:3463: Warning: Use of 'ld8' violates RAW dependency 'DTC' (data) > > pmap.s:3463: Warning: Only the first path encountering the conflict is report > ed > > pmap.s:3457: Warning: This is the location of the conflicting usage > > pmap.s:3467: Warning: Use of 'st8' violates RAW dependency 'DTC' (data) > > pmap.s:3467: Warning: Only the first path encountering the conflict is report > ed > > pmap.s:3457: Warning: This is the location of the conflicting usage > > [..] > > > I haven't finished looking for the info about this.. Is this real? > > It seems that gas is complaining about an instruction that it thinks > > should be there but is missing. > > It seems gas is expecting a srlz.d, but it looks like it isn't necessary in > these cases.. The first bit of code is straight from 16.2.2.2.2 in > volume 2, and the final critical_exit() has the srlz.d. I assume this isn't > necessary since we know that we're not going to be accessing the user > areas during this loop. I don't think dependencies depend on user areas or not. There simply is a load following a ptc and according to Appendix A, volume 2 (page A-7) this means that there must be data serialization (srlz.d). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Oct 23 0:59:16 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id BB05337B401 for ; Tue, 23 Oct 2001 00:59:12 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 15vwSi-000OEg-0B; Tue, 23 Oct 2001 07:59:00 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9N7vj788925; Tue, 23 Oct 2001 08:57:45 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 23 Oct 2001 08:55:49 +0100 (BST) From: Doug Rabson To: Marcel Moolenaar Cc: Peter Wemm , Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011022200334.B566@dhcp01.pn.xcllnt.net> Message-ID: <20011023085414.H549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 22 Oct 2001, Marcel Moolenaar wrote: > On Mon, Oct 22, 2001 at 04:57:27PM -0700, Peter Wemm wrote: > > Peter Wemm wrote: > > > as (2.9 and 2.11.2) report: > > > pmap.s:1230: Warning: Use of 'ld8' violates RAW dependency 'DTC' (data) > > > pmap.s:1230: Warning: Only the first path encountering the conflict is report > > ed > > > pmap.s:1213: Warning: This is the location of the conflicting usage > > > pmap.s:3463: Warning: Use of 'ld8' violates RAW dependency 'DTC' (data) > > > pmap.s:3463: Warning: Only the first path encountering the conflict is report > > ed > > > pmap.s:3457: Warning: This is the location of the conflicting usage > > > pmap.s:3467: Warning: Use of 'st8' violates RAW dependency 'DTC' (data) > > > pmap.s:3467: Warning: Only the first path encountering the conflict is report > > ed > > > pmap.s:3457: Warning: This is the location of the conflicting usage > > > > [..] > > > > > I haven't finished looking for the info about this.. Is this real? > > > It seems that gas is complaining about an instruction that it thinks > > > should be there but is missing. > > > > It seems gas is expecting a srlz.d, but it looks like it isn't necessary in > > these cases.. The first bit of code is straight from 16.2.2.2.2 in > > volume 2, and the final critical_exit() has the srlz.d. I assume this isn't > > necessary since we know that we're not going to be accessing the user > > areas during this loop. > > I don't think dependencies depend on user areas or not. There > simply is a load following a ptc and according to Appendix A, > volume 2 (page A-7) this means that there must be data > serialization (srlz.d). I took this to mean that there should be serialization between a ptc and a reader of the va that the ptc covered. I don't think serialization is really needed here but it should be harmless to add a couple of srlz.d instructions to ia64_cpu.h. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Oct 23 12:11:51 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 65B2937B43A for ; Tue, 23 Oct 2001 12:11:40 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9NJBeM32078 for ; Tue, 23 Oct 2001 12:11:40 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 82005380A; Tue, 23 Oct 2001 12:11:40 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: obrien@nuxi.com, dfr@nlsystems.com Cc: ia64@freebsd.org Subject: Fixes for ia64 on in-tree binutils Date: Tue, 23 Oct 2001 12:11:40 -0700 From: Peter Wemm Message-Id: <20011023191140.82005380A@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The first one solves ia64_info->fptr_sec et al from being trashed by the default MALLOC_OPTIONS AJ. The second is a potentially fatal int/long pointer mistake on LP64 systems. [FYI to people on the list, dfr and obrien already know this] Also, to get a working assembler, you need to grab http://people.freebsd.org/~peter/ia64-asmtab.c and replace the src/contrib/binutils/opcodes/ia64-asmtab.c version which got trashed before binutils-2.11.2 was released (64 bit numbers got truncated to 32 bit) Index: elfxx-ia64.c =================================================================== RCS file: /home/ncvs/src/contrib/binutils/bfd/elfxx-ia64.c,v retrieving revision 1.1.1.1 diff -u -2 -u -r1.1.1.1 elfxx-ia64.c --- elfxx-ia64.c 2001/10/13 01:47:45 1.1.1.1 +++ elfxx-ia64.c 2001/10/23 19:05:52 @@ -1303,5 +1303,4 @@ new_hash_entry_func new; { - memset (ht, 0, sizeof (*ht)); return bfd_hash_table_init (&ht->root, new); } @@ -1441,4 +1440,5 @@ if (!ret) return 0; + memset (ret, 0, sizeof (*ret)); if (!_bfd_elf_link_hash_table_init (&ret->root, abfd, elfNN_ia64_new_elf_hash_entry)) Index: peXXigen.c =================================================================== RCS file: /home/ncvs/src/contrib/binutils/bfd/peXXigen.c,v retrieving revision 1.1.1.1 diff -u -2 -u -r1.1.1.1 peXXigen.c --- peXXigen.c 2001/06/26 16:56:37 1.1.1.1 +++ peXXigen.c 2001/10/23 19:05:52 @@ -1806,4 +1806,5 @@ struct internal_extra_pe_aouthdr *i = &pe->pe_opthdr; const char *subsystem_name = NULL; + time_t t; /* The MS dumpbin program reportedly ands with 0xff0f before @@ -1826,5 +1827,6 @@ /* ctime implies '\n'. */ - fprintf (file, "\nTime/Date\t\t%s", ctime (&pe->coff.timestamp)); + t = pe->coff.timestamp; + fprintf (file, "\nTime/Date\t\t%s", ctime (&t)); fprintf (file, "\nImageBase\t\t"); fprintf_vma (file, i->ImageBase); Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Oct 23 22: 6:27 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 08E9A37B401 for ; Tue, 23 Oct 2001 22:06:20 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9O56Jo09198; Tue, 23 Oct 2001 22:06:19 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9O56rB02155; Tue, 23 Oct 2001 22:06:53 -0700 (PDT) (envelope-from marcel) Date: Tue, 23 Oct 2001 22:06:53 -0700 From: Marcel Moolenaar To: Doug Rabson Cc: Peter Wemm , ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] Message-ID: <20011023220653.B2044@dhcp01.pn.xcllnt.net> References: <20011022200334.B566@dhcp01.pn.xcllnt.net> <20011023085414.H549-100000@salmon.nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011023085414.H549-100000@salmon.nlsystems.com> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 23, 2001 at 08:55:49AM +0100, Doug Rabson wrote: > On Mon, 22 Oct 2001, Marcel Moolenaar wrote: > > > > necessary since we know that we're not going to be accessing the user > > > areas during this loop. > > > > I don't think dependencies depend on user areas or not. There > > simply is a load following a ptc and according to Appendix A, > > volume 2 (page A-7) this means that there must be data > > serialization (srlz.d). > > I took this to mean that there should be serialization between a ptc and a > reader of the va that the ptc covered. I don't think serialization is > really needed here but it should be harmless to add a couple of srlz.d > instructions to ia64_cpu.h. I think the dependency is not on the address, but on the translation cache entry. In that sense, anything that accesses the entry needs to be serialized after the purge. Given that the purge behaviour is implementation specific, it's probably impossible to determine (staticly) when a data access is dependent or not. See also: SDM, vol 2, page 2-191: Purge Translation Cache Entry. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Oct 23 22:37:29 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 135B337B401; Tue, 23 Oct 2001 22:37:15 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9O5bEo09244; Tue, 23 Oct 2001 22:37:14 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9O5c1B02319; Tue, 23 Oct 2001 22:38:01 -0700 (PDT) (envelope-from marcel) Date: Tue, 23 Oct 2001 22:38:01 -0700 From: Marcel Moolenaar To: msmith@FreeBSD.org Cc: ia64@FreeBSD.org Subject: Enumerating processors using ACPI Message-ID: <20011023223801.A2209@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.21i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike, I'm looking at SMP support for ia64 and it looks to me that we really want to use ACPI to enumerate the processors. Besides the phase ordering problem (cpu_mp_probe, cpu_mp_start and cpu_mp_announce is called too early to have them keep their current meaning) we also need a clean way to scan the devices. One possible way is: extern devclass_t acpi_cpu_devclass; devclass_get_devices(acpi_cpu_devclass, &cpus, &ncpus); for (i = 0; i < ncpus; i++) lid = acpi_get_cpu_id(cpus[i]); /* ACPI interface function */ launch_cpu(lid); I don't know exactly what we store in the softc, but does the scheme described above looks reasonable. The bigger picture I use is: mp_machdep.c:cpu_mp_probe() returns 1 if we've seen an AP wake-up vector entry in the SAL system table, otherwise 0. mp_ncpus is left 0. subr_smp.c:mp_start() Only calls cpu_mp_start and cpu_mp_announce if running on MP hardware (as returned by cpu_mp_probe) and mp_ncpus > 0. SYSINIT(SI_SUB_SMP) Now that all devices are probed and we have parsed the ACPI tables, initialize the MP data, and launch the APs. Have each AP announce itself as a debugging aid. Here we want to enumerate the processors known by ACPI. Thoughts? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Oct 24 1: 1: 3 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from giasmd01.vsnl.net.in (giasmd01.vsnl.net.in [202.54.6.1]) by hub.freebsd.org (Postfix) with ESMTP id 1679237B401; Wed, 24 Oct 2001 01:00:17 -0700 (PDT) Received: from voice_server (unknown [203.197.130.21]) by giasmd01.vsnl.net.in (Postfix) with SMTP id 7635AE761; Wed, 24 Oct 2001 13:32:18 +0530 (IST) From: Marblejar_Recruiter@vsnl.net To: IT_Professionals@giasmd01.vsnl.net.in Subject: ADV: Introduction to Marblejar X-Mailer: AMLC 2.7 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B7_01C157D4.6513E350" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Message-Id: <20011024080218.7635AE761@giasmd01.vsnl.net.in> Date: Wed, 24 Oct 2001 13:32:18 +0530 (IST) Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_01B7_01C157D4.6513E350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take charge of your career by utilizing www.marblejar.com. We offer IT = professionals like you all of the services you require to find the most = challenging positions in the IT industry.=20 * $500 Signing bonus when you get job through us * Dedicated recruiters to help you identify the best job openings in = your skill * Targeted searches that meet your needs * We provide totally privacy on all of your contact information. No one = can view your resume without your approval. * Immediate notification anytime a client selects your resume for = review. * One short step approval process- upload your resume in less than 5 = minutes. Marblejar is full service web based IT recruiting firm. Let us start = helping you, login today at www.marblejar.com. Sincerely, John Ross Program Manager We respect your time. If you would like to be removed from our mailing = list, click on mailto:Marblejar_Recruiter@vsnl.net?subject=3DREMOVE and = add the email address(es) to remove in your subject line. This message = is designed to comply with all U.S. state laws and pending federal = legislation regarding electronic mail marketing. You can avoid seeing = compliant messages by setting your mail reader to filter messages with = "ADV:" at the beginning of the Subject line. Submit questions or = comments regarding these matters by clicking on = mailto:Marblejar_Recruiter@vsnl.net?subject=3DCOMPLIANCE. Marblejar LLC Manor Oak Two, Suite 252 1910 Cochran Road Pittsburgh, PA 15220 ------=_NextPart_000_01B7_01C157D4.6513E350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Take charge of your career by = utilizing www.marblejar.com.  We offer = IT=20 professionals like you all of the services you require to find the most=20 challenging  positions in the IT industry.

* $500 Signing = bonus=20 when you get job through us
* Dedicated recruiters to help you = identify the=20 best job openings in your skill
* Targeted searches that meet your = needs
*=20 We provide totally privacy on all of your contact information. No one = can view=20 your resume without your approval.
* Immediate notification anytime a = client=20 selects your resume for review.
* One short step approval process- = upload=20 your resume in less than 5 minutes.

Marblejar is full service web = based=20 IT recruiting firm. Let us start helping you, login today at www.marblejar.com.


Since= rely,

John=20 Ross
Program Manager

We respect your time. If you would like = to be=20 removed from our mailing list, click on mailto:Marb= lejar_Recruiter@vsnl.net?subject=3DREMOVE=20 and add the email address(es) to remove in your subject line.  This = message=20 is designed to comply with all U.S. state laws and pending federal = legislation=20 regarding electronic mail marketing. You can avoid seeing compliant = messages by=20 setting your mail reader to filter messages with "ADV:" at the beginning = of the=20 Subject line. Submit questions or comments regarding these matters by = clicking=20 on mailto:= Marblejar_Recruiter@vsnl.net?subject=3DCOMPLIANCE.
 
 
Marblejar LLC
Manor Oak Two, Suite = 252
1910=20 Cochran Road
Pittsburgh, PA 15220
------=_NextPart_000_01B7_01C157D4.6513E350-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Oct 24 1: 2:39 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id C5F8837B405; Wed, 24 Oct 2001 01:02:35 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f9O8ExI08929; Wed, 24 Oct 2001 01:14:59 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110240814.f9O8ExI08929@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Marcel Moolenaar Cc: msmith@FreeBSD.org, ia64@FreeBSD.org Subject: Re: Enumerating processors using ACPI In-reply-to: Your message of "Tue, 23 Oct 2001 22:38:01 PDT." <20011023223801.A2209@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Oct 2001 01:14:59 -0700 From: Mike Smith Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Mike, > > I'm looking at SMP support for ia64 and it looks to me that we > really want to use ACPI to enumerate the processors. Besides > the phase ordering problem (cpu_mp_probe, cpu_mp_start and > cpu_mp_announce is called too early to have them keep their > current meaning) we also need a clean way to scan the devices. Assuming that we can reliably expect ACPI on the IA64 to describe the processors that are actually present (vs. those that merely appear to be), or we can check for certain that a CPU is present, there's no reason not to defer attaching the CPU until we handle the Processor device in the ACPI namespace. > One possible way is: > > extern devclass_t acpi_cpu_devclass; > devclass_get_devices(acpi_cpu_devclass, &cpus, &ncpus); > for (i = 0; i < ncpus; i++) > lid = acpi_get_cpu_id(cpus[i]); /* ACPI interface function */ > launch_cpu(lid); Do it in the processor device attach routine instead. You would probably want to make this an IA64-specific driver. Alternatively, you could just have the generic CPU driver export the logical ID via some accessor function as you suggest. Do the first part like this though: devclass_get_devices(devclass_find("cpu"), &cpus, &ncpus); > I don't know exactly what we store in the softc, but does the > scheme described above looks reasonable. We can certainly get the logical ID, if that's all you need to launch the CPU. Alternatively, we can hang an IA64-specific device off the CPU, ie. a cpu_activation device. There are lots of ways to do this; I'm just not sure what information you need to actually launch the CPU. > The bigger picture I use is: > > mp_machdep.c:cpu_mp_probe() > returns 1 if we've seen an AP wake-up vector entry in the > SAL system table, otherwise 0. mp_ncpus is left 0. IA64 should be intrinsically MP. Making MP conditional on x86 was, IMO, a major mistake. > subr_smp.c:mp_start() > Only calls cpu_mp_start and cpu_mp_announce if running on > MP hardware (as returned by cpu_mp_probe) and mp_ncpus > 0. I don't know where this is in the bigger picture. Basically, if the CPU driver finds an extant CPU that is not the BSP, it should configure it and leave it spinning on the lock. Once all the device probes are done and we're ready to go MP, we should unconditionally open the lock. > SYSINIT(SI_SUB_SMP) > Now that all devices are probed and we have parsed the ACPI > tables, initialize the MP data, and launch the APs. Have > each AP announce itself as a debugging aid. Here we want > to enumerate the processors known by ACPI. No; we should have enumerated all the processors long ago. Here is where we start them running, as above. So basically: - Boot on the BSP. - During the ACPI namespace scan, check for and start the APs, leave them blocked. - At SI_SUB_SMP, unblock all the APs and have them announce themselves as running. Again, this is basically the way that x86 MP should have been done (substitute MPTABLE for ACPI above). HTH, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Oct 24 1:20:15 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id 23D3337B403 for ; Wed, 24 Oct 2001 01:20:11 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 15wJGk-000BES-0V; Wed, 24 Oct 2001 09:20:10 +0100 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9O8Is796269; Wed, 24 Oct 2001 09:18:54 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 24 Oct 2001 09:16:56 +0100 (BST) From: Doug Rabson To: Marcel Moolenaar Cc: Peter Wemm , Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] In-Reply-To: <20011023220653.B2044@dhcp01.pn.xcllnt.net> Message-ID: <20011024091602.A549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 23 Oct 2001, Marcel Moolenaar wrote: > On Tue, Oct 23, 2001 at 08:55:49AM +0100, Doug Rabson wrote: > > On Mon, 22 Oct 2001, Marcel Moolenaar wrote: > > > > > > necessary since we know that we're not going to be accessing the user > > > > areas during this loop. > > > > > > I don't think dependencies depend on user areas or not. There > > > simply is a load following a ptc and according to Appendix A, > > > volume 2 (page A-7) this means that there must be data > > > serialization (srlz.d). > > > > I took this to mean that there should be serialization between a ptc and a > > reader of the va that the ptc covered. I don't think serialization is > > really needed here but it should be harmless to add a couple of srlz.d > > instructions to ia64_cpu.h. > > I think the dependency is not on the address, but on the translation > cache entry. In that sense, anything that accesses the entry needs > to be serialized after the purge. > > Given that the purge behaviour is implementation specific, it's > probably impossible to determine (staticly) when a data access > is dependent or not. > > See also: SDM, vol 2, page 2-191: Purge Translation Cache Entry. You are right, especially for ptc.e. I've added 'srlz.d' to the various ptc inlines and also to the ia64_set_rr inline. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Oct 24 1:23:19 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id B30C037B403; Wed, 24 Oct 2001 01:23:16 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 15wJJj-0008jr-0B; Wed, 24 Oct 2001 08:23:15 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9O8M0796332; Wed, 24 Oct 2001 09:22:00 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 24 Oct 2001 09:20:02 +0100 (BST) From: Doug Rabson To: Mike Smith Cc: Marcel Moolenaar , Subject: Re: Enumerating processors using ACPI In-Reply-To: <200110240814.f9O8ExI08929@mass.dis.org> Message-ID: <20011024091929.I549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 24 Oct 2001, Mike Smith wrote: > > Mike, > > > > I'm looking at SMP support for ia64 and it looks to me that we > > really want to use ACPI to enumerate the processors. Besides > > the phase ordering problem (cpu_mp_probe, cpu_mp_start and > > cpu_mp_announce is called too early to have them keep their > > current meaning) we also need a clean way to scan the devices. > > Assuming that we can reliably expect ACPI on the IA64 to describe the > processors that are actually present (vs. those that merely appear to > be), or we can check for certain that a CPU is present, there's no reason > not to defer attaching the CPU until we handle the Processor device in > the ACPI namespace. My SDV reports two cpus through ACPI but only one is actually present. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Oct 24 1:43:43 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id C83E537B405; Wed, 24 Oct 2001 01:43:38 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9O8hco09605; Wed, 24 Oct 2001 01:43:38 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9O8iPC45104; Wed, 24 Oct 2001 01:44:25 -0700 (PDT) (envelope-from marcel) Date: Wed, 24 Oct 2001 01:44:24 -0700 From: Marcel Moolenaar To: Mike Smith Cc: ia64@FreeBSD.org Subject: Re: Enumerating processors using ACPI Message-ID: <20011024014424.A44917@dhcp01.pn.xcllnt.net> References: <20011023223801.A2209@dhcp01.pn.xcllnt.net> <200110240814.f9O8ExI08929@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110240814.f9O8ExI08929@mass.dis.org> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Oct 24, 2001 at 01:14:59AM -0700, Mike Smith wrote: > > Mike, > > > > I'm looking at SMP support for ia64 and it looks to me that we > > really want to use ACPI to enumerate the processors. Besides > > the phase ordering problem (cpu_mp_probe, cpu_mp_start and > > cpu_mp_announce is called too early to have them keep their > > current meaning) we also need a clean way to scan the devices. > > Assuming that we can reliably expect ACPI on the IA64 to describe the > processors that are actually present (vs. those that merely appear to > be), or we can check for certain that a CPU is present, there's no reason > not to defer attaching the CPU until we handle the Processor device in > the ACPI namespace. I'm currently using the Multiple APIC table (local APIC/SAPIC entries) to add CPUs. It works ok, because I have the processor ID and APIC id in the entries there, including an enabled/disabled flag. It looks like the right ACPI information to use, but it currently doesn't have any relation (AFAICT) with the cpu device_t. > > One possible way is: > > > > extern devclass_t acpi_cpu_devclass; > > devclass_get_devices(acpi_cpu_devclass, &cpus, &ncpus); > > for (i = 0; i < ncpus; i++) > > lid = acpi_get_cpu_id(cpus[i]); /* ACPI interface function */ > > launch_cpu(lid); > > Do it in the processor device attach routine instead. You would probably > want to make this an IA64-specific driver. > > Alternatively, you could just have the generic CPU driver export the > logical ID via some accessor function as you suggest. Do the first part > like this though: > > devclass_get_devices(devclass_find("cpu"), &cpus, &ncpus); Ok, thanks. > > I don't know exactly what we store in the softc, but does the > > scheme described above looks reasonable. > > We can certainly get the logical ID, if that's all you need to launch the > CPU. See below. > Alternatively, we can hang an IA64-specific device off the CPU, ie. a > cpu_activation device. There are lots of ways to do this; I'm just not > sure what information you need to actually launch the CPU. So far it looks I only need to have the local processor ID, which in this context is the ProcessorId as defined by the PROCESSOR_APIC structure. > > The bigger picture I use is: > > > > mp_machdep.c:cpu_mp_probe() > > returns 1 if we've seen an AP wake-up vector entry in the > > SAL system table, otherwise 0. mp_ncpus is left 0. > > IA64 should be intrinsically MP. Making MP conditional on x86 was, IMO, > a major mistake. Yes. I'm testing a lot on my UP machine. If it continues to scale down as nicely as it does now, we don't need the SMP option. Of course we then also want it scaling up nicely :-) > > subr_smp.c:mp_start() > > Only calls cpu_mp_start and cpu_mp_announce if running on > > MP hardware (as returned by cpu_mp_probe) and mp_ncpus > 0. > > I don't know where this is in the bigger picture. Basically, if the CPU > driver finds an extant CPU that is not the BSP, it should configure it > and leave it spinning on the lock. Once all the device probes are done > and we're ready to go MP, we should unconditionally open the lock. True. For now I delay waking up processors until we're ready to go MP. The only thing I do when I encounter a APIC entry in this case is to add a mapping from cpu to ID. > > SYSINIT(SI_SUB_SMP) > > Now that all devices are probed and we have parsed the ACPI > > tables, initialize the MP data, and launch the APs. Have > > each AP announce itself as a debugging aid. Here we want > > to enumerate the processors known by ACPI. > > No; we should have enumerated all the processors long ago. Here is where > we start them running, as above. Ok. It's basicly what I have now (except for the waking-up). > So basically: > > - Boot on the BSP. > - During the ACPI namespace scan, check for and start the APs, leave > them blocked. > - At SI_SUB_SMP, unblock all the APs and have them announce themselves > as running. > > Again, this is basically the way that x86 MP should have been done > (substitute MPTABLE for ACPI above). Thanks, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Oct 24 1:54:53 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 71B9A37B401; Wed, 24 Oct 2001 01:54:40 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f9O8seo09632; Wed, 24 Oct 2001 01:54:40 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f9O8tQV45167; Wed, 24 Oct 2001 01:55:26 -0700 (PDT) (envelope-from marcel) Date: Wed, 24 Oct 2001 01:55:26 -0700 From: Marcel Moolenaar To: Doug Rabson Cc: Mike Smith , ia64@freebsd.org Subject: Re: Enumerating processors using ACPI Message-ID: <20011024015526.B44917@dhcp01.pn.xcllnt.net> References: <200110240814.f9O8ExI08929@mass.dis.org> <20011024091929.I549-100000@salmon.nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011024091929.I549-100000@salmon.nlsystems.com> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Oct 24, 2001 at 09:20:02AM +0100, Doug Rabson wrote: > > > > Assuming that we can reliably expect ACPI on the IA64 to describe the > > processors that are actually present (vs. those that merely appear to > > be), or we can check for certain that a CPU is present, there's no reason > > not to defer attaching the CPU until we handle the Processor device in > > the ACPI namespace. > > My SDV reports two cpus through ACPI but only one is actually present. Yes. I found out though that the Local APIC entry in the MADT seems correct in that there are 2 entries, but only the first is enabled. The second APIC entry and both SAPIC entries are marked as disabled. I want to see how this looks on the dual-Itanium Lion, but I don't know when (if) I can hijack it again... On the 2-way Lion box: Table 'FACP' at 0xe00000007fe9c700 Table 'APIC' at 0xe00000007fe9c838 Local SAPIC entry ProcessorId=0x0, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0x201, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0xaa02, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0xaa03, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0xaa04, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0xaa05, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0xaa06, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0xaa07, Id=0x0, Eid=0x0 It looks like the first two entries are valid. Now that we print whether an entry is disabled or not, I expect the other 6 to be disabled. If this is the case, then we know exactly how many CPUs are actually installed... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sat Oct 27 1:19:52 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 28E7E37B403 for ; Sat, 27 Oct 2001 01:19:49 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f9R8JmM47189 for ; Sat, 27 Oct 2001 01:19:48 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id A3B56380A; Sat, 27 Oct 2001 01:19:47 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: dfr@nlsystems.com Cc: ia64@freebsd.org Subject: ia64 crti.S and crtn.S Date: Sat, 27 Oct 2001 01:19:47 -0700 From: Peter Wemm Message-Id: <20011027081947.A3B56380A@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've discovered there are no crti/crtn implementations in the tree.. I've hacked together these ultra-trivial crti/crtn implementations: .file "crti.S" .section .init .global _init# .proc _init# _init: alloc loc1 = ar.pfs,0,2,0,0 mov loc0 = b0 /* Save return addr */ .endp _init# .section .fini .global _fini# .proc _fini# _fini: alloc loc1 = ar.pfs,0,2,0,0 mov loc0 = b0 /* Save return addr */ .endp _fini# And: .file "crtn.S" .section .init .regstk 0,2,0,0 mov b0 = loc0 /* Recover return addr */ mov ar.pfs = loc1 br.ret.sptk.many b0 .endp _init# .section .fini .regstk 0,2,0,0 mov b0 = loc0 /* Recover return addr */ mov ar.pfs = loc1 br.ret.sptk.many b0 .endp _fini# Would anybody care to comment on these? I'm in the process of putting together a build script to build the working parts of the userland, libraries and includes in one go, and these files came up. Second question.. Can I use a caller-saved register (eg: r4-r7) for this to avoid the pfs save/restore? Or would I have to use the register stack anyway in order to preserve our caller's r4-r7 first, thus defeating the purpose? (This is partly based on gcc output for clues). Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sat Oct 27 1:45:35 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id EA04937B401; Sat, 27 Oct 2001 01:45:31 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f9R8jVT95923; Sat, 27 Oct 2001 01:45:31 -0700 (PDT) (envelope-from obrien) Date: Sat, 27 Oct 2001 01:45:30 -0700 From: "David O'Brien" To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/csu/ia64 Makefile Message-ID: <20011027014530.A95835@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200110270829.f9R8T3r73051@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110270829.f9R8T3r73051@freefall.freebsd.org>; from obrien@FreeBSD.org on Sat, Oct 27, 2001 at 01:29:03AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Oct 27, 2001 at 01:29:03AM -0700, David E. O'Brien wrote: > obrien 2001/10/27 01:29:03 PDT > Modified files: > lib/csu/ia64 Makefile > Log: > Update for reality and syncing with other FreeBSD platforms. I should have waited until I had the crt{i,n}.S files ready before committing this sync. I'll fix it tomorrow (until then the 3 people that could actually be using this Makefile are capable to tweak things appropriately. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sat Oct 27 10:13:49 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id E9AC837B403 for ; Sat, 27 Oct 2001 10:13:44 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 15xX1i-000Fo8-0B; Sat, 27 Oct 2001 17:13:43 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f9RHCQ725214; Sat, 27 Oct 2001 18:12:26 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 27 Oct 2001 18:10:21 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: Subject: Re: ia64 crti.S and crtn.S In-Reply-To: <20011027081947.A3B56380A@overcee.netplex.com.au> Message-ID: <20011027180634.B549-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 27 Oct 2001, Peter Wemm wrote: > I've discovered there are no crti/crtn implementations in the tree.. I've > hacked together these ultra-trivial crti/crtn implementations: > > .file "crti.S" > > .section .init > .global _init# > .proc _init# > _init: > alloc loc1 = ar.pfs,0,2,0,0 > mov loc0 = b0 /* Save return addr */ > .endp _init# > > .section .fini > .global _fini# > .proc _fini# > _fini: > alloc loc1 = ar.pfs,0,2,0,0 > mov loc0 = b0 /* Save return addr */ > .endp _fini# > > And: > .file "crtn.S" > > .section .init > .regstk 0,2,0,0 > mov b0 = loc0 /* Recover return addr */ > mov ar.pfs = loc1 > br.ret.sptk.many b0 > .endp _init# > > .section .fini > .regstk 0,2,0,0 > mov b0 = loc0 /* Recover return addr */ > mov ar.pfs = loc1 > br.ret.sptk.many b0 > .endp _fini# > > Would anybody care to comment on these? I'm in the process of putting > together a build script to build the working parts of the userland, > libraries and includes in one go, and these files came up. They look fine to me. > > Second question.. Can I use a caller-saved register (eg: r4-r7) for this > to avoid the pfs save/restore? Or would I have to use the register stack > anyway in order to preserve our caller's r4-r7 first, thus defeating > the purpose? > > (This is partly based on gcc output for clues). You can't use r4-r7 to save rp because that would trash your caller's version of r4. The only way to avoid the alloc would be to save rp on the stack: mov r14=rp // copy to general reg ;; st8 [sp]=rp,-16 // save and reserve stack space ... add sp=16,sp ;; ld8 r14=[sp] ;; mov rp=r14 I doubt if it would be better than using alloc though. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message