This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Enabling -O2 option of GCC]


Andrew,
I'm obviously going to keep the old scheme - I want to maintain
compatibility with the main eCos source tree - so if at all possible any
changes I make I'll try to limit to my own low level drivers.

I'm lucky my processor can handle un-aligned data accesses so do you
think the network stack will be happy with a 16 bit rather than 32 bit
aligned IP header?

The idea of dma'ing the Ethernet header into one mbuf and the remainder
of the frame into another is neat but difficult in practice to organise
since in my case the dma'ing is handled automatically by the Ethernet
controller and I think it would be hard to guarantee that the Ethernet
header would be dma'd into the small mbuf rather than the large mbuf -
so I've discounted this idea.

I think you're very sensible looking at a more efficient memcpy - it's
something I'm also doing. In my processor where non-aligned accesses are
supported if both source and destination are not 32 bit aligned rather
than just doing byte copies it's worth aligning either the source or
destination on a 32 bit boundary and then performing 32 bit copies. I'm
even considering implementing it in assembler to get the very last mips
out of the processor. 

An efficient memcpy is something that is processor specific (sometimes
even target specific depending on memory widths etc) - so it's most
sensible for eCos infra to supply a generic memcpy that's adequate and
let the compiler/processor/target override it with its own if necessary.

	Dave Webster
 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]