On Thu, 10 Sep 2009 11:19:53 +1000 Simon Horman <ho...@verge.net.au> said:
> On Thu, Sep 10, 2009 at 10:53:17AM +1000, Carsten Haitzler wrote: > > On Tue, 8 Sep 2009 20:52:39 -0300 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > > you've already put my word in on this. i go the accounting way. 1. it is > > consistent with eina_list. 2. can be extended beyond last and include count > > and many other things. 3. doesn't change inlist struct size to be bigger > > (tho we dont win on it being smaller). 4. doesnt play evil games. (using > > low-order bits in pointers is wrong imho. i've sen this game played before > > (using high order bits) and then it com crashing down on peoples heads when > > suddenly those used bits become relevant. using those bits will also > > require instruction overhead of masking them out always before use. so you > > lose on the code simplicity and speed side, just to save 4 bytes (or 8 on > > 64bit) per inlist instance. it's not worth it. it is possible also in > > future allocations no longer are limited to word boundaries and allocs do > > use those bits, thus removing them from our use and requiring another > > solution. > > Does anyone know if the issues related to using the lower bits of pointers > architecture-specific, libc-specific or both? > > I was pondering this recently in relation to a different project. I know > that they use this technique in the Linux kernel. But obviously they have > quite a lot of control over what their memory addresses look like in terms > of alignment and thus unused bits. well a combo of both. 1. libc "guarantees" that allocations will be on the largest arch-specific alignment boundary. ie the largest "primitive" the processor uses (most often 32bits, or 64bits). this is so any structure you allocate - if it uses the largest primitive type, will have its first member always aligned, meaning any compiler alignment for struct members will work too. 2. most arches will actually raise processor exceptions for access of non-aligned data. x86 does not but there is a small performance penalty to accessing unaligned data. so align your data if u ant it faster, but there isnt a big pain level for not doing so. for arm (for example) you literally get a processor exception (sigbus) if you access non-aligned mmory (eg read 32bit words at a non 32bit boundary). some arm kernels are compiled to do a fixup, access the mem anyway in a non-exception raising way in the kernel when the exception is raised from a "bad" userspace app, then flip back to userspace and log the pain. your accesses work - but are slow-as-windows. other kernels simply issue a sigbus that nicely terminates your process. it is in theory possible to have an architecture where accesses on byte boundaries is always possible and has no penalty. in theory here allocations would never need to be aligned (but may be for simplicity sake). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
