vbcc code generation and dbf

[Asman]

Does vbcc can generate a loop with dbf ?

I'm trying to make such loop in C but without success. Without asm insertion of course.

Any ideas ?

[Samurai_Crow]

Originally Posted by Asman

Does vbcc can generate a loop with dbf ?

I'm trying to make such loop in C but without success. Without asm insertion of course.

Any ideas ?

Since a byte branch offset with a subtract is smaller and faster than DBF, I wouldn't imagine it would generate a DBF for anything smaller than 128 bytes forward or 130 bytes back as an offset. Even then, I don't recall seeing a DBF optimization mentioned in the manual. The only real frequent time to see an improvement in speed with DBcc is if the condition code is not false.

[Asman]

Let consider two very small examples: first take 142c second one 108c. Both doing same thing, mean nothing

        moveq   #10,d0
loop1
        subq.b  #1,d0
        bne     loop1
;total 142c

       moveq   #10-1,d0
loop2   dbf     d0,loop2
;total 108c

So for me its real gain even for small loops. For 10000 elements then you have 140006c and 100012c. Of course I mean about MC68000.

[matthey]

Originally Posted by Asman

Does vbcc can generate a loop with dbf ?

I doubt the vbcc 68k backend will currently generate a dbf. Some of the C static library code and assembler inlines will use it though. If i recall correctly, the startup code and 68000 inlined memcpy() will use it.

Originally Posted by Samurai_Crow

Since a byte branch offset with a subtract is smaller and faster than DBF, I wouldn't imagine it would generate a DBF for anything smaller than 128 bytes forward or 130 bytes back as an offset. Even then, I don't recall seeing a DBF optimization mentioned in the manual. The only real frequent time to see an improvement in speed with DBcc is if the condition code is not false.

A SUBQ+Bcc.B is 4 bytes and DBcc is also 4 bytes so they are the same size. I believe DBF is considerably faster on the 68000 and 68020 but there is no speed advantage to DBF on the 68040 and 68060.

SUBQ+Bcc.B is used by the compiler because it is more flexible. DBcc only works with a 16 bit counter and 16 bit displacement and often needs to be branched into at the start. It would be possible to make an optimization that uses DBF when the counter is 16 bit or less and static but most C code today is using 32 bit and 64 bit counters as they avoid the chances of the counter variable overflowing.

[Leffmann]

There is code in the M68K backend to use DBF for loop constructs actually, but the conditions are never met, probably due to a bug somewhere, and it always ends up emitting the SUBQ+Bcc sequence instead.

[Asman]

Originally Posted by Leffmann

There is code in the M68K backend to use DBF for loop constructs actually, but the conditions are never met, probably due to a bug somewhere, and it always ends up emitting the SUBQ+Bcc sequence instead.

You mean about this code from vbcc/machines/m68k/machine.c ?

    if(loops>0){
      if(!cf&&loops<=32767&&loops>=-32768){
	emit(f,"\tdbra\t%s,%s%d\n",mregnames[dreg],labprefix,label);
      }else{
	emit(f,"\tsubq.l\t#1,%s\n\tbge\t%s%d\n",mregnames[dreg],labprefix,label);
      }
    }

[Leffmann]

Yeah I assumed that's what it was, but it seems to be part of the code for copying structs around, so matthey is right that VBCC doesn't use DBF for loops.

[matthey]

Originally Posted by Leffmann

Yeah I assumed that's what it was, but it seems to be part of the code for copying structs around, so matthey is right that VBCC doesn't use DBF for loops.

Copying structures and memory use loops, at least when the copy can't be unrolled. Vbcc has sophisticated loop unrolling settings so the most common loop generating code is likely more complex than the code above. The code above almost looks too simple even for a structure copy.

[kamelito]

@PHX
Not sure you read this but in case...What is the status of Vbcc regarding UB?
http://www.complang.tuwien.ac.at/kps...mission_29.pdf

Kamelito

[matthey]

Originally Posted by kamelito

@PHX
Not sure you read this but in case...What is the status of Vbcc regarding UB?
http://www.complang.tuwien.ac.at/kps...mission_29.pdf

Interesting article although nothing surprised me. Compiler developer's selling hype and C not being portable? Yawn. What's new? Undefined behavior? What can compilers do besides shoot an error, handle the code consistently between platforms and versions and not optimize the problem? Obviously, some of the top compilers can't even handle that. Vbcc is standards strict and more likely to give errors for UB cases unlike the default GCC slop but most of the C world has learned and expects GCC slop so it has become a pseudo standard which programmers use. It would help if the C standards would define more of the common UB cases but there will always be some problems. GCC adds their own GCCisms which also have UB problems. Programmers would like more GCC compatibility but Volker has tried to keep vbcc standards clean, non-bloated and able to be programmed at a low level for embedded systems. His efforts are under appreciated by those wanting perfect GCC compatibility and the best optimizations in the world. It is too bad that compilers like vbcc are not supported more as they could have a positive influence on the direction of C. Instead, we have one huge bloated GCC C standard and its optimization target x86_64 to rule the world.

[phx]

I agree with everything matthey has said. There is nothing to add.

[kamelito]

Is there any other C compiler that is doing it the right way like VBcc?
Any plan to support X64? (or 80x86 (386 and above) mean also x64...)
is VBcc for plateform other than Amiga is distributed as source code only?
Kamelito

[phx]

Originally Posted by kamelito

Is there any other C compiler that is doing it the right way like VBcc?

I hope so.

BTW, Visual C++ is certainly not one of them. Last time I checked it didn't even implement the most basic C99 functionality. And Microsoft's attitude is that it doesn't matter, because everybody will use C++ anyway ...

Any plan to support X64? (or 80x86 (386 and above) mean also x64...)

You have to ask Volker about that. An 80x86 code generator exists since nearly the beginning, but it never became mature - also because nobody used it. AROS is not very vbcc-friendly, so there was not much reason for it.

is VBcc for plateform other than Amiga is distributed as source code only?

Yes. To be precise, my contract with Volker allows me to make releases for Amiga and Atari only.

BTW, vbcc 0.9e is currently in the final testing phase for the release.

[kamelito]

Maybe GCC with -Wall -Wextra -ansi -pedantic
I knew about MS, but is C99/C11 features any good, I'm sure some of them should be avoided.

Kamelito

[matthey]

Originally Posted by phx

BTW, vbcc 0.9e is currently in the final testing phase for the release.

Awesome. What is new? Mostly bug fixes? New functionality?

Originally Posted by kamelito

Maybe GCC with -Wall -Wextra -ansi -pedantic
I knew about MS, but is C99/C11 features any good, I'm sure some of them should be avoided.

IMO, C99 is overall a good standard for C. The new standard datatypes (64 bit integers, fixed length integers, boolean, etc.) make writing portable and optimized code easier. Allowing BCPL/C++ style comments and allowing variable declarations in the code are convenient additions. Floating point functions were standardized and there is a huge selection of functions. C99 is more strict and defined in some ways which helps with optimizations and UB (for example restrict and inline behavior). The biggest problem with C99 is that it went too far into unnecessary areas where optional C add-ons would have been better (complex number support, variable length character support, etc.). The amount of work and code needed to support C99 made full support of the C99 standard rare (vbcc does not fully support C99). C11 made several add-ons optional and added some important but mostly specialized new features like multi-threading support.

GCC is by default in slop mode (-std=GNU11). This includes POSIX support and GCCisms which can interfere with the standard (this is why phx has a different set of includes for his PosixLib). Some older GCC behavior is retained for compatibility with older GCC versions. Standards and errors are relaxed in general. GCC can be put in strict C99 (-std=c99) or C11 (-std=c11) mode. GCC with -std=c99 -pedantic switches would probably be closer to vbcc with -c99. I expect many existing GCC programs would no longer compile though.

[Samurai_Crow]

I consider C11 to be interesting if for no other reason than the preprocessor supports "generic" style functionality and allows some unpopular features of C99 to be optional.

-edit-
This is a subject for another thread.