TS says 32 bit binary. That's just 10 decimal digits, so I think ten 74185.

It's not nearly that simple. You have to process intermediate results in a layered approach and the number of gates needed grows faster than linear (quadratic?) with the number of bits.

Looking at the data sheet a 6-bit converter requires 1 gate while an 8-bit converter requires 3 gates and a 9-bit requires 4. Not bad. But a 12-bit requires 8 and a 16-bit requires 16. It appears that, very roughly, the number of gates is doubling for each additional three or 4 bits, but I don't think that trend continues. I don't see a distinct pattern that I can easily quantify, but it appears that you add another row for each two additional bits and each row is, on average, perhaps half a gate longer than the row before it. So by the time you get to 32 bits you might adding 8 rows on top of the 16-bit and those additional rows might average something like five gates, so that would be an additional forty gates on top of the sixteen, making it between fifty and sixty gates.

 

I hope TS knows that calculators don't do 32-bit arithmetic.
They do 4-bit BCD arithmetic.

 

TS says 32 bit binary. That's just 10 decimal digits, so I think ten 74185.

Have you ever actually tried to do something like this? I designed a binary to BCD converter and cascaded it to 17 bits. My converter was 4 bits, and it took 42 of them.

This is a 16 bit implementation from the datasheet: