How to enable the DIV instruction in ASM output of C compiler

Question

I am using vbcc compiler to translate my C code into Motorola 68000 ASM.

For whatever reason, every time I use the division (just integer, not floats) in code, the compiler only inserts the following stub into the ASM output (that I get generated upon every recompile):

public  __ldivs
jsr __ldivs

I explicitly searched for all variations of DIVS/DIVU, but every single time, there is just that stub above. The code itself works (I debugged it on target device), so the final code does have the DIV instruction, just not the intermediate output.

Since this is the most expensive instruction and it's in an inner loop, I really gotta experiment with tweaking the code to get the max performance of it.

However, I can't do it if I don't see the resulting ASM code. Any ideas how to enable it ? The compiler manual does not specify anything like that, so there must clearly must be some other - probably common - higher principle in play ?

Answer 1

From the vbcc compiler system manual by Volker Barthelmann:

4.1 Additional options

This backend provides the following additional options:

• -cpu=n Generate code for cpu n (eg -cpu=68020), default: 68000.

...

4.5 CPUs

The values of -cpu=n have those e?ffects:
...
n>=68020

• 32bit multiplication/division/modulo is done with the mul?.l, div?.l and div?ll instructions.

The original 68000 CPU didn't have support for 32-bit divides, only 16-bit division, so by default vbcc doesn't generate 32-bit divide instructions.

Answer 2

Basically your question doesn't even belong here. You're asking about the workings of your compiler not the 68K cpu family.

Since this is the most expensive instruction and it's in an inner loop, I really gotta experiment with tweaking the code to get the max performance of it.

Then you are already fighting windmills. Chosing an obscure C compiler while at the same time desiring top performance are conflicting goals.

If you really need MC68000 code compatibility, the choice of C is questionable. Since the 68000 has zero cache, store/load orgies that simple C compilers tend to produce en masse, have a huge performance impact. It lessens considerably for the higher members and may become invisible on the superscalar pipelined ones (erm, one; the 68060).

Switch to 68020 code model if target platform permits, and switch compiler if you're not satisfied with your current one.