Jump to content

DigitalMonk

Members
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

8 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Whoops! Sorry for mis-using the term "pseudo-registers" when I was talking about "imaginary registers"... I haven't started X16 programming yet, so I was just thinking about imaginary registers LLVM-MOS uses for PET/VIC/C64/C128/Atari/etc.
  2. First, their focus has been on clang, not clang++, so I'm not sure how much C++ support is present (I would expect all the language features to be there because that's a front-end common thing, but I know that the runtime library doesn't exist because that's a backend supplied library and they haven't worked on it yet). I do want to start poking around with C++ language features, just to see how they go, but I want to get all my platforms working again first. Second, I'd swear that I've seen somewhere (thought it was this thread, but can't find it) that interrupt handlers couldn't be written yet because of an implementation detail about how they handle function calls... __BUT__ I've been trying to compare and contrast 5 different C compilers, so I could very easily be thinking of one of the others...
  3. Yeah... I was really hoping I could just slip by on those... A lot of them are BASIC workspaces that shouldn't matter much, but there are also KERNAL workspaces that would be very bad to stomp on. I'll have to break out all my ZP memory maps and compare them. I'm really glad that the number of pseudo-registers and their locations is completely configurable through just text files. Once I can get all my stuff running, I will make a cleanup pass to make sure I don't have "hackery" left sitting around, and then I'll definitely send a pull-request... Hmmm, gotta fork the repo inside GitHub first, probably, instead of just messing with it on my local machine
  4. *SMH* D'oh! Thank you for that... Just got jammed into my mental rut... OK, all four platforms at least build and link now. They load and (except for the VIC) have the correct BASIC SYS command waiting. Now I just have to be more careful about linker files and where I'm placing my fonts and graphics and where the stack goes, and so forth ('coz they CPU JAM "immediately" if I run them )
  5. I would be very interested in the details of your tweaks. Did you make an X16 target alongside the existing 64 target, or did you just modify the 64 files into X16 files? I'm trying to make my little game for the 128, 64, VIC, and PET, and they all put BASIC in different places... 64 works, of course. I'm trying to get 128 working next. My first attempt modified files directly in the 'build' directories. I copied the 64 source directory and renamed it to 128. I modified the ldscripts/link.ld to use the 1c01/1c0d addresses needed on the 128. I renamed 64.cfg to 128.cfg and tweaked the comments (the actual commands didn't appear to need modification). Got a valid PRG. Tried to autostart it in VICE and it exploded. Automounted it instead so that I could list it, and it was "7773SYS2061", so the basic header didn't autoadjust to the linker start point (I got lazy with KickC, because it generates the basic header on the fly). Realizing that I'd been hacking on output files instead of editing inputs, I moved out to the actual source code directories. Did the equivalent edits from above to the source. Then I adjusted various CMakeLists.txt files to include the new directory. I modified the lib/basic_header.s to use 7181 (1c0d) in the SYS command. Ran ninja to rebuild and I get ``` [0/1] /usr/bin/cmake -S/home/mac/games/llvm-mos-sdk -B/home/mac/games/llvm-mos-sdk/build CMake Error at cmake/modules/AddObjectFile.cmake:10 (add_library): add_library cannot create target "basic_header" because another target with the same name already exists. The existing target is created in source directory "/home/mac/games/llvm-mos-sdk/commodore/64/lib". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): commodore/128/lib/CMakeLists.txt:6 (add_object_file) ``` I'm not much of a CMake or ninja user, just following steps and extrapolating what I can. I don't quite see why the 128's basic_header is conflicting with the 64's basic_header. They should be in separate directories. But they only have one target machine under each "brand" of computer, so there may be some assumption buried somewhere that I'm just missing. I think I looked at all the CMakeLists.txt from the root down and I can't see it, but that doesn't surprise me, really...
  6. They seem to be _VERY_ strict about there unit and integration testing. No Pull Requests are allowed unless they are covered by an existing test or include new ones. All code has to follow the LLVM coding and quality guidelines. None of that stops errors getting in, of course, but it should severely limit the "quick hack" kind of coding that leads to fix/re-fix/fix-again/no-this-time-really/argh commits... I am incredibly stoked that there are so many C compiler efforts out there now for 6502: cc65, of course, which is pretty rock solid but unfortunately generates (by far) the slowest/largest code. But it always works. gcc-6502 has the GCC front end goodness, but still some backend issues, and is pretty much dead unfortunately... KickC is quite active and the lead developer is responsive and helpful. Very cool if you want to mix and match with KickAssembler NutStudio has been mentioned in another thread here. I had good luck in my initial forays with it. He's not ready to release, but is open to beta testers LLVM-MOS which appears to be very serious about the whole effort
  7. Awwwww... Did you have to ruin my fantasy of hundreds of retro-enthusiasts frantically hacking towards getting this completed? Still, 2-3 a day is pretty good!
  8. I mentioned it was in active development, but just for a sense of scale: llvm-mos-linux-main github-actions released this 21 hours ago · 8911 commits to fd5a4cc2c8cb064afe6df5ccb436831ef8743bda since this release Almost 9000 commits in less than a day. Basically, if it's doing what you want, just use what you have. But if you have any issues, grab a new build coz they may have already fixed your problem...
  9. 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
  10. 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.
  11. 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.)
  12. Well, Micro-LISP exists for the C64, so doing it on the X16 should be easy... micro-lisp.pdf
  13. 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.
  14. 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)
  15. 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...
×
×
  • Create New...

Important Information

Please review our Terms of Use