Original developer tool set - Alcyon C compiler and assembler

[rcgldr]

I may have a working copy of this on one of my floppies, but currently I don't have any working double sided floppy drives.

 

update - Fortunately I had formatted one of my developer boot floppies to be PC compatible, and was able to back it up on a PC.

Edited June 7, 2018 by rcgldr

[rcgldr]

Ran out of time trying to edit my original post.

 

I had a few boot floppies I made from the Atari ST developer tool set (I was doing consulting work for an Atari ST developer), and fortunately for me, one of them was formatted to be PC compatible, so I now have the tool set backed up on a PC, and I made a new Atari floppy. I don't have a working double sided drive for the Atari ST, but I may purchase one later.

 

Later Atari switched to a different compiler for it's developer tool set, but I recall that the code generated by the Alcyon compiler was smaller and faster than the other compiler (don't recall what the other compiler was).

 

Has anyone else here used the Alcyon compiler? If so what was your opinion of it versus the other compilers for Atari ST?

[ijor]

Hmm. I'm not sure it was like that. The Alcyon compiler didn't produce very optimized code. You can tell just by looking at the earlier versions of TOS. Let alone that the Alcyon toolset was extremely primitive and awfully slow to compile.

 

I didn't use Alycon too much. Initially I didn't have a hard disk, and compiling from floppies with Alycon was unbearable. I mostly used Megamax tools, much more user friendly, let alone from floppies. Megamax compiler produced faster and more compact code. But the compiler provided by later version of the Atari Developer Kit was Mark Williams C. I didn't use MWC much either. Eventually Lattice C become the most popular compiler for the Atari ST.

 

There was also Turbo C, a port of Borland compiler for the PC. But was released only on Germany?

 

In anycase, you can find several versions on: https://www.dev-docs.org/docs/

[rcgldr]

The development kit I bought included a 520ST upgraded to 1MB, with the intent of using the extra memory as a ramdisk, which sped up builds on a floppy only system. I have multiple copies of "development" floppies, but I only formatted one of them to be PC compatible, and that is the only one I can read (on a PC), as I don't have a working double sided floppy drive for the Atari yet (I'm ordering one, but it will take a while).

[ParanoidLittleMan]

Thorsten Otto worked on reconstructing 100% exact TOS 2.06/3.06 from available sources. So, he needed original Alcyon compiler for it.

Look discussion here: http://www.atari-forum.com/viewtopic.php?t=31243&start=75

 

But I agree with Ijor - and dare to say that everyone would agree that using that prehistoric compiler now .... eh . My opinion is that it was not much good, as it is with any tool done by DRI .

 

Here is my tool, with which you can access any Atari floppy on PC with internal floppy drive. Making images, extracting, adding files:

http://atari.8bitchip.info/floimgd.php

[rcgldr]

Thanks for the tool. What I have been doing instead is formatting floppies that are PC compatible, since both Atari ST and PC can read those.

[landondyer]

The Alcyon compiler didn't produce very optimized code. You can tell just by looking at the earlier versions of TOS.

 

Boy howdy, you can say that again. One of the build steps for the ST ROMs was a peephole optimizer I wrote . . . in sed. One pass of a relatively stupid script (100-200 lines IIRC) trimmed the code by over 5%, closer to 10%. Credit where credit is due: I got the basic idea from the build scripts of 4.2bsd for the Vax 11/780 -- the compiler there wasn't all that bright, either.

 

I think the script found redundant loads and other quite local things, like replacing ADD.W with ADDQ.W. This may have been where we did the "line F" compression hack as well (which let us turn a six-byte absolute mode function call into a 2-byte trap, at some cost in execution speed).

 

There are a bunch of other tricks you can play if you've got intermediate assembly language available for a whole ROM, like collapsing common tails of functions, and identifying "nearly identical" functions for rewriting by humans.

[ParanoidLittleMan]

When talking about reducing TOS in ROM code size, I can say many things about. Here are some things described: http://atari.8bitchip.info/stTOShist.html

When reassembling TOS 1.04 completely unchanged you can get some 7 KB shorter code only by using simple optimizations in Devpac - short absolute addressing + movea.w instead movea.l - when possible.

That self would be enough to make it fit in 192 KB without using Line-F trick (what save about 7 KB by my calculations. But there is much better thing: 2 RSCs (Desktop and AES) and Desktop.inf template at ROM end are just copied straight in RAM, and all further access is in RAM - sure, because some values, txt changes in them. Funny thing is that no one came to idea to use packing there (1989 !) - with even low efficient one it would save about 8 KB . This stays for 1.04 and 1.06/162 - which are practically same. And I guess for older versions too. Things are little better in 2.06 - no packing, but static parts stay in ROM.

So, in case of 1.04 it was possible to save about 15 KB TOS ROM space with simple measures, and that's some 8% of whole size. Really good compiler could save even more, I guess. We could even have answer on this question if compiling what is available with something better - TOS 2.06 sources. But it will need some time to make that mess usable with other toolchain than what Otto used.

Of course, I have feeling again that I will be who need to do all it

[ijor]

 

Boy howdy, you can say that again. One of the build steps for the ST ROMs was a peephole optimizer I wrote . . . in sed. One pass of a relatively stupid script (100-200 lines IIRC) trimmed the code by over 5%, closer to 10%. Credit where credit is due: I got the basic idea from the build scripts of 4.2bsd for the Vax 11/780 -- the compiler there wasn't all that bright, either.

...

There are a bunch of other tricks you can play if you've got intermediate assembly language available for a whole ROM, like collapsing common tails of functions, and identifying "nearly identical" functions for rewriting by humans.

 

Good to know, and nice job with the optimizer. But obviously it is rather limited what you can do with a script. As Pera is saying, a good assembler should be able to perform quite some optimization automatically. With multiple passes it is possible to replace forward branches with short branches, and use PC relative addressing whenever possible.

 

The most efficient optimization must be performed by the compiler itself. It took quite some time until native ST compilers performed decent optimization.

 

[kimchipenguin]

Hmm. I'm not sure it was like that. The Alcyon compiler didn't produce very optimized code. You can tell just by looking at the earlier versions of TOS. Let alone that the Alcyon toolset was extremely primitive and awfully slow to compile.

 

I didn't use Alycon too much. Initially I didn't have a hard disk, and compiling from floppies with Alycon was unbearable. I mostly used Megamax tools, much more user friendly, let alone from floppies. Megamax compiler produced faster and more compact code. But the compiler provided by later version of the Atari Developer Kit was Mark Williams C. I didn't use MWC much either. Eventually Lattice C become the most popular compiler for the Atari ST.

 

There was also Turbo C, a port of Borland compiler for the PC. But was released only on Germany?

 

In anycase, you can find several versions on: https://www.dev-docs.org/docs/

 

Turbo C/Pure C was by far the most popular C compiler in Germany, which meant great support by various GEM libraries.

 

It's unfortunate that the sources for Milan TOS aren't available. Milan claimed in 1999 that they recompiled TOS 4.x with a more modern compiler.