From owner-freebsd-ia64@FreeBSD.ORG Sat Apr 26 11:15:19 2003 Return-Path: Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9344537B408 for ; Sat, 26 Apr 2003 11:15:17 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5512543F93 for ; Sat, 26 Apr 2003 11:15:14 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h3QIFDwk029764; Sat, 26 Apr 2003 11:15:13 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h3QIFD6k000735; Sat, 26 Apr 2003 11:15:13 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h3QIFCEq000734; Sat, 26 Apr 2003 11:15:12 -0700 (PDT) (envelope-from marcel) Date: Sat, 26 Apr 2003 11:15:12 -0700 From: Marcel Moolenaar To: Anthony Naggs Message-ID: <20030426181512.GA570@dhcp01.pn.xcllnt.net> References: <20030426073334.GA85139@rot13.obsecurity.org> <20030426094135.GA970@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i cc: ia64@freebsd.org cc: Kris Kennaway Subject: Re: InformationWeek: Intel Sees A 32-Bit Hole In Itanium X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2003 18:15:19 -0000 On Sat, Apr 26, 2003 at 02:52:11PM +0000, Anthony Naggs wrote: > In article <20030426094135.GA970@dhcp01.pn.xcllnt.net>, Marcel Moolenaar > writes > >On Sat, Apr 26, 2003 at 12:33:34AM -0700, Kris Kennaway wrote: > >> IA-32 Execution Layer will take 32-bit code and convert it to 64-bit > >> code that the Itanium processor can run, an Intel spokeswoman > >> says. > > > >I wonder why the conversion if ia64 can already run ia32 applications. > > Quite slow, and Intel need to address AMD64's (perceived) lower risk > migration for x86 users. AIUI native IA-32 execution doesn't support > instruction extensions introduced on later Pentium models such as SSE, > (since Pentium III). It doesn't compute. The ia32 environment is not designed for performance, it's designed to be functional. This relates to risk and support. Not implementing SSE is a decision that directly relates to this. SSE is just a performance enhancement, which you can do without if your prime focus is functionality. What it means to me is that people don't just want an upgrade path, they want a fully fletched Pentium. Or at least, that is what I assume is perceived. Looping this back to FreeBSD, I'm having difficulty finding an attachment point. > >Maybe Intel is planning to retire the ia32 execution unit early to > >make room for caches and additional functional units? > > The IA-32 support takes little space at the moment, this would change > somewhat if Intel were pushed into including a Xeon with 4 (say) way > Hyper-Threading. This fits in with the above. The tradeoff between using die space for the ia32 engine or native ia64 execution like hyper-threading is not easily made if you need the space to improve native performance when market pressure also demands that it is used for the ia32. It's logical that you remove the conflict by taking a different road for ia32 execution. > So removing IA-32 wont yield much die space, but it > means Intel don't have to keep taking more space to give IA-32 support > comparable to their higher spec Pentium family. It also means Intel > aren't committed to including IA-32 execution forever more. Intel has never been committed AFAICT. The ia32 execution engine was always slated to be removed in favor of native execution once the upgrade path wasn't crucial anymore. Note that there's must fundamental difference here. The ia32 execution engine allows booting ia32 operating systems. The ia32 EL will not be able to do that, simply because it's part of the OS. The problem space will therefore be very different. The engine has to provide all the necessary traps/faults and exceptions, whereas the EL only has to deal with non-privileged instructions. > There is little information about the IA-32 Execution Layer as yet so > one must speculate a little: Intel have committed a lot of development > effort to this, and so wont to let it out of their control (or e.g. to > let Transmeta see the source). So including IA-32 EL will require > working through Non-Disclosure Agreements and around the need to only > (mostly) have executable code to include in FreeBSD. Yes, that's very plausible. Note that any motivated hacker can implement this on his/her own. You have both instruction sets fully documented, so you can start of with interpretation to get something of the ground. After that you can add JIT compilation and if you really want to get all Java, you add a hotspot compiler to further boost performance. > Writing a translator from IA-32 to reasonably optimized IA-64 would be > quite challenging. Porting Intel's IA-32 EL should not be too hard, > given the opportunity. It's an interesting topic for sure. HP already has something like that for their PA-RISC support. Pretty cool stuff. Nonetheless, nothing beats native code... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net