Just curious...

[ Post removed by author. ]

Ciper,

Packed BCDs are quite useful when "USAGE IS DISPLAY" (in COBOL-speak). FASM internally uses unpacked BCZ (radix 36 numbers in their ASCII representation) for macro-local symbols' trailer.

These (almost forgotten) aaa/aad/aam/aas/daa/das instructions provide compact, while slow, methods to handle them well. OTOH, das was made popular by famous 5-byte sequence to convert nibble to its hex ASCII representation.

There is fbstp instruction for quick'n'dirty conversion to decimal representation, too.

baldr,

Thank you very much for these clarifications; I believe people and (more seriously) compilers have discarded them too soon; most run-time libraries are certainly slower than these instructions.

Ciper,

Those aren't clarifications of any sort, I'd just pointed out that data usage dictates its representation. For computation-heavy usage, binary can be optimal; if you intend to convert them to textual (or any other) representation often, BCD (or any other easily converted to ASCII/other) representation can give your program sensible boost.

Those instructions are invalid in 64-bit code anyway (except fbstp, naturally ).

baldr,

Retracting the 'clarifications' qualification...

Never found a suitable time to use it until recently when comparing lots of ASCII decimal output, switching to hex diff saved some space and time.

cod3b453,

Comparison is probably not a good example of decimal-oriented data representation usage. Exach matching of arbitary strings can be processed (with good hash function) efficiently; most scripting languages use that technique to compare strings in almost O(1) time.

..

@baldr: My example wasn't about the comparison as much as the space usage - moving from (n+2) ASCII digits to n BCD digits simply meant 2-3 times less data to be stored/loaded from disk; hence faster to compare and less of a dent in my disk quota