Talk:Global Descriptor Table

Endianness

Might a brief discussion (or link to a discussion) on endianness and loading the table directly in assembly be appropriate here? I just did this myself, and I was bitten because, for example, I tried to use in my code selector 0x59 instead of 0x9a (which is 0x9a backwards). I'd update it myself but I don't quite understand: I get that bytes go from least to most significant, but I'm not entirely sure I understand how the bits work for something like this. Surgo 17:00, 24 January 2011 (UTC)

The bits are not affected, which is probably why you didn't find any mention of them. -- Solar 15:34, 25 January 2011 (UTC)

It's not that bits are not affected, it's actually that bits in a byte don't actually have any direction (don't let instructions like SHL or BT fool you --- they got their names based on common usage rather than functionality) despite being represented in one way or another by documentation. Bit positions are merely conventions whereas byte positions are tangible in software. This is precisely why we never talk about bits when discussing endianness. In case you don't understand, think of bytes as being represented in a row and each byte's bits being represented in a column; you end up with a Nx8 table... Which is bit 6? --Love4boobies 06:53, 26 January 2011 (UTC)

Bit #6 is the one that gives a value of 2^6 when set. (You do count from zero, right?) Look at it like this: If *bits* had an endianess, you would have to match endianess in your motherboard and the RAM you are using... ;-) -- Solar 14:05, 26 January 2011 (UTC)

That doesn't contradict what I've said :)

figure 3-1 refers to "Segmentation and Paging", nice overview, but has nothing to do with L-bit
New16 12:53, 25 July 2016 (CDT)

It did say Table 3-1, not Figure 3-1... but that wasn't correct either. I've changed it to Figure 3-8. John Burger 23:48, 25 July 2016 (CDT)