Commander X16

None of what I've been saying is meant as flame, though I'm sure it reads like that.  I do get heated because of misunderstandings about what C++ is now, and because of how frequently those misunderstandings are repeated in public forums where people who are coming to learn just pick it up as "truth" and continue the problem.

"all this complexity and abstraction"...  C++ is only complex if you need it to be.  Abstraction is a very useful tool to increase programmer efficiency.  And neither needs to water down anything.  All the heavy lifting of expanding out the abstractions/complexities happens at compile time.  Then it gets optimized back down to just the parts you were using.  Which you were going to be using no matter what language you used.  And then that minimal pseudo code is converted to 6502 opcodes.

With new compilers and libraries (and LLVM is the newest, pretty much), C++ has repeatedly beaten C at performance tests.  And not because the runtime has some huge library component that wouldn't fit on a 6502, but because modern C++ compilers write better C than C programmers do.  And they do it because they simultaneously get the benefit (from all that complexity and abstraction) of better understanding what the programmer was actually trying to do (ie, if I use the std::nth_element algorithm, the compiler knows much more about what I'm trying to do than if it was just looking at some for loops and conditionals) AND of being a tireless worker with nearly limitless concentration and memory who can see opportunities for code reuse, simplification, etc.  Oh, and all that cool pre-computation that lets games and demos run so fast?  In modern C++, the compiler automatically figures out if a string of execution -- even if it spans multiple function calls -- is actually a constant and can be performed at compile time so that the final result is just stomped directly into the opcode.

Yes, an expert C programmer can outperform an average C++ programmer.  But I suspect an expert C++ programmer could outperform an expert C programmer.  And it's really about the averages anyway, if this is a learning computer, and in the average case, C++ gives an average programmer the benefits of an expert programmer under-the-hood.

Nothing about the C++ experience would be "watered down."  You don't write the same kinds of programs on an X16 that you write on a generic PC, but that doesn't mean that the tools that have been constantly improving for decades aren't a good fit.  Anything that would require a heap or other "bloat" in C++ would require the exact same capability from C, but be much more likely to leak in C because C only has dumb pointers, while C++ provides dumb pointers, reference counted pointers, weak pointers, and unique pointers.

"C++ is unwieldy" is an old trope that has been repeated for so long that many people don't even question it.  But it simply isn't true.  It comes from the time when C++ was basically just a hairy preprocessor in front of C code.  Anything after C++11 is a completely different beast, and things are accelerating.

One last thing I'm going to throw out there, and then I swear I'm going to try to stop...  C++ isn't really about "Object Oriented Programming" any more.  Sure, it's still got classes.  But the originators of OOP figured out (after 20 years or so of people trying to work out the issues) that OOP doesn't deliver on its promises.  OOP is also where all of the heap flail and bloat came from.  So, when you look at what gets C++ programmers excited now, it's mostly about template metaprogramming -- making the compiler write the tedious dreck for you (which the optimizer then pares down to only the bits you actually used).  If you think that's only for wizards or academia, look at KickAssembler, whose primary claim to fame is its extensive metaprogramming capabilities.  Now, personally, while I am super stoked by the things you can do with metaprogramming, I will be the first to admit that C++'s syntax is ugly, and there are other languages out there that do it easier and more cleanly.  But you REALLY can't get those compilers for specialized processors and systems, and most of them do require a hefty runtime.  C++ remains one of the few languages that can give you every tool you could hope for and yet still run on a tiny constrained system (note that the LLVM-MOS guys made code for a VIC-20, so...)   Rust is another, which also provides a lot of compile time guarantees about correct memory usage without requiring any runtime on the host, and someone has already shown using LLVM-MOS as a backend for Rust to generate a program on a 6502 machine.  C++ remains a "system programming language", one of the few out there that meet the criteria of driving hardware at its lowest level.

(I'm 50, and I've fought with lack of C++ in the embedded world for decades.  And even when it was available, it would be the ancient C++98 variant, which did still have all the issues you're worried about.  My life changed immensely when the embedded tools I have to use FINALLY introduced C++11 almost 10 years after it was ready.  Fortunately for me, they've been a little zippier since then, and they're up to C++17 support.  It still amazes me, when GCC and LLVM are freely available and more powerful than any proprietary compiler that these chip makers continue to put out their own garbage...)

(Oh, and I would _NEVER_ suggest trying to write a C++ compiler to run ON the X16.  That would be horrible.)

Interesting (to me) aside: I got the job working on PCBoard in part because I had written my own BBS for my C=64 in the mid 80s. It wasn't *great* but it demonstrated I had experience in the "market" (though I only wrote it for myself and never actually marketed it).

5 minutes ago, DigitalMonk said:

(Oh, and I would _NEVER_ suggest trying to write a C++ compiler to run ON the X16.  That would be horrible.)

Challenge accepted! #hahaha

1 minute ago, Scott Robison said:

Challenge accepted! #hahaha

DO IT!!!

Upon reflection:  Oh lord...  I mean, I suppose you could always cram the LLVM source code through LLVM-MOS.  I don't know how huge the resulting PRG would be, since there is a LOT of logic in LLVM. 

I've looked into using a C compiler on the C64, and that was insane.  You had to have either two or three floppy drives to even start, and all the steps were separate, and just argh...

I would also like to mention, for those who might not be old enough to know, that back in the day a whole lot of commercial programming was cross-development as well.  Programmers worked on minicomputers that crunched out binaries to test on the little home computers.  Home programmers programmed on their computer 'coz it was the only thing they had and they were having fun, but once time and efficiency got into it, compilation moved off to bigger machines.  So using LLVM's giant brain on a 32-core Ryzen to develop X16 code isn't as ridiculous as it might otherwise sound.  It's just the modern version of what they used to do, and saves you tearing out (as much of) your hair.

4 minutes ago, DigitalMonk said:

I've looked into using a C compiler on the C64, and that was insane.  You had to have either two or three floppy drives to even start, and all the steps were separate, and just argh...

The only reason C or C++ might be possible on X16 would be the 512K to 2048K of banked RAM. All those floppies were compensating for the lack of RAM (or so is generally my experience).

6 minutes ago, Scott Robison said:

The only reason C or C++ might be possible on X16 would be the 512K to 2048K of banked RAM. All those floppies were compensating for the lack of RAM (or so is generally my experience).

C is possible, there were at least three commercial C compilers back in the 80s.

C++, well, maaaaaaaybe C++98ish.  But just as a meaningless point of information, clang++ (the C++ compiler for LLVM-MOS) is 84.5MB.  That's not it's memory footprint, just the executable size.  Now, granted, clang, clang-13, and clang++ are all the same size, so I suspect that is one mega compiler/librarian/linker application for multiple similar languages, but it's waaaaaay beyond the 2MB for the big X16...

But I love to see people tackling impossible odds.  Frequently they found out that they're merely ludicrously difficult ?

5 minutes ago, DigitalMonk said:

C is possible, there were at least three commercial C compilers back in the 80s.



C++, well, maaaaaaaybe C++98ish.  But just as a meaningless point of information, clang++ (the C++ compiler for LLVM-MOS) is 84.5MB.  That's not it's memory footprint, just the executable size.  Now, granted, clang, clang-13, and clang++ are all the same size, so I suspect that is one mega compiler/librarian/linker application for multiple similar languages, but it's waaaaaay beyond the 2MB for the big X16...



But I love to see people tackling impossible odds.  Frequently they found out that they're merely ludicrously difficult ?

When I say "possible" I mean "possible to do without needing to swap to disk". In other words, floppy disks are just very slow RAM. Hard disks are slightly faster RAM. CD / DVD / bluray is slow ROM (ignoring the possibility of -RW or -RAM versions). Printers are WOM. ?

Further, by "possible" I do not mean "feature parity with an x64 native edition of the same compiler".

2 hours ago, DigitalMonk said:

DO IT!!!



Upon reflection:  Oh lord...  I mean, I suppose you could always cram the LLVM source code through LLVM-MOS.  I don't know how huge the resulting PRG would be, since there is a LOT of logic in LLVM.  ...

The tack to take might be to use LLVM to speed optimize a C++ compiler that had been written to fit into a small (for C++) space, and adapt a smart linker to use LLVM to compile libraries for that compiler, so you take the normal C performance hit on code compiled by the the hosted C++ compiler, but it is calling speed optimized libraries to help make up for it.

For me, the appeal would be to get AWK up and running without having to write it from scratch.

I've had a lot of fun writing software for the Commodore 64 in Rust with this over the past week. One nice thing about Rust is how it divides the standard library into three parts: completely freestanding, things that only require heap allocation, and things which require a full OS. So much of the standard library is already available on the C64, although I did end up replacing the formatting stuff with a third-party library in order to get smaller executable sizes.



The LLVM backend is still not ready for making finished software yet, due to a few limitations such as not being able to handle code being called from interrupts, since it tries to statically allocate memory for functions instead of using the stack, which breaks down when interrupts get involved. Nonetheless, it's definitely ready for experimentation and writing fun things for 6502-based platforms. They have a Slack group that you can join from the link on their wiki.

I mentioned it was in active development, but just for a sense of scale: