LLVM-MOS

[DigitalMonk]

Just wanted to drive by and toss this out there:

https://llvm-mos.org/wiki/Welcome

https://github.com/llvm-mos

I've been poking around on the beginnings of a game, something I wish I'd known enough to be able to do 35 years ago...  I was using KickC, which is very cool, but I was running into too many issues and starting to spend more time on workarounds than on programming.  Then, yesterday, I found out that there's an actively developed and complete 6502 backend for LLVM, which means you can do pretty much anything the LLVM frontends can do and then spit it out to your 6502.  Library support may be challenging, of course.  As of today, only the C64 (and Atari 800) has linker target files, but I've played with them (they're compatible with GCC ld linker scripts) and it shouldn't be too hard to create new ones for other targets.  If you follow that link, you'll see that they've built programs for VIC-20, Apple IIe, C64, and even built a simple Rust program onto an Atari 800.  Creating target files for the X16 shouldn't be particularly difficult.

That having been said, don't expect any of the IO (printf, gets, files) to magically work out of the box today.  This is in _ACTIVE_ development, and their focus is currently on C64.  The backend 6502 codegen passes all LLVM unit tests (a few thousand), and that was announced in a post from just a few days ago.

But if you're willing to just hammer the hardware with your own routines, well, it's pretty slick.  I haven't gotten around to X16 programming yet, but I wanted to attach a screenshot of what I've been working on as compiled by LLVM-MOS's clang compiler for the C64.  I've been building the project to cross compile for the PET, VIC-20, C64, and C128 with different graphics on each, so I should probably just add an X16 target ?

[desertfish]

Ok wow

Any idea about the quality of the program's code that it produces?

Maybe eventually using llvm with all its advanced code optimizations as a backend for Prog8 isn't totally impossible...

[Scott Robison]

I'd love it if I could use C++ to target 6502. ?

[DigitalMonk]

I'm going to leave it to the LLVM-MOS guys to give status (although, my experience suggests that they are actually further along than this page suggests):

https://llvm-mos.org/wiki/Current_status

Also, to answer "why?" and also performance/features kinds of questions:

https://llvm-mos.org/wiki/Rationale

(I find the "Findings" section at the bottom especially interesting)

[SlithyMatt]

cout << "Hello, World!";

⏲️?

Hello, World!

[DigitalMonk]

Is that a comment on compilation speed or C++ speed?

If you're concerned about compilation speed, LLVM-MOS is currently much faster than KickC for my project.

If you're concerned about C++ performance, that has been corrected and refuted for at least 10 years.  High-level optimization kicks the crud out of low-level peephole optimization.

LLVM is crazy fast to compile, AND it optimizes the heck out of the intermediate code that it generates, discarding all of the abstractualization overhead that simplistic C++ compilers in ye olden dayes created.  What it hands off to the back end is already optimized enough that a straightforward 6502 code generation is sufficient to outperform most people's expectations (see the "Findings" section in the link above).  And the LLVM-MOS guys haven't even started looking at "codegen level" optimizations yet.

[SlithyMatt]

12 minutes ago, DigitalMonk said:

Is that a comment on compilation speed or C++ speed?

It's about what kind of 6502/X16 code would be generated from an LLVM iostream implementation. Using C++ is nice, but using the language as intended on a 6502-based system is a bit dicey. What's lean and efficient on an x86-64 or ARM64 with GB of RAM could still be bloated and sluggish on a 6502 with kB of RAM.

[Scott Robison]

5 minutes ago, SlithyMatt said:

It's about what kind of 6502/X16 code would be generated from an LLVM iostream implementation. Using C++ is nice, but using the language as intended on a 6502-based system is a bit dicey. What's lean and efficient on an x86-64 or ARM64 with GB of RAM could still be bloated and sluggish on a 6502 with kB of RAM.

Note that I'm not necessarily talking about using the entire standard C++ library (though for some app types that would be fine as well). More than anything what I really want is efficient expression of template based code (including templates in the standard library).

There are freestanding and hosted expectations. I don't necessarily need hosted. I would love freestanding.

[DigitalMonk]

You might be surprised by how little bloat is in modern iostream implementations.  Memory allocation, copying, and deallocation are performance headaches for all computers, regardless of how much they have.  The C++ standards team have spent a huge amount of time and effort making the core libraries lean and efficient, with minimal unnecessary copying and heap interaction.

That being said, I personally don't care about iostream and never use it.  C++ still provides stronger type checking, readily available data structures, and many benefits that I use all the time in small embedded projects.  How many X16 are going to be doing text work where "I don't really care that much about formatting, just push this information out there"?  If anything, I'd think a low resolution text screen would be a bigger problem, because you have to be so careful about exactly how you display everything (and iostreams is ridiculously annoying for formatting issues).

And I definitely second Scott's comments.  Even if I loved iostream, nothing in my project would benefit from having it...

I just know that a lot of people hate C++ because "it's so bloated", and that just isn't the case any more in either space or speed.

[Scott Robison]

Not trying to be condescending, but since many people don't know the difference between freestanding and hosted, https://en.cppreference.com/w/cpp/freestanding might prove useful.