Commander X16

Even if it's a freestanding application with no iostream or other standard library calls, this is still not a bare-metal Raspberry Pi were talking about here. The X16 is much, much smaller. You will still need a separate frame stack and probably a heap to make C++ worthwhile. You could allocate everything statically, and then you just have classes standing in for structs and not doing any of the actual OO things. The question really becomes, "what is the value added by developing with C++ over C for the X16?" Sure, you COULD do it, but is it really going to make development any more efficient or enjoyable? Or is it just a parlor trick of "hey, look: 8-bit C++" and then you go back to assembly or just plain old C to develop a real application?

It's also a bit of a moot point today, because the LLVM-MOS team is focusing on C.  The C++ headers aren't there yet.  But that's more an issue of having the time to put them in and test them all.  No real reason why they wouldn't work.

Unfortunately, that does mean that all those wonderful STL tools and libraries aren't available yet.  But it's just a matter of time.  And the C++ LANGUAGE features are there, so it's entirely possible that you could use Boost header-only libraries to get some heavy lifting done...

 

8 minutes ago, SlithyMatt said:

Even if it's a freestanding application with no iostream or other standard library calls, this is still not a bare-metal Raspberry Pi were talking about here. The X16 is much, much smaller. You will still need a separate frame stack and probably a heap to make C++ worthwhile. You could allocate everything statically, and then you just have classes standing in for structs and not doing any of the actual OO things. The question really becomes, "what is the value added by developing with C++ over C for the X16?" Sure, you COULD do it, but is it really going to make development any more efficient or enjoyable? Or is it just a parlor trick of "hey, look: 8-bit C++" and then you go back to assembly or just plain old C to develop a real application?

First off, the X16 is going to have 512kB or 2MB of RAM, right?  C++ was absolutely used on DOS machines with that "little" memory.  Yes, the paging nature adds some complexity, but it adds complexity for everybody.  Once it's handled in the runtime library, we'd be able to (mostly) forget about it as application developers.  We'd probably want some way to hint things to pack heap items into common heap pages for maximum efficiency, but that problem was addressed decades ago by overlay linkers.

As for speed, that 8MHz 6502 is comparable to a 32MHz z80, so faster than any 8086 that was ever meaningfully fielded.

PLEASE REMEMBER:  Arduino's use C++ as their core language, and most of them have less memory than even the starting X16 is going to have.  IN PARTICULAR,

The ATmega328 chip found on the Uno has the following amounts of memory:

Flash  32k bytes (of which .5k is used for the bootloader)
SRAM   2k bytes
EEPROM 1k byte

Yep.  2kB of RAM and only 32kB of flash.  I could pack __ANY__ Arduino Uno sketch, libraries and everything into just over half of a C64.  And believe me, Arduino uses iostreams.

Personally, I'd say being able to take the growing makerspace of Arduino hackers and bring them to the 6502 world would be a Good Thing(TM)

I think it might be time to drag out this old link that was posted about 12 times to the Facebook community.

 

This is supposed to be a teaching computer.  Anything that adds to that goal is great. Being able to program in lots of different languages or classes of languages is definitely to be encouraged. 

Anyone want to take a crack at LISP?

25 minutes ago, kelli217 said:

I think it might be time to drag out this old link that was posted about 12 times to the Facebook community.

Thank you.  And I feel the need to point out that the code generation in that particular effort is very messy.  He uses an x86 compiler to generate x86 assembly, then rams that through his own x86->6502 translator.  Which works, but all that x86 code thought that integers were 32 bit.  The LLVM-MOS effort uses 16 bit as the default int, 8 bit chars, and 32 bit longs (which is the approach taken by many, many compilers in the 16 bit era).  So the LLVM-MOS output will already be much cleaner, smaller, and faster than the code generated in that video.

15 minutes ago, Ed Minchau said:

This is supposed to be a teaching computer.  Anything that adds to that goal is great. Being able to program in lots of different languages or classes of languages is definitely to be encouraged. 



Anyone want to take a crack at LISP?

Well, Micro-LISP exists for the C64, so doing it on the X16 should be easy...


micro-lisp.pdf

26 minutes ago, DigitalMonk said:

The ATmega328 chip found on the Uno has the following amounts of memory

I don't doubt you could pack a very simple C++ program into that much memory. But you are also dealing with a MUCH faster processor than an 8MHz 6502, and a much simpler system that doesn't have to do things like manage VERA graphics and play PSG sound effects.

As for C++ on mid-80s DOS PCs, it was not really a common thing, and I don't know of any commercial software that was developed using C++ for that platform in that era. C++ didn't really take off on Wintel PCs until the advent of Visual C++, and that was really for 486 machines and better.

Look, I don't want to discourage people from trying anything, but just to manage expectations. We have the gift of the X16: a machine so beautifully simple and yet so capable it becomes a joy to program in assembly language or in very simplified C and create really wonderful software. Adding all this complexity and abstraction is just going to give you something watered down, a less capable PC. Again, JUST MY OPINION, but this goes into the territory of just getting a Raspberry Pi and doing C++ development there. Or python or whatever.

7 minutes ago, SlithyMatt said:

I don't doubt you could pack a very simple C++ program into that much memory. But you are also dealing with a MUCH faster processor than an 8MHz 6502, and a much simpler system that doesn't have to do things like manage VERA graphics and play PSG sound effects.



As for C++ on mid-80s DOS PCs, it was not really a common thing, and I don't know of any commercial software that was developed using C++ for that platform in that era. C++ didn't really take off on Wintel PCs until the advent of Visual C++, and that was really for 486 machines and better.



Look, I don't want to discourage people from trying anything, but just to manage expectations. We have the gift of the X16: a machine so beautifully simple and yet so capable it becomes a joy to program in assembly language or in very simplified C and create really wonderful software. Adding all this complexity and abstraction is just going to give you something watered down, a less capable PC. Again, JUST MY OPINION, but this goes into the territory of just getting a Raspberry Pi and doing C++ development there. Or python or whatever.

The first DOS C++ compiler as far as I know (at least the first I used) was Turbo C++ which I think was released in 1990. But that is pre-standard C++, much less modern C++17 / C++20. The current language definition has so much optimization opportunity with const, constexpr, templates and lambda functions (only const was supported in 1990) that it might as well be a different language. You simply can't compare 1990 era C++ with 2020 era C++.

In many ways it is the difference between a simple machine language monitor that only recognizes mnemonics, addressing modes, and hex numbers, and a fully featured macro assembler that allows you to build your own assembler syntax with relocatable segments ala ca65 / ld65 or comparable systems.

The video linked above basically gives you a freestanding implementation of "modern C++" that can be used to generate 6502 family assembly, though with more tools in the toolchain to jump through. Getting an LLVM supported way that doesn't require translation from 32-bit x86 to 8-bit 6502 is just a little more neat of a process *if* it generates the equivalent of hand rolled assembly language.

Certainly I'm not trying to tell the world they should use C++ instead of assembly on a X16. I'm saying I'd like a good optimizing compiler for C++ that would support the X16. In that case, you can have functions that are evaluated at compile time and have zero stack parameter passing overhead, because the compiler is smart enough to see that all the information to inline the function is available at compile time.

Sorry for the tautological statement...

Microsoft's first C++ was apparently also released in 1990, though I have no idea how well it worked.

I was working for Clark Development Company between 1992 & 1995, and I used Borland C++ for the PCBoard Programming Language which was very well received. We were already using Borland Turbo C & Turbo Assembler for PCBoard, and I convinced them to allow me to use C++ for the scripting language we added to PCBoard v15. I saw that code recently and it is not pretty (I was much younger and less experienced) but it predated Visual C++ v1 in 1993.

https://en.wikipedia.org/wiki/PCBoard#History for a brief history of PCBoard / PPL (though it doesn't discuss the fact that it was C++) for those who are interested.