Kaj de Vos Posted April 24, 2021 Author Share Posted April 24, 2021 I have many projects planned in the language. They're quite varied, and I'm not sure the list would tell you much more. They're all the projects that I tried and contemplated over the years and ran into walls with due to the environments I had to use. For the first time in three decades, I don't feel those barriers anymore. A lot of work needs to be done for them, but it's all solvable now. In my mind, there's a distinct coherence to these plans, but it tends to be hard to explain to people with different experiences. So I am here for people who understand the Atari passion, and in REBOL circles I will look for people who understand REBOL, and so forth. I think a language should empower and support you to make what you want. Most languages, including REBOL, throw up too many barriers. One kind of barrier is a limit on the platforms you can use. There is really only one cross-platform language that lets you do almost anything you want on almost any system: C. But it's half a century old, and at the time it was already envisioned as a primitive language compared to its contemporaries, to compete with assembly on underpowered systems. I think the REBOL language concepts are ideal to retrace this path and raise it to a higher level. So I want to make a language core like C, that is, unlike REBOL, flexible enough to adapt to my use cases and your use cases. I'm adamant now that it must work on small systems the way I want, so there will be a good foundation and this will always be the case. As long as I live, Atari will be supported. For later, I think I will put in my testament that anyone who deteriorates Atari support will be haunted by my ghost for all eternity. ? However, this seems overly concerned. I also target systems with 128 bytes of memory. 48 KB is an ocean of memory. ?In any case, 48K ought to be enough for everyone. ? In the future there will be many features that will not be available for Atari, but that is different. It's the same situation with C. Nobody complains CC65 doesn't support Atari because GTK+ is not available. This is quite different from the REBOL concept, which is like a golden cage, that I am now escaping. My target audience is everyone, to use the language for what they want. Whether a person will take up the offer is up to them. C can be used for almost anything, but not everybody can use it. My language will be easier and within reach of more people. I am interested to know why you think you are not in the target audience? Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 24, 2021 Author Share Posted April 24, 2021 2 hours ago, ivop said: You might also want to look into ThinLTO, which can be enabled by -flto=thin with clang. I saw that, but it sounded to me like it does less, so I didn't look at it further. What does it do? I actually looked over the hundreds of CLang options, but -flto didn't strike a chord with me. It explains itself as "LTO". I think that's what modern humans call "Duh!" these days. Had it explained itself as "Link Time Optimisation", I would have recognised it as the option I was looking for. Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 24, 2021 Author Share Posted April 24, 2021 I see ThinLTO indeed does less. I see papers from 2016 to now "Towards Always-Enabled LTO". It all seems to be very difficult. I would have expected LLVM to solve this early on. I seem to give projects too much credit. Anyway, thanks for the updates about the state of things. It helps me a lot. Quote Link to comment Share on other sites More sharing options...
ivop Posted April 24, 2021 Share Posted April 24, 2021 Yes, ThinLTO is a compromise for always-enabled LTO. "Normal" LTO does not scale well. ThinLTO does. You were saying Syllable OS took ages to compile, so hence my suggestion to look into this It especially helps if you make only a single change in a 10MLOC project. You still get most of LTO, and you can compile your final version with full LTO. Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 24, 2021 Author Share Posted April 24, 2021 GCC was already a monument twenty years ago when we started Syllable. I always assumed it did most things right. In any case, it was always unthinkable to me that linkers could not distinguish between multiple functions in one source file. I saw huge library source files scrolling by day and night for many years. We knew some things could be improved because LLVM said so. I also knew from their status reports that their optimising runtime loader was going slowly, but I always thought the compile-time linker was long done. Really, this is all twenty years ago. I always had a lingering wish to switch to CLang, but the GCC situation was already very complex. Syllable was an enormously much lighter system than other operating systems, but compared to REBOL, it was a juggernaut. You could never rely on subtle things such as incremental builds being reliable, so I always built the entire operating system start to finish, only segmented in some course-grained software collections. Quote Link to comment Share on other sites More sharing options...
Alfred Posted April 24, 2021 Share Posted April 24, 2021 2 hours ago, Kaj de Vos said: My target audience is everyone, to use the language for what they want. Whether a person will take up the offer is up to them. C can be used for almost anything, but not everybody can use it. My language will be easier and within reach of more people. I am interested to know why you think you are not in the target audience? I have programmed in assembly language for different platforms for nearly 40 years now. On the Atari, assembler is my default because of the need for both decent performance and a small footprint. Most of the higher level languages are fairly inefficient. PL/65 wastes 1/3 to 1/2 of it's code to pushing or pulling things from the stack. CLSN Pascal is a veritable ocean of JSR calls to library calls and memory swapping code. Action! isn't too bad for say small projects, but it's handling of pointers and arrays internally is very slow. The other issue I have with high level languages like say Delphi which is what I mostly use on the PC these days, is that when you run into problems, you first have to determine if the bug is in your code, the compiler, or some third-party library. Assembly language doesn't have that problem, at least not on the Atari, where it's always your bug. Abstraction takes away from performance, and I don't see what advantage generic types and such bring to say developing a Robotron clone or a database program. I saw somewhere that Rebol was supposed to be good for implementing languages, so if could produce a modem version of say Action!, then from my point of view, perhaps it has its uses. It always kills me when some language maven gives an example of say a 1-line webserver implemented in their latest offering, as if the 5 million LOC in the backend to make it work just magically don't count. By all means, keep on with it. I think you might be disappointed in the crowdfunding response, but who knows, maybe people will pony up. 1 Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 24, 2021 Author Share Posted April 24, 2021 For Atari, I have the integrated assembler. It allows the same philosophy as PL65: write the critical parts in assembly, but save time by writing the non-critical skeleton in a higher-level language. For larger systems, I completely agree that all the layers get in the way. REBOL's battle yell was always the fight against complexity. REBOL is far simpler than other modern languages, and my language is far simpler than REBOL. Cutting out layers improves performance a lot. The abstraction is still there, but most of the intermediate layers are not needed. REBOL languages are actually very suitable for writing database programs. It's customary for REBOL programmers to avoid complex databases, because they are seldomly needed with REBOL. Indeed, REBOL is designed for implementing domain-specific languages. It's extremely useful for implementing my language. No Lex and YACC and such stuff, it's a very different model. Funding was always a problem with all previous projects. I have some ideas how to fix that. It's one of the reasons why I'm very particular about how to do this project. Quote Link to comment Share on other sites More sharing options...
zbyti Posted April 24, 2021 Share Posted April 24, 2021 As like in Effectus, there will be 2 layers of bug finding for programmers. Effectus -> Mad Pascal -> MADS Quote Link to comment Share on other sites More sharing options...
dmsc Posted April 25, 2021 Share Posted April 25, 2021 Hi! 4 hours ago, Kaj de Vos said: GCC was already a monument twenty years ago when we started Syllable. I always assumed it did most things right. In any case, it was always unthinkable to me that linkers could not distinguish between multiple functions in one source file. I saw huge library source files scrolling by day and night for many years. We knew some things could be improved because LLVM said so. I also knew from their status reports that their optimising runtime loader was going slowly, but I always thought the compile-time linker was long done. Really, this is all twenty years ago. You seem to think that somehow CLANG is more advanced than GCC. This is false. CLANG is a newer project, and has a lot of commercial baking, so it is catching up to GCC fast, but IMHO, it is still behind: it support less targets, is is less mature and it optimizes about the same in common architectures (it produces code sometimes faster, sometimes slower than GCC). GCC support Link-Time-Optimization from version 4.5, released in 2009, just a few months prior to the release of the first version of CLANG (1.0) that still did not had complete C++ support. So, why LTO is not enabled by default? - It is slow, specially on big C++ projects. As the full source code is "visible" to the compiler, and C++ templates produce code explosion, the compiler has to analyze a lot of code, using a lot of memory. - It can fail in older codebases that cheat with symbol types - this was a common pattern, define one symbol (variable or function) with different types in different source files. Both Chrome and Firefox use LTO for their release builds, as it produces faster and smaller code, specially on those projects that include a lot of libraries internally to avoid shipping DLLs. Have Fun! 1 Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 25, 2021 Author Share Posted April 25, 2021 Yes, LLVM has that aura. CLang less so, I always thought it was way too big. But they are more modular, they open their intermediate code format and provide API's, which was very important to my language plans. For Syllable, we saw what a mess the GNU software was. LLVM was said to be cleaner. I can't really say. I didn't like that it is C++, but that did match Syllable well. I saw that LTO is slow. But it's such a fundamental feature, long advertised for LLVM, that I would have expected it to be included in -O3. In general, cleaner software tends to come from smaller projects. Opening up a project to a community makes it messy, but it broadens the acceptance. There is no ideal solution, so I will have to do some cord dancing there. Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 25, 2021 Author Share Posted April 25, 2021 11 hours ago, zbyti said: As like in Effectus, there will be 2 layers of bug finding for programmers. Effectus -> Mad Pascal -> MADS True, CC65 is the layer still inbetween, and that bugs me. Hence my talking about eventually cutting that out, too, in favour of a native Atari backend. But for the moment being, CC65 is instrumental in shaping the language like a glove to match C features and interface with C libraries. Quote Link to comment Share on other sites More sharing options...
zbyti Posted April 25, 2021 Share Posted April 25, 2021 (edited) 1 hour ago, Kaj de Vos said: True, CC65 is the layer still inbetween, and that bugs me. Hence my talking about eventually cutting that out, too, in favour of a native Atari backend. "native Atari backend" from my observations (Mad Pascal, Millfork, Atalan) this is the place where REAL work begins Edited April 25, 2021 by zbyti Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 25, 2021 Author Share Posted April 25, 2021 In a way, that's true. It feels like cheating to generate C. On the other hand, C and the assembly syntax in CC65 have some nasty limitations that make it harder in some ways to generate C than to generate machine code. This is why most new languages these days generate LLVM intermediate code instead of C. Also, the real work begins in the preparation for generating machine code. My compiler is structured in a broad way like LLVM, with an intermediate code that is designed to absorb higher level REBOL-style code and to generate both mid-level code such as C and WebAssembly text format, and low-level code such as WebAssembly binary format, pseudo machine code and native machine code. I started by generating WebAssembly text format, because it is a modern, limited specification designed for this job. I thought I would just keep using one of the WebAssembly text to binary format compilers, because I didn't want to do all the work of many binary backends, which is greatly delaying the development of the Red language. But the WebAssembly compilers are already so big for this limited task, often written in Rust, that one day, I decided to do a binary WebAssembly backend, as a preparation for generating machine code. In the end, I was really glad that I did, because it wasn't at all as much work as it seems, and it helped shape the language further. Much of my design and planning is about doing this project quicker than other projects, or at least less glacial. It's also about bootstrapping my own empowerment, and it happens quite regularly that what I have already done enables me to take on a sub-project that I previously thought would be too hard or too much work. 1 Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 25, 2021 Author Share Posted April 25, 2021 Double rainbow Here is an improved version of the rainbow demo in mixed high-level language and assembly: https://language.meta.frl/examples/platforms/Atari/8-bit/RAINBOWM.XEX https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-mixed-assembly.list https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-mixed-assembly.labels https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-mixed-assembly.map unsafe!!! [ constant reference volatile byte! [ ; OS RTCLOK3= ~14 SDMCTL= ~022F ; ANTIC COLBK= ~D01A WSYNC= ~D40A VCOUNT ] SDMCTL: 0 ; Switch off display DMA forever [ LDA VCOUNT ASL-A CLC ADC RTCLOK3 STA WSYNC STA COLBK ] ] It generates the exact same code as the demo in the high-level language, that goes through generated C. So in this case, dropping down to hand-writing assembly yields no advantage. Quote Link to comment Share on other sites More sharing options...
Alfred Posted April 26, 2021 Share Posted April 26, 2021 10 hours ago, Kaj de Vos said: Much of my design and planning is about doing this project quicker than other projects, or at least less glacial. It's also about bootstrapping my own empowerment, and it happens quite regularly that what I have already done enables me to take on a sub-project that I previously thought would be too hard or too much work. Well that's an interesting approach, develop the language first and then the projects later. I'm doing the opposite, as imo it would take so long to implement the language the projects might never get done. If your compiler generates code as good as the above for more complex contructs, my interest in it would definitely sharpen. Good 6502 code generators are rare. Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 26, 2021 Author Share Posted April 26, 2021 I'm interleaving them. I have some projects in REBOL, some projects in Red, some old projects in C and Ruby, that I all want to port. I write in a simple style inspired by Atari and REBOL, so I always saw the similarities in these languages. Now and then I check what I need to implement to start a port. I'm starting very small and incrementally with command-line and Atari examples. The largest program until now is the CGI program that drives the project web server. Each program and each extension leads to the next round of language implementation. The Atari code is generated by CC65, so miracles should not be expected, but I did make a lot of effort to force it to generate better code. Essays written by people here were very helpful. When I implement an example, I inspect the code and try to get it as close as possible to what I would write in assembly by hand. CC65 doesn't do very well on complex constructs, that is for later to fix in a native Atari backend. But there are also a few constructs that can be avoided when programming, similar to the advice for writing C in CC65. Quote Link to comment Share on other sites More sharing options...
sanny Posted April 26, 2021 Share Posted April 26, 2021 2 hours ago, Kaj de Vos said: The Atari code is generated by CC65, so miracles should not be expected Me thinks your skills could be better used to improve the CC65 code generator instead of writing your own backend for your new language, which, honestly, probably will always stay a niche language. OTOH, improving CC65 would immediately benefit a lot people in the community. 1 Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 26, 2021 Author Share Posted April 26, 2021 Time will tell. From my point of view, spending my time on the CC65 code generator is a better guarantee to remain niche than making a programming language for all platforms. It's not for nothing that I am making a new language. I don't want to program in C anymore, apart from the C version of my language runtime, and almost haven't done so in a quarter century. Besides some mandatory exercises, I only ever wrote three C programs, an Atari emulator and two REBOL 3 plug-ins. If I remain the only one using my language, it will still be a success. It is solving my problems and gives me a great competitive advantage. On the other hand, if I make it popular, perhaps more people will become interested to work on the CC65 code generator behind it. 1 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted April 26, 2021 Share Posted April 26, 2021 On 4/5/2021 at 11:01 AM, MrFish said: Apparently OSS decided users didn't need all of Page 6, when they decided to take a chunk out for BASIC A+. Could have factored into the success of this DOS, or lack thereof... I should have said "this programming language", not "this DOS". I think I was momentarily mixing up BASIC A+ with OS/A+. 1 Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 27, 2021 Author Share Posted April 27, 2021 Triple rainbow Here is an improved version of the Rainbow demo in pure assembly: https://language.meta.frl/examples/platforms/Atari/8-bit/RAINBOWA.XEX https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-assembly.list https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-assembly.labels https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-assembly.map unsafe!!! [ constant reference volatile byte! [ ; OS RTCLOK3= ~14 SDMCTL= ~022F ; ANTIC COLBK= ~D01A WSYNC= ~D40A VCOUNT ] LDA 0 STA SDMCTL ; Switch off display DMA forever: LDA VCOUNT ASL-A CLC ADC RTCLOK3 STA WSYNC STA COLBK CLC BCC forever ] It is actually a byte larger than the versions in the high-level language and mixed assembly, because CC65 doesn't know that the assembly keeps looping, so it doesn't optimise away the RTS at the end of the generated main function. Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted April 28, 2021 Author Share Posted April 28, 2021 Over the rainbow I ported Rainbow to Atari 2600: It shows that the language is small enough to run on a machine with 128 bytes of RAM, and fast enough to "race the beam": to draw the television display scanline by scanline in real-time, 50 to 60 times per second, on an 8-bit CPU running slightly over 1 MHz. 3 Quote Link to comment Share on other sites More sharing options...
Kaj de Vos Posted June 8, 2021 Author Share Posted June 8, 2021 Since we're on page 7 now, in DOS territory, I wanted to make the first DOS tool, to show interaction with the system. But it turned out to be a dud for Atari. I have it working on my development Linux, but on Atari, getcwd () returns only an empty string. There is an Atari implementation, which does an XIO call, but it doesn't work. I tested on several SpartaDOSes and MyDOS. I don't know if this is a general issue in CC65 or only with the Atari code. Quote Link to comment Share on other sites More sharing options...
sanny Posted June 9, 2021 Share Posted June 9, 2021 (edited) On 6/8/2021 at 3:37 PM, Kaj de Vos said: Since we're on page 7 now, in DOS territory, I wanted to make the first DOS tool, to show interaction with the system. But it turned out to be a dud for Atari. I have it working on my development Linux, but on Atari, getcwd () returns only an empty string. There is an Atari implementation, which does an XIO call, but it doesn't work. I tested on several SpartaDOSes and MyDOS. I don't know if this is a general issue in CC65 or only with the Atari code. Works for me: $ cat tgetcwd.c #include <stdio.h> #include <unistd.h> #define BUFSZ 256 char pathbuf[BUFSZ]; int main(void) { char *s = getcwd(pathbuf, BUFSZ); if (! s) { perror("getcwd error: "); return 1; } puts(pathbuf); return 0; } $ $ cl65 -tatari tgetcwd.c -o TGETCWD.COM $ atari800.basic sdos33-test.atr Using Atari800 config file: /data/home/chris/.atari800.cfg Created by Atari 800 Emulator, Version 3.1.0 SpartaDOS Ver 3.2f 25-Feb-94 Copyright (C) 1994 by FTe D1:CWD TEST D1:?DIR >TEST D1:D1:>TGETCWD.COM >TEST D1: Edited June 9, 2021 by sanny forgot test program source code 1 Quote Link to comment Share on other sites More sharing options...
Alfred Posted June 10, 2021 Share Posted June 10, 2021 On 6/8/2021 at 9:37 AM, Kaj de Vos said: Since we're on page 7 now, in DOS territory, I wanted to make the first DOS tool, to show interaction with the system. But it turned out to be a dud for Atari. I have it working on my development Linux, but on Atari, getcwd () returns only an empty string. There is an Atari implementation, which does an XIO call, but it doesn't work. I tested on several SpartaDOSes and MyDOS. I don't know if this is a general issue in CC65 or only with the Atari code. Probably only SpartaDos 2.3 and higher support the concept of "current working directory". MyDos 4.3 has a default directory but I don't believe it's the same, you can't CD around to change it. I don't know about the OSS DOS products, they have a CLI but that might be as far as they go. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 10, 2021 Share Posted June 10, 2021 6 hours ago, Alfred said: MyDos 4.3 has a default directory but I don't believe it's the same, you can't CD around to change it. MYDOS's implementation is crazy. There is one default drive/path assigned to 'D:', so the moment you refer to a different drive number, you're back at the root. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.