From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29863 invoked by alias); 13 Aug 2010 14:47:13 -0000 Received: (qmail 29803 invoked by uid 48); 13 Aug 2010 14:47:00 -0000 Date: Fri, 13 Aug 2010 14:47:00 -0000 Message-ID: <20100813144700.29802.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rogerio at rilhas dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg01109.txt.bz2 ------- Comment #38 from rogerio at rilhas dot com 2010-08-13 14:47 ------- (In reply to comment #36) > > > If you include real segmentation > > > like on 80286, where there's no linear relationship between effective > > > address and segment+offset, subtraction would have been prohibitively > > > expensive to implement anyway. > > What you don't know is that when you subtracted far pointers the compiler > > generated the code to change seg16:ofs16 into abs20. > What in the words "real segmentation like on 286, where there's no linear > relationship between effective address and segment+offset" was unclear to > you to expect that abs20==seg16*16+ofs16? The "prohibitive expensive" > referred to the necessary lookup of the base in the LDT/GDT that would have > been required for every far pointer subtraction. >>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 before adding it to the 16-bit offset (16·segment + offset), therefore producing a 20-bit external (or effective or physical) address from the 32-bit segment:offset pair." So there you go: the relation between effective abs20 address and seg16:ofs16 pair. And it is a linear relation: abs20=K*seg+ofs establishes a linear relation. Check your algebra, and check x86 operation before saying "random stuff". Can you guess how tricky it is for a compiler to get an effective abs20 address out of a seg:ofs pair? abs20=seg*16+ofs (voilá! ...magic!!) What are you dreaming about LDT/GDT? Do you think you need any of that to get an abs20 from a seg16:ofs16 pair? Or maybe you think that a far qualifier would noke the compiler carry seg16 and ofs16 everywhere it went? You just made that stuff up again. Michael Michael Michael: what did I tell you about making stuff up? You don't need to prove to anyone that you are creative, will all know that by now. ... and if Wikipedia is not good enough for you then you can learn about segmentation and how to compute effective addresses in many places. All will teach you what Wikipedia shows. I would teach you if you paid me. No, scratch that: I woudn't, so I'll just leave you alone on this one. > > > And you still wouldn't get around the size limitation of ptrdiff_t that > > > was 16bit. > > What the hell are you talking about????? I personally disassembled code in > > the late 80's to see how the compiler implemented 32-bit arithmetic on a > > 286. It did, and it did it well. You weren't able to go beyond 16 bits in > > the 80's? > Did I say that? Let's see: "size limitation of ptrdiff_t that was 16bit". > Nope. I didn't. The point being that if ptrdiff_t is only 16 bit, then > no matter how fantastically capable the compiler was in emitting 32bit > arithmetic, the result of subtracting to char pointers pointing more than > 64KB (or in fact 32KB) apart would not fit into a ptrdiff_t. The code I used to do was somthing like "long dif=ptr2-ptr1" (long was most often 32-bit back then). Why the hell did you bring "ptrdiff_t" to the conversation? I didn't get it, honestly. But if you brought it was was surely to show me that there was no point in doing 20-bit arithmetic because I would not be able to fit that result anywhere, right? Maybe not, you lost me with the whole "ptrdiff_t" that you decided to bring into the conversation. > > No, not me, I don't want to write nonsense on the web, > Maybe you don't necessarily want to. But ... , well, there we are. Yup. You have still to make one valid claim, and I've been easily shooting you down everytime. And I back it up, isn't that an amazing concept? You should try it sometime. > > I prefer to be clear headed. One never knows when stuff one wrote on the > > net will come back and bite one in the ass!! > I'm not sure you realize just how true that is. But keep going, you're > by far one of the best trolls I've seen in GCC land. Much better than > Pizarro. ... is troll code for "guy who doesn't forgive any false claims and repeatedly shoots down and squashes people who do that repeatedly like a mean son of a " that he is? In that case thanks! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265