Jump to content

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by zbyti
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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+.

 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

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 by sanny
forgot test program source code
  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

  • Haha 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...