tool First DOS tool in new programming language

[Kaj de Vos]

Got it working and tested on all above DOS'es. I uploaded a new program and CC65 patch.

 

CC65 has a limited concept of the default device. It expects a drive under the "D:" handler. If your command interpreter is on an "H:" device or a FujiNet network device, for example, it still won't work as expected. For now, this is as good as it gets, I'm afraid.

[sanny]

> CC65 has a limited concept of the default device. It expects a drive under the "D:" handler. If your command interpreter is on an "H:" device or a FujiNet network device, for example, it still won't work as expected.

 

I know. It's on my TODO list. Also, SpartaDOS devices which have the colon after the third character aren't recognized.

[Kaj de Vos]

Ah, cool. I was indeed wondering about SDX devices.

[Kaj de Vos]

I posted the program code here:

 

[Kaj de Vos]

So WHERE, indeed, do we stand, after a year in this project and half a year on this forum?

 

This tiny tool, that should have been trivial, turned out to be a matryoshka of cans of worms, that took an exorbitant amount of effort and time. I think it drives home the point that it is way too hard for programmers to write programs that work well across popular Atari DOS'es, let alone all Atari DOS'es or even all computer platforms. My language will make that much easier, but it takes a large effort to get there.

 

I also think this must be close to the worst case for program size. The program source is only a few lines and some help text, but the binary program is almost 8 KB. The program pulls in some basic parts of the language runtime, which pull in substantial parts of the CC65 runtime. In larger programs, these parts are likely to be reused more, so hopefully the programs will grow more slowly.

 

Still, it forecasts a rather low limit on program size, so I have started adding a native Atari backend that doesn't use CC65:

https://atariage.com/forums/topic/315558-a-new-language-for-the-atari/page/8/?tab=comments#comment-4852627

 

This is also needed to generate native, relocatable SpartaDOS X programs, which CC65 doesn't do. The work is in an early stage, but the initial results are encouraging. I think I will eventually be able to generate much leaner programs.

 

Compared to assembly, 8 KB for this functionality is laughable. Then again, the functionality provided is significant. It would take a similarly large effort to replicate in assembly, and while the binary program would be tiny, the program source code would be laughably big compared to the high-level language. Not to forget it would be utterly non-portable.

 

The situation is much better for the hardware programming demos I published. They use much less of the runtime, and my language forces CC65 to generate fairly good code. Sometimes it's identical to hand-written assembly code, sometimes it's between 50 and 100 percent larger.

 

The CC65 backend is okay for native hardware programming, but has considerable overhead for systems interfacing. This is in part because C is not designed for 8-bit systems, and because the standard C library needs to provide a cross-platform abstraction that is also often a mismatch.

 

This distinction is relevant compared to the current standard in Atari BASIC's, FastBasic. Its runtime is said to be 3 KB. I suppose it's fairly constant because it's a pseudo-code interpreter with a limited number of data types. In contrast, the runtime overhead of my language varies a lot with the type of program, because it has a large number of specialised data types with supporting runtime functions that it compiles in selectively.

 

Compared to where compiled for my 64-bit Linux system, the Atari 8-bit version is only half the size. This is with Linux where stripped, and CC65 having to compile in the needed parts of the C library, while the Linux version doesn't include the C library, because it is able to link with it dynamically, and is heavily optimised by the modern C compiler. Of course, Linux has some overhead due to the 64-bit instruction set, but this is such a small program, that it shows how much overhead modern toolchains inject into programs.

 

Compared to the pwd on my 64-bit Linux system, from GNU CoreUtils, Linux where is only 40% of the size. This while GNU pwd is written in C, supposedly the most efficient cross-platform programming language. Still, my high-level language does pretty well here. GNU pwd contains some bizarre stuff that is very far removed from its core functionality. This is a general symptom of software today. Because programming languages aren't powerful enough, it has become customary to pull in layers upon layers of framework libraries into every program.

 

I think we have another matryoshka here. ?Let's peel it off.

 

Concluding, I think what I am making is the highest-level language that can produce usable and potentially cross-platform Atari 8-bit programs, and that's exactly what I wanted.