Date: Sat, 26 Apr 2003 11:15:12 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Anthony Naggs <tony@ubik.demon.co.uk> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: InformationWeek: Intel Sees A 32-Bit Hole In Itanium Message-ID: <20030426181512.GA570@dhcp01.pn.xcllnt.net> In-Reply-To: <iHaJEfAb0pq%2BIwcB@ubik.demon.co.uk> References: <20030426073334.GA85139@rot13.obsecurity.org> <20030426094135.GA970@dhcp01.pn.xcllnt.net> <iHaJEfAb0pq%2BIwcB@ubik.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 26, 2003 at 02:52:11PM +0000, Anthony Naggs wrote: > In article <20030426094135.GA970@dhcp01.pn.xcllnt.net>, Marcel Moolenaar > <marcel@xcllnt.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030426181512.GA570>