------- Comment #43 from rogerio at rilhas dot com 2010-08-13 16:28 ------- (In reply to comment #41) > You should really adjust your glasses if you want to continue trolling with > the high standards we're used to meanwhile: > > > What in the words "real segmentation like on 286, where there's no linear > > > relationship between effective address and segment+offset" > So, I think it's pretty clear that I'm referring to the 80286, whereas > you cite something ...
Oh really? Because you so cleverly used the word "real" to lead me to believe you were talking about real mode 286? How clever of you, you were talking about protected mode after all. Ok, after interpreting your incorrect wording I can give you that: 286 protected mode was a pain. You just dropped your error rate to less than 100%, kudos!! (should adjust your phrasing though, if you want to be correctly inrepreted) > > From wikipedia: > > > > "Rather than concatenating the segment register with the address > > register, as in most processors whose address space exceeded their > > register size, the 8086 shifted the 16-bit segment only 4 bits left > ... about the 8086. To make it very obvious, even to you: 86 vs 286. > As you have so huge experiences with such old processors, I'm sure > you can guess what I meant with "real segmentation" aka protected mode now. There is no thing as "real segmentation", you must have made it up. The Linux community seems to talk a little about it... but I never saw Intel say or write anything about it when I was studying the 286. Linux guys use that expression, is that why you thought it was standard? Wrong. What Intel defined was "real mode" and "protected mode". So you see what you do when you don't use your words correctly and call it "real segmentation"? Of course it would look like "segmentation in real mode". Your bad. Unless you can backup "real segmentation" with some official doccument from Intel, can you? > In case you still can't and because we seem to start using wikipedia to back > up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation . No mention of "real segmentation". Is this what you wanted to show me? > Now, implement a routine that subtracts two pointer for this memory model. > You'll see that it requires bit-magic on the segment selector, > lookup in the GDT or LDT and finally some 24bit arithmetic to produce > the result. Yup, too much work. Better leave it alone and return some random pointer subtraction number. Better yet: don't compile such code. And never again guarantee to anyone anything about pointer subtraction unless it fits inside C99 box. I had one class on 286 which made us implement processes on a minimal protected mode OS for the 286. I can tell you it isn't that hard to read the LDT or GDT, and it didn't have any prohibitive performance penalty, contrary to what you claim. Maybe you are confusing yourself between reading from and writing to the GDT/LDT? Or maybe you can backup your claim that reading from GDT/LDT is prohibitive? > The arithmetic is of course trivial, the lookup is expensive. Could you please back it up? That's contrary to my experience, you see, and since it lacks logic since the processor reads to those tables were designed to be fast to make it run fast... so I think you should back that up, otherwise it just looks like you are making it up (not to me though, I know it wasn't prohibitive). > Doing it for every pointer subtract was what I called prohibitive expensive > for a normal pointer subtraction. Yes, you are wrong to call it prohibitive. You just want to imagine it to be prohibitive so that you can stick to your claim that pointer subtraction result is not guaranteed by GCC *EVER* because of the 286. What a boring unsubstantiated argument. Without backing up such illogical claims its all just jiberish. So go ahead and find a techncal paper or report that shows that reading the LDT or GDT causes a significant performance penalty. Let's set a threshold: 50 instructions? So, ok: if you can find such a document that says that accessing those tables always costs 50 instructions or more then I'll grant you that the compiler should have an option to disable correct pointer subtraction. I will still not grant you an incorrect pointer subtraction by default, but I will <insert apology here> in that my experience with 286 was unexplainably better than yours. If you can't find such a document then <insert apology here for making unsubstiated claims> and forget about it (apology accepted). > That, together with the fact that all > segments are max 2^16 in size, and that it's impossible to map back all > 24bit numbers into segmented addresses without generally adding new > entries into the GDT/LDT made it useless to have pointer differences > any larger than 16 bit, not impossible but useless in real compilers. > Therefore the result of such a subtraction isn't always representable. In the copilers I used back then the far pointer was 32-bit, just like it was 32-bit on the seg16:ofs16 pair. So the compilers we used didn't need to check on any GDT/LDT as they approached a flat 24-bit memory model and could do all arithmetic with the 32 bits alone. Didn't your compiler do that?? What did it do with a far pointer? Keep only the 16 bits? Really???? So you could only access 64k then? Crappy compiler. Your point has been proven for your crappy compiler, congratulations. I don't know how the compilers I used converted near to far and back, but we didn't really used to do that. However that is not the point because I never asked you about pointer subtraction with mixed qualifiers. In fact, you are just digging a deeper and deeper hole for yourself, as I placed 2 equivalent pointers: char* p1=... char* p2=... ... and then asked about their subtraction. None of them is far, because (as you should know) the default was near in just about every compiler (naturally!!). So you made up segmentation as an excuse, and you are drifting away form the original issue. That issue is that, on any platform, pointers defined like this must *ALYWAYS* return the correct difference. And for that original issue (as for many others we started making up as we went along) you are just wrong. Had I written "far char*"... but I'm not stupid. I'm just a mean son of <some animal>, right? :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
