On 30/01/13 14:59, camper wrote: > Am 30.01.2013 14:41, schrieb Luca Barbato: >> That simple size is a pointer difference. It can be a negative a size >> can't be negative. So it is clarifying its usage after all. >> > I'd like to point out that this interfers with x32 - porting. Since > there ptrdiff_t is still only 32 bits, while effective addresses are > best done using 64 bits (requiring an address size override otherwise = > greater > code size). Those movxsd would have to be reintroduced then. Since > similar concerns have been expressed with x264 I'm currently working on a > solution > to have the assembler figure out those things from an ordinary C-style > declaration > of the function.
I see... > e.g. replace > cglobal foo, 2, 4 which might be a void foo(int* src, intptr_t stride) > with > cglobalx "void foo(int* srcq, intptr_t strideq)", 4 > and let the assembler figure out if mosxd&co need to be inserted. Oh, sounds interesting. > The parser already works, so I expect to have something by the weekend - > assuming there is interest. As a general rule we prefer to be compatible with x264 in those parts since we share code with them. > In general I agree that ptrdiff_t makes more sense. Overall it is just a pragmatic matter of usefulness, if there are more cons than pros in using ptrdiff instead of normal int, then we should reconsider this move. Thank you for you input and your work =) lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
