Personal computing discussed

Moderators: renee, mac_h8r1, Nemesis

  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
 
Flying Fox
Gerbil God
Posts: 25690
Joined: Mon May 24, 2004 2:19 am
Contact:

Tue Jan 08, 2008 7:28 pm

hyttemor wrote:
So how does the math look like? You have a 32-bit virtual address pointing to something that is larger than can be expressed with 32 bits :roll:
Which math are you talking about? Can you elaborate?
The Model M is not for the faint of heart. You either like them or hate them.

Gerbils unite! Fold for UnitedGerbilNation, team 2630.
 
hyttemor
Gerbil In Training
Posts: 3
Joined: Tue Jan 08, 2008 7:21 pm

Tue Jan 08, 2008 7:57 pm

No matter what you do, an application always uses 32-bit virtual pointers, correct? But if the physical address space is much larger than 4GB, how can such a pointer, with only 32 bits in it, point to something that is larger...
 
Flying Fox
Gerbil God
Posts: 25690
Joined: Mon May 24, 2004 2:19 am
Contact:

Tue Jan 08, 2008 8:15 pm

hyttemor wrote:
No matter what you do, an application always uses 32-bit virtual pointers, correct? But if the physical address space is much larger than 4GB, how can such a pointer, with only 32 bits in it, point to something that is larger...
On a 32-bit OS, no you can't (Data Center versions of Windows server OS excepted). The motherboard and chipset can address more than 32-bit in hardware.
The Model M is not for the faint of heart. You either like them or hate them.

Gerbils unite! Fold for UnitedGerbilNation, team 2630.
 
hyttemor
Gerbil In Training
Posts: 3
Joined: Tue Jan 08, 2008 7:21 pm

Tue Jan 08, 2008 8:24 pm

Flying Fox wrote:
On a 32-bit OS, no you can't (Data Center versions of Windows server OS excepted). The motherboard and chipset can address more than 32-bit in hardware.


You make an exception in the server edition of Windows (I know 32-bit Linux also can). I just wonder how you get from the 32-bit virtual pointer to the 36-bit (or more) physical pointer.
 
SilverOmega
Gerbil
Posts: 29
Joined: Mon Dec 17, 2007 12:36 pm

Tue Jan 08, 2008 9:27 pm

Sorry to interrupt but I have a quick question. I understand I won't see all 4 gigs on vista 32-bit and am not worried about it right now, but vista only sees 2.3 gigs instead of the normal 3-3.5 gigs. Any help? BIOS reads all 4 gigs if that helps.
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Tue Jan 08, 2008 9:47 pm

hyttemor wrote:
No matter what you do, an application always uses 32-bit virtual pointers, correct? But if the physical address space is much larger than 4GB, how can such a pointer, with only 32 bits in it, point to something that is larger...
I'll try to keep this simple; if you want more details, I'll dig up some links.

PAE allows a 32bit OS to manage more than 32bits of physical memory. It does this using a variation of the same mechanism it uses to manage 32bits of physical memory. On the x86 (in protected mode), the translation of a virtual memory pointer to a physical address involves indirecting through several levels of pointers. This indirection is set up by the OS by creating tables of pointers in memory, but the actual translation (chasing the pointers) is handled by the hardware. Conceptually, a 32bit address uses 20bits to select a 4K page, and then 12bits to identify the byte within that page. But in practice, the address translation machinery goes through several levels (pointers to pointers to pointers) and there are extra bits involved at each level even in 32bit mode to track/enforce things like page status bits (read-only, kernel/user, etc). In PAE mode the final level of pointers are actually 64bit values, of which some bits are reserved, some are used for other things (like the NX/XD no execute bit), and 24 are used to select a page. That's 24bits, not 20, and those extra 4 bits are what give you access to (up to) 36bits of physical memory (when combined with the 12bit index into a page). The OS manages those tables of pointers, and it can certainly read and write 64bit values, so even though it can can only address 32bits of virtual memory itself, it can fill out entries that are more than 32bits long; the hardware takes care of actually grabbing the right page of physical memory -- and that's the piece that is more than 32bit, and why you need a motherboard and chipset that supports it for this to work.

The applications likewise are only using 32bit pointers for virtual memory, but when they hand them to the OS to get at physical memory they have no idea where that memory is actually coming from. Thus (under PAE) several application can be occupying more than 4GB of physical memory in aggregate but each of them is still operating within a 32bit virtual address range. (Similarily, they can occupy more than the amount of physical RAM you have installed even when that's less than 4GB; the excess goes into the page file).

It's actually considerably more complex than this, because what I (simplistically) described is the paging mechanism for 4K pages; x86 allows other page sizes (2MB and 4MB) which cause addresses to be handled differently. In addition, in PAE mode there's an extra (3rd) level of indirection, so the way those tables get set up and the way an address gets translated changes as well. And 64bit mode uses this same indirection mechanism to translate virtual addresses to physical addresses, but it use four levels of tables.

There's also a mechanism in Windows called Address Windowing Extensions (AWE). This allows an application to play these kinds of games within itself. Essentially the app defines a "window" in its (virtual) address range, and then calls a API which -- presto chango -- swaps out whatever is in that range and replaces it with a fresh memory that the app can do with as it likes. When that's full, it can call the API to swap it out again for yet another fresh range, or switch back to the old data. In this way you can have access to more physical memory than your address space allows. As you would expect, this operation is slow (there's no help from the hardware) and requires a lot of bookkeeping code in the app (in a sense you have to implement your own virtual memory management system). It's also of limited utility on a machine that doesn't have a lot of physical memory already, since the memory you swap out has to go somewhere and you're just going to end up paging a lot if you don't have excess physical memory. And if your app is going to require so much (>4GB) physical memory anyway, why not write for 64bit? These days, with 64bit CPUs and OSes available, the sooner AWE is forgotten the better.
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Tue Jan 08, 2008 9:51 pm

SilverOmega wrote:
Sorry to interrupt but I have a quick question. I understand I won't see all 4 gigs on vista 32-bit and am not worried about it right now, but vista only sees 2.3 gigs instead of the normal 3-3.5 gigs. Any help? BIOS reads all 4 gigs if that helps.
Let me guess -- you have two 768MB GeForce 8800 in SLI?
 
SilverOmega
Gerbil
Posts: 29
Joined: Mon Dec 17, 2007 12:36 pm

Tue Jan 08, 2008 10:22 pm

No. Two 512mb GeForce 8800 in SLI
 
derFunkenstein
Gerbil God
Posts: 25427
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Tue Jan 08, 2008 10:32 pm

well, the more graphics RAM you have, the more memory addresses you're giving up...
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
Twittering away the day at @TVsBen
 
Captain Ned
Global Moderator
Posts: 28704
Joined: Wed Jan 16, 2002 7:00 pm
Location: Vermont, USA

Tue Jan 08, 2008 10:39 pm

So, if I read it correctly, PAE is about the same with respect to WinXP as EMM was to DOS 5.0, within the limitations of the respective OSs.
What we have today is way too much pluribus and not enough unum.
 
Krogoth
Emperor Gerbilius I
Posts: 6049
Joined: Tue Apr 15, 2003 3:20 pm
Location: somewhere on Core Prime
Contact:

Tue Jan 08, 2008 10:41 pm

Captain Ned wrote:
So, if I read it correctly, PAE is about the same with respect to WinXP as EMM was to DOS 5.0, within the limitations of the respective OSs.


Yep, and the whole 4GB problem mirrors the nastiness of EMS back in 1980s where 640KB didn't cut it. ;)
Gigabyte X670 AORUS-ELITE AX, Raphael 7950X, 2x16GiB of G.Skill TRIDENT DDR5-5600, Sapphire RX 6900XT, Seasonic GX-850 and Fractal Define 7 (W)
Ivy Bridge 3570K, 2x4GiB of G.Skill RIPSAW DDR3-1600, Gigabyte Z77X-UD3H, Corsair CX-750M V2, and PC-7B
 
bhtooefr
Lord High Gerbil
Posts: 8198
Joined: Mon Feb 16, 2004 11:20 am
Location: Newark, OH
Contact:

Tue Jan 08, 2008 10:45 pm

derFunkenstein wrote:
well, the more graphics RAM you have, the more memory addresses you're giving up...

I thought they patched that already, and that was only on Vista?

AGP/PCIe aperture definitely does affect the memory addresses you're giving up, though, IIRC.
Image
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Wed Jan 09, 2008 12:42 am

Krogoth wrote:
Captain Ned wrote:
So, if I read it correctly, PAE is about the same with respect to WinXP as EMM was to DOS 5.0, within the limitations of the respective OSs.
Yep, and the whole 4GB problem mirrors the nastiness of EMS back in 1980s where 640KB didn't cut it. ;)
Well, no. EMM then is more like AWE now, in the sense that it's totally up to the app to handle it (often badly). PAE is completely transparent to the application; the entire burden is on the OS. But a fundamental assumption about virtual memory systems is that the virtual address space is bigger (a lot bigger) than the physical address space. When that's not true, all sorts of inefficiencies and ugliness begin to show up. The user, and the application, is largely oblivious to this but it makes OS designers crazy -- if you look back through this thread, you'll find links to Linus Torvalds' rather, uh, intense opinions on the subject.

So, in the sense that "there's a better answer out there, and it involves switching to a new OS that takes advantage of a new feature in the CPU" then yes: the answer then was Win95/OS/2 and protected mode, today it's Win x64 / Linux and 64bit.
 
todd
Gerbil XP
Posts: 339
Joined: Mon Mar 01, 2004 2:02 pm

Fri Jan 18, 2008 8:57 pm

I have the same problem as noob. Can't find the memory remap.
Gigabyte GA-M69G-S3H, which according to gigabyte supports 16 GB of ram. 4 one GB sticks in there but only shows 3.25. Not that big a deal right now, but I'd like to know my board has the bios settings to overcome this if it ever becomes a problem.
 
morphine
TR Staff
Posts: 11600
Joined: Fri Dec 27, 2002 8:51 pm
Location: Portugal (that's next to Spain)

Fri Jan 18, 2008 10:45 pm

todd wrote:
I have the same problem as noob. Can't find the memory remap.
Gigabyte GA-M69G-S3H, which according to gigabyte supports 16 GB of ram. 4 one GB sticks in there but only shows 3.25. Not that big a deal right now, but I'd like to know my board has the bios settings to overcome this if it ever becomes a problem.

You're using XP 64 or Vista 64, right?
There is a fixed amount of intelligence on the planet, and the population keeps growing :(
 
Flying Fox
Gerbil God
Posts: 25690
Joined: Mon May 24, 2004 2:19 am
Contact:

Fri Jan 18, 2008 11:31 pm

I take it you meant the GA-MA69G-S3H board?

Try hitting Ctrl-F1 to get the Advanced Settings to see if the option is there. I don't even see CnQ there that's a little odd.
The Model M is not for the faint of heart. You either like them or hate them.

Gerbils unite! Fold for UnitedGerbilNation, team 2630.
 
derFunkenstein
Gerbil God
Posts: 25427
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Fri Jan 18, 2008 11:48 pm

bhtooefr wrote:
I thought they patched that already, and that was only on Vista?

AGP/PCIe aperture definitely does affect the memory addresses you're giving up, though, IIRC.

I'm not talking about aperture; I'm talking about a total of 1GB of video memory + whatever other addresses it needs. You can see what the BIOS detects as memory (without re-map enabled) and find that it's going to be the same as what Windows sees.
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
Twittering away the day at @TVsBen
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Sat Jan 19, 2008 3:47 am

AMD tends to call this "hoisting" while Intel calls it "reclaiming" BTW, though the BIOS writers may call it any crazy thing. Whatever name it goes by, it involves placing that last GB or so of memory above the 4GB boundary rather than losing it "behind" the PCI address space.
Flying Fox wrote:
I take it you meant the GA-MA69G-S3H board?

Try hitting Ctrl-F1 to get the Advanced Settings to see if the option is there. I don't even see CnQ there that's a little odd.
Yeah, I grabbed the manual off Gigabyte's site and I don't see anything in there. Assuming the support is in the hardware (I don't know) you may need them to do a BIOS update. If the support isn't in the hardware, you're screwed.
 
todd
Gerbil XP
Posts: 339
Joined: Mon Mar 01, 2004 2:02 pm

Re: Dude, where's my 4GB?

Mon Jan 21, 2008 3:05 pm

Yeah, it's a GA-MA69G-S3H. XP pro 32bit. I'll try to put up a bios shot later.

I was wondering if the hoisting might be built in? Otherwise, how can the board support 16GB of ram? I'm guessing that is incorrect thinking?
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Re: Dude, where's my 4GB?

Mon Jan 21, 2008 3:27 pm

todd wrote:
I was wondering if the hoisting might be built in? Otherwise, how can the board support 16GB of ram? I'm guessing that is incorrect thinking?
It can still support 16GBm but you'll only have access to ~15GB of that. (With hoisting, physical RAM lives 0-3GB and then 4-17GB, avoiding the PCI addresses between 3 and 4; without hoisting, RAM just runs 0-16GB and the chunk between 3 and 4 is "lost" to PCI). Of course, just because a board uses a chipset claiming to support 16GB doesn't mean that particular board's implementation will support 16GB.
 
morphine
TR Staff
Posts: 11600
Joined: Fri Dec 27, 2002 8:51 pm
Location: Portugal (that's next to Spain)

Re: Dude, where's my 4GB?

Mon Jan 21, 2008 3:49 pm

todd wrote:
Yeah, it's a GA-MA69G-S3H. XP pro 32bit. I'll try to put up a bios shot later.

Uh dude... you're not going anywhere until you install a 64-bit OS, sorry. The 32-bit limit itself is up to 4GB, and that has to go for your RAM *and* the devices. That's why you only get 3.odd GB of RAM, that's 4GB less chunk and change for the graphics card and other devices.
There is a fixed amount of intelligence on the planet, and the population keeps growing :(
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Re: Dude, where's my 4GB?

Mon Jan 21, 2008 4:36 pm

morphine wrote:
todd wrote:
Yeah, it's a GA-MA69G-S3H. XP pro 32bit. I'll try to put up a bios shot later.

Uh dude... you're not going anywhere until you install a 64-bit OS, sorry. The 32-bit limit itself is up to 4GB, and that has to go for your RAM *and* the devices. That's why you only get 3.odd GB of RAM, that's 4GB less chunk and change for the graphics card and other devices.
Yes, that's quite true. I was assuming he was planning on moving to 64bit, but perhaps I was assuming too much. In any case, that wouldn't affect whether remapping was available in the BIOS -- but if it was available, he'd still need a 64bit OS to benefit from it.
 
bhtooefr
Lord High Gerbil
Posts: 8198
Joined: Mon Feb 16, 2004 11:20 am
Location: Newark, OH
Contact:

Re: Dude, where's my 4GB?

Mon Jan 21, 2008 4:46 pm

UberGerbil wrote:
Yes, that's quite true. I was assuming he was planning on moving to 64bit, but perhaps I was assuming too much. In any case, that wouldn't affect whether remapping was available in the BIOS -- but if it was available, he'd still need a 64bit OS to benefit from it.


Actually, any 32-bit OS that supports PAE EXCEPT FOR WORKSTATION VERSIONS OF WINDOWS will work, too.

Windows Server 2003, Linux, BSD, etc., etc.
Image
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Re: Dude, where's my 4GB?

Mon Jan 21, 2008 5:00 pm

bhtooefr wrote:
UberGerbil wrote:
Yes, that's quite true. I was assuming he was planning on moving to 64bit, but perhaps I was assuming too much. In any case, that wouldn't affect whether remapping was available in the BIOS -- but if it was available, he'd still need a 64bit OS to benefit from it.
Actually, any 32-bit OS that supports PAE EXCEPT FOR WORKSTATION VERSIONS OF WINDOWS will work, too.

Windows Server 2003, Linux, BSD, etc., etc.
Yeah, if you read back through this very thread you'll see I made that point several times. But PAE is a bad solution to the problem except in very specific (mostly server) situations, it's significantly more expensive in the Windows world, and ultimately it's a dead end. We should stop talking about it. The future is 64bit, and we really shouldn't be confusing the issue for most users. The users who understand PAE, have a specific case where it makes sense, and (if they're Windows users) have the budget for Windows Server generally already know what they're getting into and aren't asking for advice here.
 
todd
Gerbil XP
Posts: 339
Joined: Mon Mar 01, 2004 2:02 pm

Re: Dude, where's my 4GB?

Tue Jan 22, 2008 3:08 pm

UberGerbil wrote:
morphine wrote:
todd wrote:
Yeah, it's a GA-MA69G-S3H. XP pro 32bit. I'll try to put up a bios shot later.

Uh dude... you're not going anywhere until you install a 64-bit OS, sorry. The 32-bit limit itself is up to 4GB, and that has to go for your RAM *and* the devices. That's why you only get 3.odd GB of RAM, that's 4GB less chunk and change for the graphics card and other devices.
Yes, that's quite true. I was assuming he was planning on moving to 64bit, but perhaps I was assuming too much. In any case, that wouldn't affect whether remapping was available in the BIOS -- but if it was available, he'd still need a 64bit OS to benefit from it.


Thank you. That's really what I was trying to get at. If the bios doesn't support remapping, and apparently it doesn't, then I'm not going to get ALL of my memory, whether it's 4 gigs or 16 gigs. Though if I went with a 64 bit OS, I could get 15GB out of the 16. Correct?

I actually think my system ran a little better with 2GB of ram. Until I started doing some encoding, where I noticed my peak commit charge in task manager was 2.75GB after upgrading to 4GB. The system only sees 3.25GB. I never noticed what the peak was with 2GB of ram, but I'm wondering if the peak would go up if I installed even more?

Of course I doubt I'd be willing to install any more ddr2 800, considering I'd have to completely ditch the 4 sticks I currently have for 4X2GB sticks, and I don't have another board to put the X1's in. Have to wait for the next new system.
 
Shining Arcanine
Gerbil Jedi
Posts: 1718
Joined: Wed Jun 11, 2003 11:30 am

Re:

Wed Jan 30, 2008 11:40 am

just brew it! wrote:
l33t-g4m3r wrote:
then this would be the most relevant article.
http://en.wikipedia.org/wiki/X86-64

you're talking about whether or not the hardware supports the memory.

No, he's not.

He's talking about whether the hardware supports splitting the physical RAM addresses into two blocks, to avoid the addresses which are reserved for I/O devices in the 3-4GB range. This is a different issue.


The memory addresses in the 3-4GB range are not reserved for I/O devices. The I/O devices have their own separate 4GB address range that is in x86 exclusively intended for them. The only thing is that with the exception of some USB devices, nothing uses them. Back when 32bit computing was new, driver writers decided that instead of using the 4GB I/O address range that was meant for them, they would use memory addresses instead, as with 2^32 addresses, it was unfathomable that they would ever be needed. If all of the driver writers would modify their drivers to use the I/O address range like they are supposed to use, there would be no problem, but none of them do.
 
Flying Fox
Gerbil God
Posts: 25690
Joined: Mon May 24, 2004 2:19 am
Contact:

Re: Re:

Wed Jan 30, 2008 12:50 pm

Shining Arcanine wrote:
The memory addresses in the 3-4GB range are not reserved for I/O devices. The I/O devices have their own separate 4GB address range that is in x86 exclusively intended for them.
Link please?
The Model M is not for the faint of heart. You either like them or hate them.

Gerbils unite! Fold for UnitedGerbilNation, team 2630.
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Re: Re:

Wed Jan 30, 2008 1:51 pm

Flying Fox wrote:
Shining Arcanine wrote:
The memory addresses in the 3-4GB range are not reserved for I/O devices. The I/O devices have their own separate 4GB address range that is in x86 exclusively intended for them.
Link please?
See Chapter 10 of the Intel Architecture Software Developer's Manual, Volume 1: Basic Architecture (PDF)

Don't go blaming the driver writers for this. It was the IHVs, with Intel's encouragement, who went with memory mapped IO. And with good reason. The IO address space (which dates back to the 8080) is not 4GB. It is 64KB. Sixty-four Kilobytes. For all devices. So you're back to 16bit addressing limitations. Have fun moving big textures through that. And, btw, you're using the In/Out opcodes to move bytes/words, and the Ins/Outs to move strings. No Mov or any of the other string instructions for you. And it has to go somewhere, which in practical terms means the memory is going to be in use anyway, just by the OS or the individual programs to buffer it before/after the IO. Also, the IO operation is guaranteed to be atomic, so you have a pipeline stall: no other instruction on that thread can execute until the IO operation completes.

The IO address space was a necessary hack when 16bit made for a tight address space and the package was short on pins. None of that has been true in almost 20 years. There's a reason why every serious modern architecture uses memory-mapped IO

The driver writers, if they wanted to, could write drivers that just use IN and OUT. But the devices would still occupy memory -- they just wouldn't be doing anything with it. To make the devices not occupy any of the memory map, they'd also have to modify the firmware on the device to change the configuration registers so no memory was requested. And sure, Intel could extend the IO address space, update the instructions to use it, and add a bunch more IO instructions to match what is available for memory ops.

But why? To avoid occupying less than a GB of address space? There are terabytes available! We had this problem before, when we were running into 64K. And 640K. The solution is to go to 64bit, not to hack around trying to re-use some old 16bit technology to eke a little more life out of a 32bit design.
Last edited by UberGerbil on Wed Jan 30, 2008 2:13 pm, edited 1 time in total.
 
Flying Fox
Gerbil God
Posts: 25690
Joined: Mon May 24, 2004 2:19 am
Contact:

Re: Re:

Wed Jan 30, 2008 2:11 pm

UberGerbil wrote:
Flying Fox wrote:
Shining Arcanine wrote:
The memory addresses in the 3-4GB range are not reserved for I/O devices. The I/O devices have their own separate 4GB address range that is in x86 exclusively intended for them.
Link please?
See Chapter 10 of the Intel Architecture Software Developer's Manual, Volume 1: Basic Architecture (PDF)

Don't go blaming the driver writers for this. It was the IHVs, with Intel's encouragement, who went with memory mapped IO. And with good reason. The IO address space (which dates back to the 8080) is not 4GB. It is 64KB. Sixty-four Kilobytes. For all devices. So you're back to 16bit addressing limitations. Have fun moving big textures through that. And, btw, you're using the In/Out opcodes to move bytes/words, and the Ins/Outs to move strings. No Mov or any of the other string instructions for you. And it has to go somewhere, which in practical terms means the memory is going to be in use anyway, just by the OS or the individual programs to buffer it before/after the IO. Also, the IO operation is guaranteed to be atomic, so you have a pipeline stall: no other instruction on that thread can execute until the IO operation completes.

There's a reason why every serious architecture uses memory-mapped IO

The driver writers, if they wanted to, could write drivers that just use IN and OUT. But the devices would still occupy memory -- they just wouldn't be doing anything with it. To make the devices not occupy any of the memory map, they'd also have to modify the firmware on the device to change the configuration registers so no memory was requested. And sure, Intel could extend the IO address space, update the instructions to use it, and add a bunch more IO instructions to match what is available for memory.

But why? To avoid occupying memory? There are terabytes available! We had this problem before, when we were running into 64K. And 640K. The solution is to go to 64bit, not to hack around trying to re-use some old 16bit technology to eke a little more life out of a 32bit design.

It wouldn't be Chapter 13 by any chance? ;)

Read that. I never knew it existed. :oops: :o
The Model M is not for the faint of heart. You either like them or hate them.

Gerbils unite! Fold for UnitedGerbilNation, team 2630.
 
UberGerbil
Grand Admiral Gerbil
Posts: 10368
Joined: Thu Jun 19, 2003 3:11 pm

Re: Re:

Wed Jan 30, 2008 2:20 pm

Flying Fox wrote:
It wouldn't be Chapter 13 by any chance? ;)

Read that. I never knew it existed. :oops: :o
Perhaps the notorious Appendix H.

Really, unless you're writing drivers or writing low-level kernel or embedded code -- or you just date back to the days when essentially that's all any program was -- there's no reason to know about it. It's like segmented addresses: a necessary hack at the time, but now an ugly complication no one wants to deal with...and no one has to. Intel has been trying to ignore it for a couple of decades now, and the rest of the industry has followed suit.
  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

Who is online

Users browsing this forum: No registered users and 1 guest
GZIP: On