What's the stance of the D language regarding the "aliasing" problem? The last C99 has added a keyword (restrict) to manage this problem (and in GCC you can find some nonstandard extensions for C++ too).
See also: http://www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict_keyw.html I think this keyword potentially allows C compilers to produce executables as efficient as Fortran ones. ------------------ D now allocated "large" memory blocks aligned to 16 bytes, so something like this (that can be seen in some C++ code) isn't necessary: __attribute__ ((aligned(16))); But this page also says that the AMD Barcelona Quad-Core: http://en.wikipedia.org/wiki/SSE4#cite_note-2 >Support was added for SSE4a for unaligned SSE load-operation instructions >(which formerly required 16-byte alignment).< So maybe aligning a lot will not be so necessary in future. On the other hand the next pack of instructions, named AVE, will use 256 first, and then 512 and 1024-bit vector FPs: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions A PDF reference is already available: http://softwarecommunity.intel.com/isn/downloads/intelavx/Intel-AVX-Programming-Reference-31943302.pdf I haven't read the reference, so I don't know if they will require 32-64-128 byte alignment :-) Such instructions don't look much complex, but they make the already really messy X86 asm even more chaotic :-) Someday they will have to throw away lot of old stuff, and just simulate it :-) It's not a problem for the transistor count, because the amount of transistors added by each of such extension packages is huge compared for example to a 80286 that is the core of the intel CPUs :-) The problem is for compilers and the vanishing asm programmers :-) Bye, bearophile
