David Hess (davidwhess.delete@this.gmail.com) on March 1, 2013 1:58 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 27, 2013 11:22 am wrote:
> > David Hess (davidwhess.delete@this.gmail.com) on February 26, 2013 11:01 pm wrote:
> > >
> > > I still regularly use auxiliary carry and parity if available. The only reason I no longer
> > > use them with x86 is that x86 no longer exists in the embedded space I work in.
> >
> > What kind of odd code do you write where auxiliary carry makes sense? Even if you do
> > bcd, I can't imagine that you can't do it better than that using vectors (or even just
> > 32/64 bits at a time using perfectly normal arithmetic and some bit tricks).
> >
> > Is there some other nefarious use of the AC flag than bcd?
>
> On x86 there is or was. You can use it to aid in binary to ASCII conversion. On processors
> where the DAA instructions actually loaded its immediate value instead of reading it
> from the microcode, you could use it to support other nefarious conversions.
>

You can be interested of what binary-to-bcd speed is possible on modern x86. With no stinkin DAA, of course.

http://groups.google.com/group/comp.arch/msg/32b0c0a868f208a4


Terje Mathison says that even on old x86 CPUs DAA-based conversion was much slower than smart (not naive) DIV/MUL based conversion. And Terje tends to know what he is talking about.


> BCD using vectors or 32/64 bit registers would be nice but as far as I know, only IBM goes for that
> sort of thing now to support financial applications. I am not sure how that would work on ARM.

I think, few ideas from x86 code presented above would work on Neon.
And for smaller ARM cores, those without Neon, like Cortex-M0/M3/M4, you can try original Terje's variant. According to my understanding, it is written in portable 'C".

> guess it takes a couple of XOR operations and an immediate AND to recover the carry bits which is not
> so bad if you are working with 8 digits at a time except there is a recent patent covering it?
>
> I still live in 8 and 16 bit land. The more I play with ARM the more annoyed
> I get with it but not only because of the instruction set. I have not done real
> application programming since Watcom C++ although I am tempted sometimes.
>
> > Parity calculations I can kind of see still being used in legacy communication protocols, but ..
>
> Oddly enough modern UARTs and USARTs that support parity often do not support calculating
> it and just pass it along as an 8th or 9th bit relying on the CPU to handle it.
>

Sorta makes sense, taking into account how easy it is to calculate in CPU.
Anyway, I hate COMM protocols that utilize parity. IMHO, that's pretty stupid [mis]use of the bandwidth.

> Parity is also handy for quick and dirty error detection when
> dealing with EEPROMs and other directly addressable memory.

Very dirty and, if you have binary data to store, not so quick.
Come on, leave the stone age already. CRC is easy. And, unlike parity, it works.

>
> I still design in asynchronous serial because USB is both more complicated and often under performing
> in specific cases. The lack of and difficulty in adding galvanic isolation to USB can be a big problem.
> USB to asynchronous serial conversion is notoriously unreliable although it should not be.
>