Re: memcpy_toio on i386 using byte writes even when n%2==0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, 30 May 2006, Chris Lesiak wrote:

> On Fri, 2006-05-26 at 17:46 -0600, Robert Hancock wrote:
>> It does seem a little bit less efficient, but I don't know think it's
>> necessarily a bug. There's no guarantee of what size writes will be used
>> with the memcpy_to/fromio functions.
> I shouldn't have made that assumption in the first place, but I suspect
> that I am not the only one to have done so.  Probably other hardware
> also gets caught not supporting byte enables.
> --
> Chris Lesiak
> [email protected]

If byte writes are used, they should always be last for any
odd byte. I think you found a bug in spite of the fact that
whoever made the revision to memcpy probably thinks they
did something 'cool'. This is an example of cute code causing
problems. The classic example of a proper memcpy() that uses
the ix86 built-in macros runs like this:

 		pushl	%esi		# Save precious registers
 		pushl	%edi
 		movl	COUNT(%esp),%ecx
 		movl	SOURCE(%esp),%esi
 		movl	DEST(%esp),%edi
 		shrl	$1,%ecx		# Make WORDS, possibly set carry
 		rep	movsw		# Copy the words
 		adcl	%ecx,%ecx	# Any spare byte
 		rep	movsb		# Copy any spare byte
 		popl	%edi		# Restore precious registers
 		popl	%esi

Note that there isn't any code for moving dwords because the
chances of gaining anything are slim (alignment may hurt).
This kind of code results in the principle of least surprise.
More sophisticated code usually takes longer to execute although
it often looks 'cute' as the designer attempts to create some
sort of alignment, at least for one of the elements. The jumps
in such code usually negate the advantages of any such cuteness.

I've found that it's often necessary to create private functions
to get around the disadvantages of some of the recent cute code.
You can always make a MemcpyTo_io().... It won't ever change
unless you change it! That way, your modules will compile and
work forever, regardless of any "improvements" made in the
source-code tree.

Dick Johnson
Penguin : Linux version on an i686 machine (5592.73 BogoMips).
New book:

The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux