On 02/25/2014 08:43 AM, Vivek Goyal wrote: > > W.r.t sharing the code with arch/x86/boot/, I am not sure how to do it. > Pretty much we have been doing #includes (a bit sad, I know)... there are already a lot of them between arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode. In that sense collecting these "limited environments" together and have these kinds of stuff together in one place seems like a good idea. Does purgatory move large amounts of data around? If so, we probably *do* want to use rep movsl, but otherwise you're definitely right, using C code makes more sense. > I see two implementations of memcpy() under arch/x86/boot. > > One is in copy.S. This is assembly code and looks like is supposed to > run in 16bit mode. (code16). > > Other one is in compressed/misc.c and there are two definitions, one > for 32bit and one fore 64bit. They are basically the 16-, 32-, and 64-bit variants of the same code. > I am not sure why there is a need to write memcpy() in assembly when > C will do just fine for my case. I don't have to write two versions of > memcpy() and use it both for 32bit and 64bit. The point would be to use the ones we already have. > So I can just make all the purgatory code share same version of memcpy(), > memcmp() and memset(), is that fine. I have taken implementations of > these functions from lib/string.c It depends on if you care about performance. For memcpy() and memset() in particular, the CPU has internally optimized versions of these that beats C at least on any newer silicon. -hpa
