On 07.01.2008 17:40, ron minnich wrote:
On Jan 7, 2008 1:40 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Well, we can't use CPU cache, but we can abuse CAR memory as cache (ironic, isn't it? I'll call it CARAC.) for the first few (or all) members in the LAR. The cost estimate would be 8-32 bytes per LAR member, depending on your personal opinion on memory usage vs. speed tradeoff.
I would rather not walk all of empty space ever at any time. I like the end marker best. We can do it many ways, I leave it to you folks, but let's try to not look at 2^16-2^4 entries in search of something :-)
My cache idea is completely orthogonal to the "walk empty space or not" issue. lib/lar.c would set up a cache of all LAR entries it encountered so far, making subsequent lookups almost pure cache memory operations.
I still find the explicit termination marker very interesting, esp. since it is flash rewrite friendly.
Pointers, let's not do them, instead, if we want such a thing, let's do indices. If we start doing pointers, LAR is no longer location-independent.
Agreed, but even for indices, the reasoning from my other mail applies. It is almost impossible to do without erasing unaffected flash sectors. There is one way to use indices sensibly without erasing the block containing the previous LAR header, but it will require an erase of the placeholder member. No-erase adding of LAR members with the requirement of no-collateral-erase-ever is not possible unless you allow me to add a dozen lines of code and uglify the central LAR parsing loop in a way that nobody ever is going to be able to verify the code. And I need 8 additional bytes in the header. There will be lots of special cases and people will have a strong urge to start v4 ;-)
Regards, Carl-Daniel