Sun, 26 May 2002 19:47:47 +0200 (CEST)
I meant alignment according to cache granularity. This can be really
helpful, when you prefretch one cache line while transferring another one.
You're saving the cost of L1 cache miss (which gets bigger each time CPUs
get faster and faster).
But, I don't think that optimizing is what should be done at this moment.
I think that feature-completeness is more important.
On Sun, 26 May 2002, Sergey Chaban wrote:
> One more note.
> > When you have larger blocks, it really pays off to optimize for
> > things like DWORD/QWORD alignment
> "cpblk assumes that both destaddr and srcaddr are aligned to the natural size of the machine"
> This is from the specs. So in the default case there is no need to worry about this.
> (It is up to code-generator to ensure alignment).
> However prefixes such as "unaligned. 1" are used to override this.
> So additional code for alignment definitely makes sense if these prefixes are used.
> Mono-list maillist - Monofirstname.lastname@example.org