TOS 2.06 improving - task for good C coder

News,announcements,programming,fixes,game patches & discussions.

Moderator: troed

mfro
Posts: 10
Joined: Thu Dec 13, 2018 7:32 am

Re: TOS 2.06 improving - task for good C coder

Post by mfro » Fri Dec 14, 2018 11:44 am

terriblefire wrote:
Fri Dec 14, 2018 10:33 am
... The last time i looked bits of EmuTOS were compiled with this toolchain ...
Personally, I'm following EmuTOS development for years now (even contributed one thing or the other over time myself) and I think you are mistaken. Must be something else.

No version of EmuTOS (that I know) ever used any part of vbcc.
And remember: Beethoven wrote his first symphony in C.

BlankVector
Posts: 40
Joined: Fri Sep 15, 2017 10:51 pm

Re: TOS 2.06 improving - task for good C coder

Post by BlankVector » Fri Dec 14, 2018 3:57 pm

terriblefire wrote:
Fri Dec 14, 2018 10:33 am
Fair enough. There is nothing Amiga specific about vbcc. Its just a compiler that sits on top of vasm. The last time i looked bits of EmuTOS were compiled with this toolchain.
Do you mean that EmuTOS was compiled with vbcc? If this is what you mean, you are mistaken. I don't know any version of EmuTOS compiled with vbcc, I'm even convinced that it couldn't work because EmuTOS sources contain many GCC extensions.

I've been working on EmuTOS for almost 10 years, and the official compiler has always been the m68k-atari-mint-gcc cross-compiler.
terriblefire wrote:
Fri Dec 14, 2018 10:33 am
GCC produces horrible code for me.
Generally, GCC produces very efficient code. There are some cases where GCC produces sub-optimal code, but they are special cases, not the general cases. Be sure to compile with "-O2 -fomit-frame-pointer" for standard optimization.
If you have a concrete example of bad code generated by GCC, then feel free to publish it (but please do that in another topic to avoid out-of-topics in this one).
Subscribe to my Vretrocomputing channel on YouTube and Facebook.

terriblefire
Moderator Team
Moderator Team
Posts: 370
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TOS 2.06 improving - task for good C coder

Post by terriblefire » Fri Dec 14, 2018 4:13 pm

BlankVector wrote:
Fri Dec 14, 2018 3:57 pm
Do you mean that EmuTOS was compiled with vbcc? If this is what you mean, you are mistaken.
No i thought that the low level of EmuTOS was once upon a time linked with vlink. Thats why i said "toolchain" not "compiler". I cant remember why i thought that. I used to help vincent with the debian development environment (building the debs) once upon a time. I've also contributed to EmuTOS. But that was many moons ago now. It seems that i'm wrong.

EDIT: This may have something to do with why i thought what I thought.. i guess it never happened https://sourceforge.net/p/emutos/mailma ... /30140563/

BlankVector
Posts: 40
Joined: Fri Sep 15, 2017 10:51 pm

Re: TOS 2.06 improving - task for good C coder

Post by BlankVector » Fri Dec 14, 2018 6:10 pm

terriblefire wrote:
Fri Dec 14, 2018 4:13 pm
EDIT: This may have something to do with why i thought what I thought.. i guess it never happened
Ah, that makes sense. This was just a suggestion about how it could be done. But AFAIK, that never happened (pointless).

But for memories, long ago Henk Robbers managed to compile EmuTOS with AHCC, after some source modifications (I don't remember having seen those modified sources). Quite a feat, if you want my 2 cents. This was a good testcase for his C compiler :)
Subscribe to my Vretrocomputing channel on YouTube and Facebook.

terriblefire
Moderator Team
Moderator Team
Posts: 370
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TOS 2.06 improving - task for good C coder

Post by terriblefire » Sat Dec 15, 2018 8:39 am

I've had a think and i'll try and write down why I am not keen on GCC.

It mostly comes from the performance of AROS. AROS uses GCC and compared to the original Kickstart is much slower (and fatter). It may be unfair to point the finger entirely at GCC for this but GCC is what seems to get the blame when i read explanations of the performance. I guess i shouldnt believe everything i read though.

On the other hand EmuTOS performs very well but is also a little fatter than the original.

I guess a properly measured explanation for AROS performance on 68K would make me feel better about GCC. I know this is not about Amiga but ignoring the mistakes of others leaves you doomed to repeat them perhaps.

Anyways I only replied to this thread because I got a request to moderate some posts on here and thought I'd mention VBCC.. since its available for multiple platforms and is very lightweight.

mfro
Posts: 10
Joined: Thu Dec 13, 2018 7:32 am

Re: TOS 2.06 improving - task for good C coder

Post by mfro » Sat Dec 15, 2018 10:39 am

terriblefire wrote:
Sat Dec 15, 2018 8:39 am
It mostly comes from the performance of AROS. AROS uses GCC and compared to the original Kickstart is much slower (and fatter). It may be unfair to point the finger entirely at GCC for this but GCC is what seems to get the blame when i read explanations of the performance. I guess i shouldnt believe everything i read though.
I don't really know, but last time I have looked at it, the Amiga gcc compilers were overly aged. Do you know which gcc toolchain versions are available for the Amiga nowadays? gcc got a lot better regarding code quality over time (admittedly also regarding resource requirements) and still improves with new releases. There is even a measurable improvement from gcc 7.x to 8.x although probably noone cares about the m68k backend anymore.
terriblefire wrote:
Sat Dec 15, 2018 8:39 am
On the other hand EmuTOS performs very well but is also a little fatter than the original.
Not sure if you can compare EmuTOS to TOS for the judgement of compiler code quality or code density. TOS was built with what I consider one of the worst C compilers ever (Alcyon C) that forced the development team to replace many routines with optimized assembler. Not just because lack of speed and ROM space shortage, but also for lack of accuracy to work around compiler bugs and deficiencies (it couldn't even cope with unsigned ints).

EmuTOS development, OTOH, built with a modern compiler, keeps a strong focus on C code cleanlyness and accuracy (which I very much appreciate). Also, the overall assembler code share is probably a lot less than in TOS. Not to mention functionality (like internal hard disk drivers and DOS partition/FS support) that original TOS doesn't have.
And remember: Beethoven wrote his first symphony in C.

ijor
Posts: 64
Joined: Fri Nov 30, 2018 8:45 pm

Re: TOS 2.06 improving - task for good C coder

Post by ijor » Sat Dec 15, 2018 12:14 pm

mfro wrote:
Sat Dec 15, 2018 10:39 am
Not sure if you can compare EmuTOS to TOS for the judgement of compiler code quality or code density. TOS was built with what I consider one of the worst C compilers ever (Alcyon C) that forced the development team to replace many routines with optimized assembler. Not just because lack of speed and ROM space shortage, but also for lack of accuracy to work around compiler bugs and deficiencies (it couldn't even cope with unsigned ints).
You don't like Alcyon C? Really? :)

Recently there was a thread at Atariage about TOS and Alycon toolchain. A former Atari employee commented about how they had to develop some scripts to introduce some optimizations by brute force. That was besides the usage of LINE-A and LINE-F
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

czietz
Posts: 71
Joined: Sun Jan 14, 2018 1:02 pm

Re: TOS 2.06 improving - task for good C coder

Post by czietz » Sat Dec 15, 2018 4:28 pm

You can testdrive different C compilers for m68k under http://brownbot.mooo.com/. Even for the trivial sample that I wrote for you here http://brownbot.mooo.com/z/7sM69l, gcc generated code runs in circles around vbcc generated code.

Sample code:

Code: Select all

unsigned long squarediv(unsigned short x)
{
    return ((unsigned long)x/3) * ((unsigned long)x/3);
}
GCC 8.2 -O2 -m68000:

Code: Select all

squarediv:
        move.w 6(%sp),%d0
        mulu.w #43691,%d0
        clr.w %d0
        swap %d0
        lsr.w #1,%d0
        mulu.w %d0,%d0
        rts
vbcc 0.9f -O2:

Code: Select all

_squarediv
        movem.l l3,-(a7)
        moveq   #0,d0
        move.w  (6+l5,a7),d0
        move.l  #3,-(a7)
        move.l  d0,-(a7)
        public  __ldivu
        jsr     __ldivu
        addq.w  #8,a7
        move.l  d0,d1
        move.l  d0,d2
        move.l  d1,d3
        swap    d2
        swap    d3
        mulu.w  d1,d2
        mulu.w  d0,d3
        mulu.w  d1,d0
        add.w   d3,d2
        swap    d2
        clr.w   d2
        add.l   d2,d0
l3      reg d2/d3
        movem.l (a7)+,d2/d3
l5      equ 8
        rts

terriblefire
Moderator Team
Moderator Team
Posts: 370
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TOS 2.06 improving - task for good C coder

Post by terriblefire » Sat Dec 15, 2018 8:54 pm

Thats interesting. I havent used GCC much beyond 4.9. Even when I did C and C++ commercially we only moved to 5.x in 2016 and I've not been using GCC since. I guess it has improved dramatically in recent years. Thanks for the example.

User avatar
exxos
Site Admin
Site Admin
Posts: 5413
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: TOS 2.06 improving - task for good C coder

Post by exxos » Sun Dec 16, 2018 1:24 am

I didn't realise there was even so much difference between compilers. I'm pretty clueless with this stuff... But is this why emutos is a fair bit slower than tos ? I'm not knocking emutos here, just after the talks here, makes me wonder how DRI /emutos code seems to lack things like the grow and shrink boxes, so should run faster than tos ? Basically less code in drawing items but emutos runs slower .

How much did Atari improve the code ? How much of a factor was the compiler ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

Post Reply