Florian Klaempfl wrote: > Tomas Hajny wrote: >> On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote: >> >>>>> First parameter is in eax, second in edx (third one is ecx) >>> TH> Yes, of course, sorry for confusion... :-( Anyway, loading of the >>> first >>> TH> parameter can be still skipped (and the stack frame is probably not >>> useful >>> TH> in this case either). So you'd get: >>> TH> function brol(b: byte; c: byte): byte; assembler; nostackframe; >>> TH> asm >>> TH> movb %dl,%cl >>> TH> rolb %cl,%al >>> TH> end ['cl']; >>> TH> Tomas >>> >>> 1. So, is there any problem with including this functions and bit >>> checks >>> (bt./bs. in intel assembler: writing (a and (1 shl i)) isn't great >>> too)? >> >> I guess there is no problem in including it. The >> only questions from my point of view are: >> >> 1) Are they useful in general, so that it would >> make sense to include them either in FPC itself >> (as opposed to some standalone unit)? > > - they must be available for all cpu platforms, so we need at least a > generic implementation
Generic implementation in Pascal has already been provided in this thread as well, so this isn't an issue. > - for an efficient implementation, this needs a compiler patch so the > compiler can really efficiently inline Would this apply for the operator case too? Isn't it then similar to shl/shr (which "just work" now as well - even without special inlining support)? Of course, this would only make sense if we're convinced about the general usefulness of such operators. Tomas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
