By: David Hess (davidwhess.delete@this.gmail.com), March 1, 2013 1:58 pm
Room: Moderated Discussions
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.
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 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.
Parity is also handy for quick and dirty error detection when dealing with EEPROMs and other directly addressable memory.
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.
> 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.
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 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.
Parity is also handy for quick and dirty error detection when dealing with EEPROMs and other directly addressable memory.
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.