From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a3fe2aac201210c0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,CP1252 Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 27 Jul 2004 18:24:40 -0500 Date: Tue, 27 Jul 2004 19:24:40 -0400 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: reading a text file into a string References: <40f6bf21@dnews.tpgi.com.au> <40fb8c00$1_1@baen1673807.greenlnk.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 24.147.90.114 X-Trace: sv3-96c2tUSPPy+/Eje8no017uqz6eo7vyuR01HMyi4i71q5jNSGALa2zN/PhrDsIhNFEpznUIMlhwSh+fH!rfBEpSaAmvZ9t1tJJkbW1r6HavAT0UcURGI4oylXYDFK7x9VSkGaawxi+CuTxQ== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.13 Xref: g2news1.google.com comp.lang.ada:2427 Date: 2004-07-27T19:24:40-04:00 List-Id: Nick Roberts wrote: > Let me first assure you that neither this time nor at any time in > the past have I intended to imply that were lying or to make any > personal slight against you. I didn't read Nick's words as indicating anything other than "things have changed in this area." But I wasn't the target. Personally, though, I think this is VERY important discussion, and I hope we can keep to the issues. I was surprised to see GNAT saying it would only do doubleword (4-byte) alignment, because 8-byte alignment has gone into and out of programming guides with each new hardware generation. > According to the manual, the 16-byte alignments are to do with > the way the instruction pre-decoding unit loads code, which is > 16-bytes (a cache 'half-line') at a time. But is the manual > correct? Don't know about the Intel IA-32 manual, but the AMD "Software Optimization Guide for AMD Athlon� 64 and AMD Opteron� Processors" http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF indicates that the latest AMD processors now use a 32-byte code decoding window. The Intel Itanium2 also loads two instruction bundles (32-bytes) at a time. > Well, I don't think so. The usual thing is to do is to save > ESP in the EBP register at stack frame creation, and restore it > from EBP just prior to return. There is, I grant, a need for a > little care, in that one would (I guess) need to do the stack > alignment I suggested before pushing anything onto the stack > that you might want to pop off it afterwards. Otherwise, I > think the 'and' instruction is the only extra thing required. > > I vaguely remember that I have actually used this technique, > but a long time ago. The AMD manual referenced above gives the example code to do this on page 128 (in Section 5.13): prologue: push ebp mov ebp, esp sub esp, SIZE_OF_LOCALS ; Size of local variables and esp, �8 ... ; Push registers that need to be preserved. epilogue: ; Pop register that needed to be preserved. leave ret This example is explictly showing a quadword alignment (8-bytes). Compilers definitely should do this for code with quadword (usually Long_Float in Ada) values. Of course, to do cache boundary alignment as well, you replace -8 with -64 (or -256 on Intel Pentium4 CPUs). The waste of space on the stack is minor, or should be if it is only done when the programmer explicitly requests it. Again, in the code where I need to do this, the _execution_time_ cost should be zero, since the stack frame needs to be quad-word aligned for other reasons. > Also, I think possibly we're arguing at crossed purposes on > this point. I'm only arging that linkers and execution > environments /should/ support cache-line alignments. I accept > that many do not, in practice, and I accept that a compiler > targetting such a linker or environment cannot be expected > to so so either. I think this is how Robert's original comment > can be construed, also. Right. But as discussed above, aligning stack frames is something any compiler can do, whether on x86 or elsewhere. Also the heap management software can/should allow for an allocation request to specify alignment. MicroQuill sells a very nice library to replace malloc and free with better performing versions, if the 'native' OS functions are not aware of cache line and disk page sizes. (Heap objects should never be allocated across vitrual memory page boundaries unless they are too big to fit in a single page. But some versions of malloc ignore page boundaries when allocating objects in the heap.) -- Robert I. Eachus "The flames kindled on the Fourth of July, 1776, have spread over too much of the globe to be extinguished by the feeble engines of despotism; on the contrary, they will consume these engines and all who work them." -- Thomas Jefferson, 1821