Just like we have binary multipler circuit in cisc computer so do we have binary divider circuit in cisc computer? Or it is just like we use algothrims instead of having a real divider circuit? (Just like risc don't have multiplier circuit so it use adders circuit instead of multiplier circuit).
You're confusing things:
CISC or RISC says something about the instruction set.
Nothing about how instructions are implemented. You can have a RISC with barrel shifters, hardware single-clock floating point multipliers and dividers, and you can have a CISC system that implements rotational shift under the hood in multiple single-bit-shifts with a carry register, and can't do any floating point in hardware, but does all floating point in slow fixed-point microcode.
CISC and RISC are unrelated to the question of how (and how fast) things work!
Generally, hardware dividers are rare:
- because division is surprisingly seldom useful and
- because a hardware divider is humongous to implement. I'll invite you to look at the "small" images in this answer of mine about why division is slower than multiplication in hardware.
RISC versus CISC has nothing to do with which raw machine capabilities are included, like whether there is a multiplier, divider, barrel shifter, etc. A hardware divider is a particulary heavyweight computational block to implement, so fewer processors have them than the more simple multipliers and even simpler adders.
The distinction is more about addressing modes, and what parts of the processor data can be moved between during individual instructions. This distinction was always somewhat blurry, and of course with marketing involved, it got even blurrier. For a while, everything was labeled RISC because the marketers thought it sounded more cool and modern. Neither is true, but some of that has left the impression that RISC is somehow more advanced. That's not true either.
In my opinion, the drive towards RISC or CISC had more to do with the relative speed of main memory compared to the combinatorial logic to implement instruction decoding and data manipulation. Consider that main memory and logic gates are implemented with different technologies. It should be no surprise that the relative speed of each therefore changes as different technologies advance and new ones emerge.
Back when main memory was core and logic was TTL chips, main memory was relatively slower than it generally is today. It therefore made sense to highly encode instructions, then perform lots of logic operations as a result of each, since you'd be waiting around a while for the next instruction anyway. When main memory is relatively faster, then you can fetch instructions more often, or put another way, you have fewer gate delays to do anything with a instruction before you need to process the next one without stalling the pipeline.
Back in the 1980s when core memory as main memory was being phased out in favor of dynamic RAMs, various new machine architectures emerged based on the "RISC" philosophy. This was over-hyped to make RISC sound like some breakthrough, as apposed to the logical evolution of faster main memory relative to gates. The relative speeds of memory and logic continue to waffle back and forth, so there are machines with tradeoffs all along the CISC/RISC spectrum.
Actually, parts of common computers from the 1960s and 1970s were way off at the RISC end of the spectrum, because microcode is in some ways the ultimate RISC architecture. CISC machines of the time had so many logic delays available to them per main memory instruction fetch that the complicated instructions were actually performed by a fast internal RISC machine running from a small (and much more expensive) gate-like memory. These micro-instructions were typically very wide, with individual bits directly controlling buffer enables controlling the source of data onto internal busses, the ALU functions, and the like.
As a result of all this, CISC instruction sets generally have lots of possible addressing modes for the sources and destinations of operands. RISC instruction sets are simpler ("reduced") by generally performing operations only between a limited set of special hardware registers. The source values have to be moved into the registers from memory and the results written back to memory (when these are required) by separate instructions from those performing the computations.
However, back to your question, none of this says whether a machine has native divide hardware, or whether divides must be done in software.