More bad about Alcyon compiler

[ParanoidLittleMan]

Accidentally spotted some another inefficient code in TOS 1.04 .

On  multiple places there is something like : 

move.l  d0,d5

tst.l  d5

Well, everyone little better familiar with 68000 knows that move to data register sets flags too, depending on value of data. So, no need for tst instruction. And I wondered how some game programmers did not know it ... 1.04 is from 1989, so they had time to know CPU better. But it looks that Alcyon C compiler by DRI was not developed, improved over some 4 years, or more ?

[damosan]

How long did folks use the Alcyon compiler in anger?  I suspect folks dumped it the minute better compilers became available - I remember using Haba Hippo-C and Megamax C in 86/87.

 

 

[ParanoidLittleMan]

Obviously Atari and DRI programmers used it. Even if maybe some of them were aware that better ones are available.

[landondyer]

On 2/27/2021 at 3:15 AM, ParanoidLittleMan said:

Accidentally spotted some another inefficient code in TOS 1.04 .

On  multiple places there is something like : 

move.l  d0,d5

tst.l  d5

Well, everyone little better familiar with 68000 knows that move to data register sets flags too, depending on value of data. So, no need for tst instruction. And I wondered how some game programmers did not know it ... 1.04 is from 1989, so they had time to know CPU better. But it looks that Alcyon C compiler by DRI was not developed, improved over some 4 years, or more ?

 

That's likely my fault. The output of the Alcyon C compiler was really, really terrible.

 

I wrote a peephole optimizer using the Unix tool sed(1), using something similar that the 4.2 bsd folks did on the Vax as inspiration (the Vax compiler was also terrible). The script just looked for really easy patterns in the Alcyon compiler's intermediate assembly to collapse into smaller code sequences. I think it reduced the original ROM size by about ten percent.

 

The ROMs went final in May 1985; I think we spent 2-3 weeks towards the end, crunching out bytes to get the code to under 192K. We were well over 210K at one point. No worries, nearly everyone on the Atari software team knew how to make code smaller for ROMs, most of us were game programmers, after all.

[Cyprian]

I wonder why Atari didn't switch to 256kB ROM in 1985/86, in order to avoid fighting with every byte over the 192kB limit.

16 hours ago, landondyer said:

 

That's likely my fault. The output of the Alcyon C compiler was really, really terrible.

 

I wrote a peephole optimizer using the Unix tool sed(1), using something similar that the 4.2 bsd folks did on the Vax as inspiration (the Vax compiler was also terrible). The script just looked for really easy patterns in the Alcyon compiler's intermediate assembly to collapse into smaller code sequences. I think it reduced the original ROM size by about ten percent.

 

The ROMs went final in May 1985; I think we spent 2-3 weeks towards the end, crunching out bytes to get the code to under 192K. We were well over 210K at one point. No worries, nearly everyone on the Atari software team knew how to make code smaller for ROMs, most of us were game programmers, after all.

Really interesting.

It would be nice to read more about such Atari Corp stories.

Edited February 10, 2022 by Cyprian

[ijor]

18 hours ago, landondyer said:

I wrote a peephole optimizer using the Unix tool sed(1), using something similar that the 4.2 bsd folks did on the Vax as inspiration (the Vax compiler was also terrible). The script just looked for really easy patterns in the Alcyon compiler's intermediate assembly to collapse into smaller code sequences. I think it reduced the original ROM size by about ten percent.

 

The ROMs went final in May 1985; I think we spent 2-3 weeks towards the end, crunching out bytes to get the code to under 192K. We were well over 210K at one point. No worries, nearly everyone on the Atari software team knew how to make code smaller for ROMs, most of us were game programmers, after all.

 

Always very interesting to hear your insider knowledge. Thank you. A couple of questions

 

How the replacement with the LINE-F shortcut was implemented? That was also part of your optimizer?

Do you still happen to have any original source code?

 

Lastly, you might be interesting to see an excellent effort to reverse engineer TOS to C sources (not just disassemble):

https://www.atari-forum.com/viewtopic.php?t=41354

[ParanoidLittleMan]

20 hours ago, Cyprian said:

I wonder why Atari didn't switch to 256kB ROM in 1985/86, in order to avoid fighting with every byte over the 192kB limit.

Really interesting.

It would be nice to read more about such Atari Corp stories.

I think that answer on this is simple. ROM/EPROM prices were such then, that it was cheaper to go on 6x 32 KB instead 2x128 KB solution. And of course, there was factor of not good prediction about how much space final 1.00 TOS in ROM will need.

By me real mistake was selecting $FC0000 for TOS ROM start - it self limited space to 192 KB, and result of it was need to change TOS ROM space start to $E00000 by STE, TT few years later. And then could even add extra space for cartridge ...

[ParanoidLittleMan]

On 2/9/2022 at 9:17 PM, landondyer said:

 

That's likely my fault. The output of the Alcyon C compiler was really, really terrible.

 

I wrote a peephole optimizer using the Unix tool sed(1), using something similar that the 4.2 bsd folks did on the Vax as inspiration (the Vax compiler was also terrible). The script just looked for really easy patterns in the Alcyon compiler's intermediate assembly to collapse into smaller code sequences. I think it reduced the original ROM size by about ten percent.

 

The ROMs went final in May 1985; I think we spent 2-3 weeks towards the end, crunching out bytes to get the code to under 192K. We were well over 210K at one point. No worries, nearly everyone on the Atari software team knew how to make code smaller for ROMs, most of us were game programmers, after all.

Not familiar with 'peephole optimizer' - but it looks like something what just can change existing C-compiler generated code to shorter one in specific cases (easy patterns) .  But it was not enough, and then needed to use so called Line-F solution, what is in fact special way of performing subrutine call with only 2 byte code (instead mostly 4 or 6 byte, usually needed). And passing parameters was solved shorter too. 

It is easy to see gain (how much less bytes) if compare AES of TOS 1.04 and 1.06/1.62 (which are practically same), only that in case of 1.06/1.62 was no need for Line-F because ROM space raised to 256 KB .

 

Well, it is always easier to be smarter after some time, and when not in rush, need to finish something until specific deadline. And of course factor of experience with specific CPU ASM coding matters too. Surely 68000 needs much more time than some 8-bit CPU.

 

I made disassembling of TOS 1.04 long time ago, in 2010. It took weeks. And was not complete. Some parts had constants for displacements between code parts instead labels - that was OK until did not change something between - like code optimization, because then displacement changes.

And yes, I went in optimization in 2018 - when decided to rewrite FAT16 of TOS to real FAT16 (what does not need to use so called long sectors) - to get more efficient and compatible, DOS type FAT16. And that needed some extra space. So, I used optimization in Devpac 3 assembler. Like Absolute addresses to short form, ADDA/SUBA to LEA, ASS/SUB to ADDQ/SUBQ, LEA to ADDQ/SUBQ, MOVEA.L to MOVEA.W, MOVE.L to MOVEQ .

And it reduced length for some 6 KB . Good start.  But I needed/wanted more extra space, so looked how can save more. And there is it:

At the end of AES part is longer RSC section - containing AES RSC, Desktop RSC and Desktop.inf template. And it is of course well packable . TOS 1.xx just copies that whole part in RAM, because most of it must be in RAM, since there are writes in it. I wonder how nobody came to idea to pack it for ROM, and then just depack in RAM, when AES is initialized.  That's why I did, and it saved about 10 KB !  Using my simple and not much efficient packer.

Here to add that is possible to save some RAM space too - if copying to RAM only parts which may change - and that was done in TOS 2.06, btw.

 

To not blame only Atari and DR, here is recent finding:  in MagiC 6.20 I saw that they used movem.l a6,-(sp) - so for only 1 register, when simple move does same, with shorter code. And it was more than 10 years later than TOS 1.00 .

 

 

 

[ParanoidLittleMan]

19 hours ago, ijor said:

...

Lastly, you might be interesting to see an excellent effort to reverse engineer TOS to C sources (not just disassemble):

https://www.atari-forum.com/viewtopic.php?t=41354

I saw that about month ago. Not sure how much of C source is original, how much is 'reconstructed' - because there are some parts available over 10 years - like TOS FAT16 filesystem C sources - not specifically for some TOS version.  Some things changed for sure in it too between 1.00 and 1.04 - as we know 1.00-1.02 have max partition size of 256 instead 512 KB. And it is in fact result of that max cluster count is only 16382 , while on 1.04 and later is 32766. But it is still not real FAT16 - because 2 POW 16 is 65536, so max cluster count in real FAT16 is 65534 (2 less as usual) .

 

Maybe the real question is: why they did not go on doing whole TOS in ASM ? Well, not realistic for 1.00, but until 1.04 there were 4 years. What should be enough for it, for sure.   My experience says that some would not like it. The same people who claim that FAT16 filesystem coding in ASM is not really possible. Well, it looks that DR people was such too. That's just stupid way of favourising C . OK, but then, why not working on making C compiler better ?

 

Back to C 'sources' - that's nice to make it possible to recompile whole thing now, some 35 years later. But what is benefit of it ?  Then, is there simple way to use some modern C Compiler on it, without need for changing plenty of it in C sources ?  That would give answer about how much shorter and faster code could get. And about by me multiple times mentioned bad work with unsigned integers of Alcyon.

[mikro]

On 2/11/2022 at 11:21 AM, ParanoidLittleMan said:

Back to C 'sources' - that's nice to make it possible to recompile whole thing now, some 35 years later. But what is benefit of it ?  Then, is there simple way to use some modern C Compiler on it, without need for changing plenty of it in C sources ?

I'm an important milestone. Now anyone can take the source code and experiment on them. For instance as you mention, you can now take a modern compiler and throw the source on it, without a fear that the source code may be in some broken state (so if something breaks, it is because of different calling convention, saving registers etc -- so you roughly know where to look). I'm really curious what people will do about it. Btw Thorsten has made MagiC source-compilable, too, so no need to patch binaries again.

[ParanoidLittleMan]

I wrote it because Thorsten's previous TOS sources - 3.06, 2.06 needed to be compiled with Alcyon, as I understood. And there was talk about need for changes in sources so can compile with some modern one.  Would be good to know has anyone done it, and as mentioned above we can then see improvement.  So, if anyone knows about such thing, pls. give us link about it - thread, WEBpage ...

 

[IGS GUY]

I'm no where near as advanced programmers as you are.  I did notice in this one Instant Graphics! script that in TOS 1.0 it executed 20 seconds faster than in TOS 1.04 and some other TOS I tried in Hatari, I think 2.06.   I am retro coding just for fun on my old project.  Always a big Atari fan.  Same script on my Falcon 030 executes visibly faster,  I'm figuring it's because CPU twice as fast.

 

[ParanoidLittleMan]

15 hours ago, IGS GUY said:

I'm no where near as advanced programmers as you are.  I did notice in this one Instant Graphics! script that in TOS 1.0 it executed 20 seconds faster than in TOS 1.04 and some other TOS I tried in Hatari, I think 2.06.   I am retro coding just for fun on my old project.  Always a big Atari fan.  Same script on my Falcon 030 executes visibly faster,  I'm figuring it's because CPU twice as fast.

 

What script ? You wrote "this one ...". So, where is it ?  Sounds strange that executes faster in TOS 1.00 ... And better would be to mention %-al speed change instead seconds.  And not sure that Hatari is best 'platform' for speed tests.  

Falcon CPU is more than 2x faster. There are instructions which execute in less cycles.

[IGS GUY]

I attached a ST disk with the last official release of IG217.ACC  Just run the ACC press F8 type in the path to EARCH.IGS runs in ST MONO  run it under TOS 1.00 and under TOS 1.04 Runs slower with TOS 1.04 while it's drawing the elliptical arcs.  I don't really know why, maybe the compilers fault.

DEFBULT.ST