Re: reading a text file into a string

["Robert I. Eachus" <rieachus@comcast.net>]

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