Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (
More info?)
Hi,
"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote:
> On Thu, 28 Oct 2004 04:36:17 GMT, "Brendan Trotter"
> >One unfortunate reality is that the harder it is to write an
> >operating system the better Microsoft's position becomes.
> >They have the resources, etc to handle an ever increasing
> >list of bugs, etc while a company attempting to write a
> >competing OS would need to begin from scratch without
> >the resources (including prior versions that handle prior
> >bugs). I've often wondered if the (mostly Microsoft's) ACPI
> >standard is a deliberate attempt to make the architecture
> >more complex, and therefore make things hard for other
> >OS's (e.g. Linux).
>
> Well to a certain extent, their size works against them - IME software
> projects -- any high-tech endeavor? -- have diminishing returns as the
body
> count for co-ordination increases.
🙂
Sure, but even though writing an OS (as opposed to just a kernel)
is an extrememly large project, it can be easily split up into
many seperate parts (all that's needed is well designed/documented
interfaces between these parts). Microsoft would be able to recycle
the almost all of thier existing design & interfaces, then assign
manageable teams to each part. Come to think of it they could
re-use most of the existing 32 bit code (using "compatibility mode")
without any changes as long as they've got a decent 64 bit kernel
behind it. Makes me wonder how much of "Microsoft Windows XP
64 bit Edition" actually is 64 bit.
> >I haven't seen it, but they announced a beta version of XP for
> >AMD's 64 bit CPUs in September last year and you can currently
> >download a trial/pre-release version of it.
>
> Yes and reports are mixed on whether it works with EM64T... even after
> being patched for the Intel inadequacy.
Hmmm, are the reports mixed for AMD's 64-bit chips too? I
wouldn't be surprised if Microsoft is having a few
generic teething troubles...
> >Specifically talking about the 36/40 bit physical address size bug, it
> >really doesn't make any difference to an OS. The OS normally
> >uses BIOS functions to determine what memory is installed, so as long
> >as the computer hasn't got more than 64 Gb installed it won't
> >actually matter.
>
> I'm no OS designer but I'd have thought that, given this is a "PC design",
> the high mapping of "reserved", BIOS and adapter memory to the *different*
> 36-bit upper boundary of physical addressing could be very troublesome...
> if you want to produce common code.. which I'd think would be err...
> good.
🙂 <sigh>It *could* have all been so much easier.
It shouldn't effect the BIOS either. 64 bit AMD CPU's start
executing in real mode with a modified CS base, such that
CS:EIP = 0xFFFF0000:0xFFF0 or address 0xFFFFFFF0. While I
haven't been able to confirm it, it's safe to assume Intel's
64 bit CPUs also start execution just below 4 Gb. Therefore
the BIOS/chipset would still map it's ROM so that it ends at
4 Gb (e.g. a 1 Mb ROM mapped at 0xFFF00000).
Because of this (and for compatibility with legacy OS's) I
expect memory mapped PCI/AGP devices will also continue to
use physical addresses below 4 Gb. This creates another "hole"
in physical memory, where an 128 Gb computer might have the
first 3 Gb of RAM at the lowest physical addresses, then a
1 Gb gap (for PCI/AGP & BIOS), followed by the remaining
125 Gb starting at physical address 0x100000000 (4 Gb).
> The 32-bit DMA is even more troubling - it took more than a decade to
> finally be able to produce an OS which didn't *have* to have double
> buffering built in; just when we were nearly there, it's..... back you go!
> I'm not sure what the details are on the capability of current AGP cards
to
> handle the "type 4" SBA requests for >36-bits, nor how PCI-Express fits in
> but it sounds like game designers would have a real mess, where they
either
> have to double buffer or keep their DMA transfer data below the main
memory
> 32-bit mark. The whole thing is just incredibly ridiculous. IMO when the
> details of this filter out in a form understandable by your average
> "analyst", Intel is going to look like a bumbling fool... Barrett could go
> early, yet!
<rant> I'd be happy to discuss this problem in entirety IF
I can have documentation for direct programming of modern
video cards and some PCI express documentation. Unfortunately
ATI and NVIDEA don't like it when people can actually write
software for thier products, and PCISIG have become
extortionists (the "special interest" seems to have changed).
</rant>
I will actually be quite pleased if PCI/AGP cards can never
access any main memory above 4 Gb, because my OS design
doesn't allow the "video driver process" to access other
address spaces, and is capable of making sure allocated
pages have physical addresses below 4 Gb where necessary
🙂.
Cheers,
Brendan
Facebook
Twitter
Instagram