68000 support has landed in LLVM

[sandord]

Apparently, 68000 support has landed in LLVM. I'm not too informed about this but I guess this means we can finally expect modern C/C++ compiler based cross compilation in the near future for our beloved STs.

Here's a link to the new 68K part in the LLVM source: https://github.com/llvm/llvm-project/tr ... arget/M68k

[czietz]

It's quite an impressive achievement by Min, yes. He talked about it a few months ago in an Planet m68k evening chat: http://m68k.info/#orgf36bc79

But it's still a very long way before LLVM (or rather Clang) becomes usable on the Atari. For example, there are no libraries (not even the standard C library), nor is it capable of generating TOS executables. In contrast, all of this exists for gcc, which already gives you modern C/C++ compiler based cross compilation today.

[stephen_usher]

Given the bloat most modern compilers produce I wouldn't be surprised if cross compiled binaries for "Hello World!" are larger than the ST's memory.

[czietz]

Given the bloat most modern compilers produce I wouldn't be surprised if cross compiled binaries for "Hello World!" are larger than the ST's memory.

Hm, "Hello world" with gcc 9.3.1 and libcmini: 3.4 kBytes.

[thorsten.otto]

Given the bloat most modern compilers produce I wouldn't be surprised if cross compiled binaries for "Hello World!" are larger than the ST's memory.

That's mostly a matter of the library rather than the code produced by the compiler. Look at EmuTOS, which has lots of features in the 192k ROM from newer TOS versions, a builtin harddisk driver and several other things, compared to the original 192k ROMs that were compiled by an ancient compiler (and even large parts done in assembler).

[mfro]

Given the bloat most modern compilers produce I wouldn't be surprised if cross compiled binaries for "Hello World!" are larger than the ST's memory.

Hm, "Hello world" with gcc 9.3.1 and libcmini: 3.4 kBytes.

Thanks a lot for promoting libcmini! ;).

To be fair, however, I think it must be mentioned that it's not mintlib's fault to produce so much larger binaries than libcmini. It's more a question of what you want to achieve. Mintlib was designed from the beginning as a universal library to support as much standard functionality as possible. It has (nearly) full ISO standard conformance and also supports gcc and other extensions. As a result, you can throw most sourcecode at it that has been originally written for Unix/Linux and it will compile with minimum or even no change at all. There is one huge drawback: size.

Libcmini does not aim to compete in that area at all. Its aim is to produce the smallest possible size for binaries and it doesn't care much about standards compatibility. If you want, it more or less disregards any development of the C language standardisation after the 80s. But it allows to create really small C programs for our dinosaurs.

IMHO, both approaches have their own value (and its good to have a choice).