meta A new language for the Atari

[Kaj de Vos]

Empty is just an empty program listing, and there are no compilation artifacts, because the new backend generates binary code immediately, without an intermediate assembly listing.

[Wrathchild]

So it's a specifically identified case or just a side effective of 'nothing to do'?

[Kaj de Vos]

If I understand you correctly, it's a side effect. I have a skeleton assembler implemented that can assemble some simple code and that generates the object formats for Atari or SpartaDOS X. The simplest example is, as before, Empty. In the SDX format without any code, in the Atari format the special case is that the RTS is always included for DOS compatibility.

[Kaj de Vos]

The native backend can now compile the assembly version of Rainbow:

https://language.meta.frl/examples/platforms/Atari/8-bit/RAINBOWA.XEX

 

 

In the internal data of the backend, this is what looks most like an assembler listing:

statements: [
    #{A900}
    #{8D2F02}
    forever
    #{AD0BD4}
    #0A
    #18
    #{6514}
    #{8D0AD4}
    #{8D1AD0}
    #18
    (#90 forever)
]

 

The CC65 version is now here:

https://language.meta.frl/examples/platforms/Atari/8-bit/CC65/RAINBOWA.XEX

 

 

The size went down from half a kilobyte in the CC65 version to 34 bytes in the native version. The assembler is now becoming suitable for things such as size-coding contests.

[Kaj de Vos]

Relocatable Rainbow

 

Here is Assembly Rainbow compiled for SpartaDOS X relocatable format:

 

https://language.meta.frl/examples/platforms/Atari/8-bit/SpartaDOS-X/RAINBOWA.COM

 

 

It comes in at 29 bytes. SDX loads it wherever MEMLO happens to be and runs it from there.

 

I believe this is the third or fourth assembler that supports SpartaDOS X, and the second cross-assembler.

[Kaj de Vos]

I have done some design work on having the native backend compile more of the language. It can now compile the mixed-assembly version of Rainbow:

https://language.meta.frl/examples/platforms/Atari/8-bit/RAINBOWM.XEX

Size is 34 bytes, as in the full assembly version.

 

I improved the internal data formats to be more semantic, more readable and more efficient. The backend now produces a simple listing from them:

https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-mixed-assembly.list

 

I moved the CC65 versions here:

https://language.meta.frl/examples/platforms/Atari/8-bit/CC65/RAINBOWM.XEX

https://language.meta.frl/examples/platforms/Atari/8-bit/CC65/rainbow-mixed-assembly.list

 

[Kaj de Vos]

Here is Mixed-Assembly Rainbow compiled to SpartaDOS X relocatable format:

 

https://language.meta.frl/examples/platforms/Atari/8-bit/SpartaDOS-X/RAINBOWM.COM

https://language.meta.frl/examples/platforms/Atari/8-bit/SpartaDOS-X/rainbow-mixed-assembly.list

 

[Kaj de Vos]

The native backend can now compile the full high-level version of Rainbow:

https://language.meta.frl/examples/platforms/Atari/8-bit/RAINBOW.XEX
https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow.list

 

Size is still 34 bytes, equal to the assembly version. This is still compared to half a kilobyte for the CC65 version.

 

The CC65 version is now here:

https://language.meta.frl/examples/platforms/Atari/8-bit/CC65/RAINBOW.XEX
https://language.meta.frl/examples/platforms/Atari/8-bit/CC65/rainbow.list

 

Compilation using the native backend is roughly around a third faster than using the CC65 backend. That is nice for now, but the real speedup will come when the compiler is eventually ported from REBOL to the language itself.

 

[Wrathchild]

I have to say your descriptions come across as super cryptic as I can't visualise the steps you take and so comparisons to cc65 are seeming more and more senseless. For me I cross compile/assemble and speed isn't an issue here and so when you say 'native' that doesn't appear to mean 'run on the atari' as would be done with the original but fairly defunct cc65.

 

My suggestion would be drop.the comparisons and focus on showcasing where/why people would use this language.

Edited July 10, 2021 by Wrathchild

[Kaj de Vos]

By native I mean that I target Atari directly, instead of cross-platform C. That means generating 6502 machine code and using the Atari OS instead of cross-platform C libraries. That way, the step of going through CC65 isn't needed.

 

This is a lot of extra work, just for the Atari platform, and as you say the performance when cross-compiling is not so important, so it is important to know why to make this effort. That's why it is important to me to measure the improvements.

 

For example, why people would need these improvements:

- I have mentioned before that I need to provide this as a network service, therefore compilation speed is significant for its scalability.

- A while earlier I mentioned that cutting out this overhead of CC65 makes the language suitable for size-coding contests.

- The first tool I published in the language, WHERE, is tiny but already 8 KB. This hurts loading times for this common DOS tool, and it looks like only small programs wil be possible with the CC65 backend.

- I can now generate native, relocatable SpartaDOS X programs.

[Kaj de Vos]

First compiled programming language for SpartaDOS X:

 

 

[ilmenit]

I agree with @Wrathchild here. Support for SpartaDOS X or native backend is hardly a selling point when the language currently is as presented in the post above:

Could you write some simple program using the language, like a Snake or Breakout clone to show off the language? Now you have a lot in your head that is not shared properly with the audience - we have close to zero idea of what you want to achieve.

[zbyti]

Yes, I agree. @Kaj de Vos one snake for you!

 

 

snake.xex snake.atl

 

or one of those https://github.com/tebe6502/Mad-Pascal/tree/master/samples/a8/games

Edited July 12, 2021 by zbyti

[Kaj de Vos]

I understand your frustration and share some of it. It would be nice if languages emerged fully formed, but they don't. They seemed to back in the day, when a magazine ad and article suddenly appeared, and you could buy it, but we didn't know what happened before and are still trying to reconstruct that here. ? These days, software is usually developed in the open on the Internet. A lot is needed, some things take longer than expected, other things happen faster than expected. It's a journey of invention.

 

This is a long-term project. I expect to be tied up with it for the rest of my life. Depending on how you count, I have been working on it for a decade or two, partly in the open, partly in classic private Atari mode. At some point, such a project needs to go public, and when is a hard decision. I could try to continue in private until everything anyone expects is there, but that is unrealistic. For better or worse, I decided on half a year ago. I got great feedback and help here, so I think it worked out well.

 

I have done public projects before. The planning is always a tug of war. Someone is always vocal about something they want. It is often hard to say whether that is of general importance or just a personal preference. There is always a danger of ignoring a silent majority. Sometimes you do a simple thing on the side and it turns out to excite the silent majority. Sometimes you accomplish something hard that hasn't been done before and you feel great about it, but people are not impressed.

 

I have been trying to address concerns voiced here. There was a concern that the Atari was too small for a modern cross-platform language, so it would be left behind. I implemented support for the 2600 to show that I mean to go even smaller. There were concerns that using CC65 would lead to poor code generation, so I investigated that, implemented many optimisations and eventually started on a native backend that some people asked for. A new backend doesn't emerge fully formed, either. I was asked about listings such as in the CC65 backend, so I implemented them. We came to discuss SpartaDOS X, and since I was a big fan of it, and always wanted to have relocatable drivers and programs, I really wanted to support it now that the native backend enabled it. I think it is pretty cool that SDX got its first language after 33 years, but apparently people disagree. On the other hand, there is a silent crowd downloading the demo. Someone asked for networking just after I published Hello World. That would indeed be nice, but it is really a number of steps farther out.

 

A programming language is a complex stack that builds upon itself. I understand that people don't have the insight into it that I have. I have a pipeline of examples and tools, including a simple game. Each example turns up a number of features that need to be implemented before it can work. I do them because I can't exactly foresee the requirements, either. After this requirements gathering, the order of implementation of the new features needs to be planned, because they have many dependencies. Sometimes the architecture of the whole system needs to be restructured to support a feature. In this early stage, these findings and restructurings are most important. Doing them early increases the future power of the system. Finding out late is costly, because more code needs to be changed. That is why I am going through small examples that do many different things.

 

The pipeline of unfinished examples is frustrating for me, too, but implementing and publishing them too early would lead to more confusion. I would have to keep changing the published examples as the language changes. There have been a few such cases, but only a few, and I want to keep it that way.

 

I have stated several times that the native backend is too much work to do now. I spent three weeks on it, anyway, because a functional assembler was doable. Having started on it, it was important to get the architecture right, so I continued with it until it could support compilation of the higher-level language. But this is where this sub-project ends for now. Since the SpartaDOS X support depends on it, there will only be an assembler for it and a small part of the language, a sort of macro assembler as I projected. Full language support is really for later.

 

Some planning decisions are inescapable because they depend on others. Some planning is important now because the first goal of the project is to get the language in your hands through a build server on the Internet. After this, the future is wide open. There are way too many possibilities to choose. That's why I will put a large part of the planning also in your hands, the part that has no blocking dependencies, through a crowd-funding system, not by being vocal, but by putting up donations. Where it can go is not that hard to find out, if you read the REBOL documentation that I linked to earlier.

[Kaj de Vos]

4 hours ago, ilmenit said:

Support for SpartaDOS X or native backend is hardly a selling point when the language currently is as presented in the post above

Do you by any chance mean this listing I posted:

statements: [
    #{A900}
    #{8D2F02}
    forever
    #{AD0BD4}
    #0A
    #18
    #{6514}
    #{8D0AD4}
    #{8D1AD0}
    #18
    (#90 forever)
]

This is not the language, it's a dump of the internal data as I mentioned, which I gave as a listing that Wrathchild asked for, and that I subsequently developed into the proper listings that I am posting now with every program.

[Wrathchild]

I'd actually meant more that the original (REBOL?) listings aren't included or linked to when you make these posts.

[Kaj de Vos]

When I post out of context in another sub-forum, I always include the link to the source code here. When I refer to a previous program here, I use its name, to avoid posting duplicate content. If it confuses you, I will include the cross-links here, too, in the future.

[ilmenit]

17 minutes ago, Kaj de Vos said:

When I post out of context in another sub-forum, I always include the link to the source code here. When I refer to a previous program here, I use its name, to avoid posting duplicate content. If it confuses you, I will include the cross-links here, too, in the future.

is this the newest source? https://language.meta.frl/examples/platforms/Atari/8-bit/SpartaDOS-X/rainbow.list

If yes, it's currently mostly the variant of 6502 assembler. Is there some code example written in the new language?

[danwinslow]

I may be wrong, but I believe that is better considered as embedded assembler inside control structures from his 'new language'. I think he is trying to write a high-level language rather than an actual assembler. I agree from that source that this isn't clear, I am going on posts he has written.

[Kaj de Vos]

No, that is the improved version of the assembler listing, similar to CC65's listings. The source code is in this thread, and I posted a link to it in the announcement:

 

The assembler listing is indeed 6502 code, because that is what the native backend produces. It's really quite like CC65, PL65 and other compilers. My language has an integrated 6502 assembler, so it was already included in the architecture. The simplest way to start a native backend was to support this assembler part of the language, because it can be compiled one-to-one. Additionally, you have to solve problems that CC65 and CA65 did before, such as selecting between absolute and zero-page versions of instructions, and resolving labels to where they end up in memory. Advanced forms of resolving compile-time expressions are already in the high-level language, so they could be used. The assembler also uses the type definitions, variable declarations and some of the type checking of the high-level language. It's not a classic assembler, it's partly a high-level one that is integrated into the language. The next step was to start compiling the high-level language to the same 6502 intermediate format that the assembler uses. Then another step is to make this architecture support relocatable code.

 

I modelled these requirements in several variants of the intermediate format. Compilation goes through stages in which each intermediate form is transformed into the next. The assembler listings are mostly a dump of several of these forms, but I made a lot of effort to make them readable.

 

If you read up on REBOL, and what I have been trying to explain in this thread, is that REBOL is a meta language that supports dialects of data and code. REBOL programs, the source code of my language, and all the intermediate formats in my compiler are all written or generated in the same meta notation. That's why the 6502 listings look similar to all the other forms. This is intended and a huge advantage.

[Wrathchild]

Here:

 

[danwinslow]

13 minutes ago, Kaj de Vos said:

No, that is the improved version of the assembler listing, similar to CC65's listings. The source code is in this thread, and I posted a link to it in the announcement:

 

 

 

 

Ok, fine...why are are you designing an assembler-level output so different from anything else? It appears to have REBOL-like control structures in it. This is what confused me. You further state that 'this is a huge advantage'. Why is it a huge advantage?

 

And after having read through the referenced post to figure out what you're citing, I assume you mean this is the 'output listing' from compiling this:

unsafe!!! constant reference volatile byte! [
    ; OS

    RTCLOK3= ~14

    ; ANTIC

    COLPF2=  ~D018
    WSYNC=   ~D40A
    VCOUNT   ; ~D40B
]

forever [COLPF2: WSYNC: overflow VCOUNT + RTCLOK3 << 1]

 

 

Edited July 12, 2021 by danwinslow

[Kaj de Vos]

I explained it right there. Everything you see is REBOL, even if it is my language or 6502 code. A language compiler is an engine that transforms forms into other forms through intermediate forms. This is what REBOL was designed for. This guides the implementation. There is no point in shoehorning it into forms others use, unless you are targeting them such as I did with CC65. And I made an attempt to give the assembler listings similar content as those produced by other compilers.

[Kaj de Vos]

33 minutes ago, danwinslow said:

And after having read through the referenced post to figure out what you're citing, I assume you mean this is the 'output listing' from compiling this

Yes, just like the CC65 listings, that I post side by side.

[Kaj de Vos]

35 minutes ago, danwinslow said:

Ok, fine...why are are you designing an assembler-level output so different from anything else? It appears to have REBOL-like control structures in it. This is what confused me. You further state that 'this is a huge advantage'. Why is it a huge advantage?

It gets messy with edited posts, but here goes: it's a huge advantage because basically, only one format is needed, the REBOL meta notation, and only one engine to manipulate it, REBOL. For example, when Wrathchild asked for listings, initially the only thing I needed to do to generate one was:

?? statements

This was really an internal format, so subsequently I used REBOL techniques to make this format both more readable and more capable of generating the next format I needed in the chain.

 

This is why REBOL and REBOL programs are so much less complex and smaller than other languages and frameworks. Just one meta format, just one engine. I wrote a native 6502 assembler in a week, a 6502 code generator for my high-level language in another week, and the first language for SpartaDOS X in the third week.