5.31.2011

memcpy

Originally, I wanted to write a flexible lifo and fifo stack system whichs works little the stack pointer in assembler: simply adding and subtracting stuff from the address depending on the pushed/popped datasize. Well, I noticed how useful and minimalizing a memcpy that copies backward instead of forward would be. So I thought it shouldn't be hard to and started to code... Writing memory copy functions is NOT trivial! What do you do if source and destination overlap? Will you want to copy byte-wise or int-wise with a byte-wise rest? Is your copy function so big and complex that you can't inline it? Question you might not think of in the beginning. At first I wanted, like always, a complete comfort package catching every overlap, copying always int-wise to minimize the necessary instructions, beeing ultra-small when inlined and so on. Well, that's a total myth. I'll probably write several function that do things differently. All in all I think it's totally useless to write special functions for forward and backward copying cause it's simply not necessary. Whatever you do try to duplicate this way, you'll always have a start and an end or a size. and if you don't have one these three, you can calculate and don't have to implement a shitload of funcs just to have them in case you'll need it one time... That said, I stumbled into something I can again not leave that simply. But it's interesting how close this situation comes to copy functions in general, which I always left out when writing array operations in C++. On a level where you don't need to worry about overwriting stupid class IDs, it's way easier to write copy functions. Did I say how I hate C++' hidden RTTI system? It plainly sucks. I never really used it and I doubt I'll ever really will... However - back to memcpy - it's surprising how limited possibilities for copying large blocks are and how more limiting the possible combinations appear. Theoretically, you can't just copy int-wise while not requiring non-overlapping memory area. The reason for that is that memory is addressed byte-wise: copy one int into it's own body and it's only possible to operate swap-less if one takes the minimal representable unit for the used address system and copy it from end to start instead of start the end. You'll never know HOW the exact copying is done inside the processor. I think there is potential room for processor improvement if you ask me.. However, this means that I'm only able to int-copy non-overlapping areas - not a too bad decision cause I only need to implement two rather simply functions... I'd love to freely combine alghorithmic properties during compile-time. This way I could use smaller subsets of copy functions and combine them on demand. I know that GCC is free to reject any inlining whereever it occurs, mostly because it increases code size or register use (atleast this was my experience). So whatever construct you create, there's the possibility that it won't it's way situation-optimized. In theory, a clever idea to compare inlining and function calls depending on that. But in practice there are so many lowlevel functions that would benefit from situation-dependent optimization. It's barely possible to create a complex function with many optimization for many cases and situations, if it's still called cause it's too big instead of inlined. There's almost ALWAYS an " almost perfect" way for every situation in every code that doesn't depend on runtime data. I don't want to judge about the developers of GCC or C cause they didn't create it to work as a sole optimizer but rather many platforms supporting compiler for many standardized languages. I'd be a fool to judge over this immense amount or good work they did and better create my own compiler that compiles to C code instead of "blaming" it. Did you know that C was written to give an abstraction of assembler code? That said, it's the only actually portable way to to export your programs. I like C cause it's exactly that: following it's spirit in almost any way. I have my complains, yes, but these are a matter of facts and design history - not false philosophies.

No comments: