OSDev.org

//I stated that it should generate and exception "(in this case)".
Thats what the extand down flag is used for: the offset of 0xffffffff is interpreted as -1.(The segment expands down from the base adress.)
When i said assembly is not a portable language, i meant between different architectures : PowerPC, ARM, Sparc, ....(The world does not end on Intel and Microsoft)

//I referred to pointers as being unsigned simply because that is the most
//logical way to interpret them, simply because address 0xffffffff is higher in
//memory than 0x0, not lower.
the offset is not a adress, it's a index. So, stating it is C it would look like:
char *base_adr;
base_adr = logical adress of byte 0;
int offset;//note int, not int*;if you need a positive high adres, then use
//unsigned int
base_adr[offset] is the logical adress of the needed byte, which is base_adr + offset. And no cheking is made. If there would be cheking, then it wold be imposible to take a byte before the base adress, which is usefull, if you want to have a grown stack.

//And if you've taken any kind of design class (hardware or software)
// you should have learned that you should plan for future changes
Yes, that's why no programs in todays world are writen in asm. Only small(tiny) pices of code are writen in OSs, like task switching.

Anton.

Look, this arguing is stupid, and a waste of my time and your time, especially since you misinterpret half the things I say (and I probably misinterpret half the things that you say). I am really tempted to keep arguing though. It's kind of fun.

Hi,

I never considered the possiblity of a virtual_address overflow wrapping around.

But the calculation "virtual_address = base + offset" is done inside the processor, I would have assumed it was smart enough to recognise 33 bit addresses and generate an error.

eg say you have ds with a base of 0FFFFFFFFh, and you do

mov [ds:100h], dword value

the processor internally tries to do (0FFFFFFFFh + 100h) and returns a 33 bit address. I think its same to assume the processors automatically recognise these situations, and you don't need to worry about them.


As for expand-down segments, don't waste your time with them. They are non-portable to other cpu architectures, and i am 99.5% certain linux and windows don't use them.

//As for expand-down segments, don't waste your time with them. They are non-
//portable to other cpu architectures, and i am 99.5% certain linux and windows
//don't use them
Expand-down segments are used by ALL architectures(except Intel 80960, which has a expand-up stack segment), so it is portable. And ofcourse, Windows and Linux uses them(The stack starts out at about 3G, and goes down). The other thing is, that only intel has segments concept in terms of a base-address and limit.
Anton.

Thanks Anton for the info. You said Windows uses expand-down seg. Would you give an example? TIA!!

First, could you decode TIA, since i don't know slang(email slang) that good.
Second, what do you mean by "Would you give an example?"
Anton.

Sorry Anton. I mean, where does Windows use expand-down seg? (which Windows version, which part of the kernel, why the kernel needs an expandable stack, can it use guard pages instead, etc.)
Thanks in advance!(tia)

Actualy, i realised today, that the message about expand-down seg and it's relation to Windows, and Linux, was stated misleading. I ment to say that expand-down segs are portable, since the use of the stack is transparent to programs, so all that is needed to be done, is a new realization of a stack(like guard pages). As concerning the use of expand-down seg in Windows and Linux, it is incorrect. I ment that they use an expand-down stack which starts at high mem,(which i gess is obvios). I always forget(or i should say that the intel terminology is the case of this), that for a expand down stack an expand down seg is not needed.
Anton.
PS.
Again, i repeat, that that message was writen after a hard day at work.

For a more detailed explanation of Expand Down Segments, see

http://www.sudleyplace.com/dpmione/expanddown.htm