DOS ain't dead

TCC 0.9.26 (Win32) (Announce)

posted by Rugxulo , Usono, 30.06.2013, 14:46

> BTW TCC boasts how fast it can compile over GCC but is there some
> comparison of speed of resulting code? What advanced instructions it can
> use? MMX/SSEx/AVXx?

I don't know. Even if I was familiar with older versions, it has probably changed in the meantime. For instance, 64-bit support probably prefers SSE, but the 32-bit one is most likely just x87 only. MMX is deprecated by almost everyone, and AVX is too new (and relatively rare, you need a 2011-era machine or newer.)

As far as compiled code speed, it's not as good as GCC. TinyC is (IIRC) a one-pass, all-in-one compiler + assembler + linker tool. It does some basic optimizations, but there was some lack of register use, perhaps it didn't schedule or didn't reload or maybe didn't even use some registers ever. Probably the only way to know for sure is compile to .o (ELF? apparently, yes, even for Win32 target) and disassemble, e.g. "objdump -M intel -d" or "objconv -fnasm" or whatever. For a simple example, I don't see any use of EBX, ESI, EDI at all. (Though I do see x87 and SSE, respectively, for float stuff.)

I don't know the details, but I'll quote the docs for you.

http://www.bellard.org/tcc/tcc-doc.html

> The TCC code generator directly generates linked binary code in one pass.
>
> The TCC code generator is register based. Optimization is only done at the
> expression level. No intermediate representation of expression is kept
> except the current values stored in the value stack.
>
> On x86, three temporary registers are used. When more registers are
> needed, one register is spilled into a new temporary variable on the stack.
>
> Constant propagation is done for all operations. Multiplications and
> divisions are optimized to shifts when appropriate. Comparison operators
> are optimized by maintaining a special cache for the processor flags.
> &&, || and ! are optimized by maintaining a special 'jump target' value.
> No other jump optimization is currently performed because it would
> require to store the code in a more abstract fashion.

Complete thread:

• Orange C 5.03 - Rugxulo, 23.05.2013, 23:07 (Announce)
  • Tested Orange C 5.03 - DOS386, 25.05.2013, 08:47
    • Tested Orange C 5.03 - Rugxulo, 25.05.2013, 22:03
      • Orange C 5.0.5 + CC386 4.11 - DOS386, 05.06.2013, 03:59
        • Orange C 5.0.5 + CC386 4.11 - Rugxulo, 06.06.2013, 01:28
          • Orange C 5.0.6 + CC386 4.12 | 2013-Jun-05 - DOS386, 07.06.2013, 09:55
            • Orange C 5.0.6 + CC386 4.12 | 2013-Jun-05 - Rugxulo, 08.06.2013, 01:47
              • Orange C 5.0.6 + CC386 4.12 | 2013-Jun-05 - Rugxulo, 13.06.2013, 14:10
                • Orange C 5.0.7 + CC386 4.14 - DOS386, 18.06.2013, 10:18
                  • N/A - DOS386, 24.06.2013, 15:42
                    • N/A - Rugxulo, 24.06.2013, 19:20
                    • TCC 0.9.26 (Win32) - Rugxulo, 25.06.2013, 18:18
                      • TCC 0.9.26 (Win32) - RayeR, 27.06.2013, 11:03
                        • TCC 0.9.26 (Win32) - Rugxulo, 27.06.2013, 15:31
                          • TCC 0.9.26 (Win32) - RayeR, 28.06.2013, 00:14
                            • TCC 0.9.26 (Win32) - Rugxulo, 28.06.2013, 05:45
                              • TCC 0.9.26 (Win32) - RayeR, 28.06.2013, 14:52
                                • TCC 0.9.26 (Win32) - Rugxulo, 29.06.2013, 13:25
                                  • TCC 0.9.26 (Win32) - RayeR, 30.06.2013, 00:07
                                    • TCC 0.9.26 (Win32) - Rugxulo, 30.06.2013, 14:46
                                      • TCC 0.9.26 (Win32) - RayeR, 01.07.2013, 02:51
                    • CC386 4.17 - 2013-Jul-12 (INFOPAD from 4.16 2013-Jun-25) - DOS386, 09.08.2013, 11:03
                      • CC386 4.18 + OCC 5.09 - DOS386, 04.12.2013, 12:30
                        • CC386 4.19 - Rugxulo, 21.01.2014, 06:22
                        • CC386 4.18 + OCC 5.09 - Rugxulo, 06.04.2014, 00:34