Magnus Christensson wrote:
>
> >>>>> "Kevin P. Lawton" <[EMAIL PROTECTED]> writes:
> Kevin>
> Kevin> - IA32 system environment, IA32 binaries, granted that the platform
> Kevin> and firmware support this. This is vague. I need to find out more.
> Kevin> Sounds like if your BIOS supports it, you could actually boot
> Kevin> into and use the processor in IA32-only mode.
> Kevin>
>
> The BIOS support needed is not very large. AFAIK it only has to
> redirect exceptions (remember that exceptions always puts the
> processor into IA-64 mode) to the IA-32 OS (and emulate some
> instructions (INVLPG, MOV2DR, LGDT, ...)).
I see what you're saying. Section 6.1.2 talks about an
interception fault upon access to system resources, and
a figure 6-1 shows a transtion to IA-64 mode for these
transitions.
The cleanest implementation for Intel to have taken
would have been to always do this, and ditch all the
logic relating to IA-32 system stuff. Some issues
are not clear to me yet, though. Like what mode does
this puppy boot up in, and if it can come up in IA-32
mode, does it have the ability to operate in only
that mode using intrinsic IA-32 system resources,
until a transition to IA-64 mode takes place?
I have a tendency to question Intel docs. :^)
It would be nice to have an analog to the "Volume 3:
System Programming Guide" for this.
Hope they gutted the IA-32 system features, and redirect
them 100% of the time to IA-64 world. If this is the case,
then since there's going to be an interception fault in the
same places we would introduce the same in FreeMWare, a user
might as well run a clean OS which has been ported to IA-64
(I hear Linux has) to service the computer in general. Then
use FreeMWare to run an OS that hasn't (I hear Windows
has not yet). Running Windows32 using a firmware wrapper
will not give you the performance potential of the processor,
because A) it's not optimized to use the EPIC strategies and
B) it will incur additional interception faults. Also,
a bunch of the overhead we impose with FreeMWare on IA-32
comes for free on IA-64.
Off topic, but interesting to me from a performance standpoint,
IA-64 uses a "Stacked Registers" concept.
("Windowed Registers" on the SPARC).
This can have performance implications
for fine-grained user-level threading where each thread
context switch necessitates spilling and filling of all
register frames. Since there's a lot of registers available
on this architecture, liberal use of them by generated
code in a compiler would make this worse. I'll be interested
to see how Merced benchmarks out in the threading department.
My take was that the SPARC people didn't think that using Windowed
Registers was such as hot idea in retrospect...
-Kevin
