"what a crock the X86 architecture is"
|
Prev: USE MY WEBSITE FOR ORDER Tramadol! BUY Tramadol HERE - FANTASTIC PRICE! buy cheap Tramadol prescriptions online
Next: 16:32 far pointers in OpenWatcom C/C++
From: Rick Jones on 25 Mar 2010 20:29 In comp.sys.intel Jim Stewart <jstewart(a)jkmicro.com> wrote: > Scott Lurndal wrote: > > The biggest advantage of UEFI is that it is _NOT_ a traditional > > BIOS. Anyone who has had to develop a BIOS or develop for a > > traditional BIOS knows how much of a chore it is; even if one can > > use flat real mode. > But it makes for some damn fine job security... I thought that was what COBOL was for?-) rick jones -- I don't interest myself in "why." I think more often in terms of "when," sometimes "where;" always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Jonathan de Boyne Pollard on 25 Mar 2010 22:46 > >>> >>> having mentioned those things I suspect now I'll get a futher >>> education about BIOS :) >>> >> Very possibly, but I for one agree that chained boot managers/loaders >> can be difficult to manage. Unfortunately, as I explain on my >> Frequently Given Answer about the EFI boot process, EFI systems >> aren't wholly free from such madness. (There you go. Further >> education about EFI, instead. (-:) >> > Touche :) I'd love a pointer to your FGA/FAQ > You should have one, by now. > not having directly interacted with (U)EFI on x86 systems, wonders if > there is an HP Integrity style EFI boot menu etc. > All EFI systems are required by the specification to have a boot manager. However, the madness alluded to above is in relation to this very thing. See the Frequently Given Answer.
From: Jonathan de Boyne Pollard on 25 Mar 2010 22:55 > > > Verification is the most time consuming and important part of > processor design and manufacturing. Not having to verify real mode > (and particularly V86 mode) will lead to faster design cycles and > other internal efficiecies. > You might still be overestimating how much of a savings that that may be. As I said, the savings, such as they are, would be for the operating systems writers and chipset manufacturers more than for the processor vendors. On which point: > Note that not only Intel wins here, as you pointed out, so do any > hypervisor or operating system devlopers/vendors that wish to run on > modern hardware � they can at some point in the product cycle say > forget PIII; you need a 64-bit Opteron or Xeon to run our newest > OS/Hypervisor/etc. Particularly hypervisors for which new silicon > capabilities appear each tock. > > Think of all the legacy stuff like a PIC, PIT or RTC that could be > eliminated from the chipset, or the elimination of IN/OUT ports in > favor of MMIO; 64-bits provides a lot of address space. > Indeed. Hence why I said that the chipset manufacturers would benefit more from such a thing more than the processor vendors would. There's an awful lot of stuff that one pretty much can throw away in such a scenario. And unlike the case for the processors, where the hardware to perform real/v8086 mode doubles up as the hardware that performs protected mode, there's less overlap in a chipset. You point out some of the old IBM PC chips that a modern PCI-to-ISA bridge has to emulate. But there's both less and more than what you stated. There's less in that one doesn't throw away a RTC. A protected mode PC operating system still needs real-time clock hardware. It can simply be a purely PCI device, rather than an ISA device with a fixed location, though. There's more in that there are other things that you haven't mentioned. There's the PS/2 keyboard/mouse emulation for non-USB-cognizant operating systems when one has a USB keyboard/mouse, for example. And there are even things like the special case PCI bridge circuitry for VGA display adapter emulation by PCI display adapters. Which brings us to operating systems: > One would maintain compatibility for user-mode apps (32-bit and 64-bit > only) for some number of generations, then eliminate the 32-bit > compatbility at some well-defined and well-advertised point in the > future, but the operating software only runs in long mode. > The gain of a (semi-)hypothetical pure EFI, no-support-for-real-mode, x86 system for operating system developers/vendors isn't really API simplicity. Unfortunately, the complexities of having to support all of the BurgerMasters and Bozos in the recent APIs (If you don't know the story behind these, then find and read Raymond Chen's explanation.) often outweighs the complexity of supporting running DOS applications in Virtual DOS Machines. After all, as long since demonstrated, purely software VDMs are possible, which means that changes in hardware capabilities are largely irrelevant to whether one still provides compatibility with DOS applications. (Of course, lack of real/v8086 mode doesn't affect compatibility support for 16-bit OS/2 or Win16 applications either, since such applications run in protected mode, not real/v8086 mode.) Application compatibility is largely divorced from what we're discussing here. The major gain for operating systems vendors is the one that EFI is explicitly aimed at providing: Bootstrap code becomes a lot simpler. There is, for example, a standard mechanism in EFI for passing parameters to an operating system boot loader. So operating systems don't have to roll their own BOOT.INIs and Boot Configuration Databases any more, just so that there's somewhere to store a few "command-line" options. There's all of the MBR/VBR code that simply goes away. There are no more worries about writing one's own first-stage boot loaders, since EFI has a program loader. One doesn't necessarily have to have mini-FSDs, since EFI provides a filesystem driver capable enough for loading the kernel's own filesystem drivers (as long as one can live with the maintenance issues of having those drivers live on the EFI System Partition). One doesn't have to write special highly-platform-specific console I/O code for user interaction very early on in the boostrap process, because EFI provides a console I/O subsystem ready-made. And of course the whole switch-to-protected-mode issue goes away, too. On the gripping hand, it's mainly those latter gains in bootstrapping that one will see in the real world at the moment. Notice that Intel Macintoshes use off-the-shelf components. It's probably not still economically viable to produce (for example) custom VGA-less display adapter and PCI bridge chips just for systems that don't support real/v8086 mode operating systems. Although people looking to produce such systems in the future might find encouragement in the observation that no-one seems to have seriously wanted to run anything less than Windows NT 5 on Intel Macintoshes. Also on the gripping hand, there are things that one can gain from EFI that really have nothing to do with the processor architecture or the firmware, and thus are largely disjoint from discussion of a putative x86 architecture without real/x8086 mode and with EFI firmware. The EFI partition table scheme has nothing to do with the processor architecture, for example. But as anyone who has written a modern disc partitioning utility will almost certainly state (as I, for one, do) it's significantly simpler to handle than the MBR partition table scheme is. No multiplicity of container partition types; no container partition re-sizing; no chaining; no variously-supported extensions; no differences of opinion on fake CHS geometries; and no having to worry about preserving reserved areas so as not to overwrite the computer viruses hiding in them.
From: Noob on 26 Mar 2010 10:52 Jonathan de Boyne Pollard wrote: > You point out some of the old IBM PC chips that a modern PCI-to-ISA > bridge has to emulate. But there's both less and more than what you > stated. There's less in that one doesn't throw away a RTC. A protected > mode PC operating system still needs real-time clock hardware. Wasn't the HPET supposed to replace the RTC? http://en.wikipedia.org/wiki/High_Precision_Event_Timer Regards.
From: Quadibloc on 27 Mar 2010 17:06
On Mar 24, 5:38 pm, Jonathan de Boyne Pollard <J.deBoynePollard- newsgro...(a)NTLWorld.COM> wrote: > It's not as if > there is a whole 8086 in every x86 CPU that can be thrown out to make > space. No, all the design flaws of the original 8086 architecture are still around to haunt the processors in 32-bit and 64-bit mode. The good guys (680x0) lost. John Savard |