TOS 2.06 improving - task for good C coder

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

Moderator: troed

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

Re: TOS 2.06 improving - task for good C coder

Post by czietz » Sun Dec 16, 2018 10:13 am

exxos wrote:
Sun Dec 16, 2018 1:24 am
But is this why emutos is a fair bit slower than tos ?
The only area where I'm aware that EmuTOS is noticeably slower than Atari TOS is some VDI graphics routines. These are indeed all hand written and optimized assembler in Atari TOS. But in EmuTOS we prefer as much C code as possible for portability (ColdFire!) and maintainability reasons. Even with a good compiler like gcc one still has to look at the generated code, though, at least for "hot" (i.e. often called) functions. Sometimes it can be optimized further, like I recently did for some VDI functions.

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

Re: TOS 2.06 improving - task for good C coder

Post by mfro » Sun Dec 16, 2018 2:42 pm

exxos wrote:
Sun Dec 16, 2018 1:24 am
... makes me wonder how DRI /emutos code seems to lack things like the grow and shrink boxes, so should run faster than tos ?
Negatively biased from past experience with older EmuTOS versions? 8-)
Grow and shrink boxes are part of EmuTOS AES since about one and a half years.
And remember: Beethoven wrote his first symphony in C.

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 2:50 pm

mfro wrote:
Sun Dec 16, 2018 2:42 pm
Negatively biased from past experience with older EmuTOS versions? 8-)
Grow and shrink boxes are part of EmuTOS AES since about one and a half years.
I'm behind the times then. Was probably 2+ years sine I used it. Maybe someone could benchmark it as it is now?

No idea if blitter is supported yet either ?

I'm not against emutos in anyway. Those guys are of course doing great work in basically creating a new OS.
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.

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

Re: TOS 2.06 improving - task for good C coder

Post by mfro » Sun Dec 16, 2018 3:05 pm

exxos wrote:
Sun Dec 16, 2018 2:50 pm
I'm behind the times then. Was probably 2+ years sine I used it. Maybe someone could benchmark it as it is now?

No idea if blitter is supported yet either ?
it is.

(since July last year).
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 » Sun Dec 16, 2018 4:46 pm

czietz wrote:
Sun Dec 16, 2018 10:13 am
The only area where I'm aware that EmuTOS is noticeably slower than Atari TOS is some VDI graphics routines. These are indeed all hand written and optimized assembler in Atari TOS. But in EmuTOS we prefer as much C code as possible for portability (ColdFire!) and maintainability reasons.
Exactly. Generally speaking, EmuTOS is not abnormally slow, or fat. Things are exactly as we designed them, by choice.
But as czietz said, one area where C language sucks is to write graphics drivers (i.e. VDI). This is because C is not well-suited to express special bitshift optimizations required for fast graphics. A very good example is NVDI, where we can see that hand-written optimized assembler routines completely blasts other implementations, sometimes even faster than hardware blitter. But for EmuTOS, we decided that flexibility was more important than speed, with some downspeed which can be seen in benchmarks, compared to Atari TOS. Such flexibility includes ability to compile code optimized for any CPU, including ColdFire. And realistically, this is not a problem for EmuTOS real-world usage (including ARAnyM + FreeMiNT, etc.).
And except than VDI implementation, I don't think that EmuTOS would be much faster if general code was rewritten in assembler. We can see that when looking at EmuTOS generated/disassembled code, manually written code would not be much different.

About Blitter, yes, it has been used in EmuTOS since a few releases. Currently, Blitter is used by some VDI functions, but not all of them. So don't expect huge boost.
Subscribe to my Vretrocomputing channel on YouTube and Facebook.

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

Re: TOS 2.06 improving - task for good C coder

Post by ijor » Sun Dec 16, 2018 6:04 pm

BlankVector wrote:
Sun Dec 16, 2018 4:46 pm
But for EmuTOS, we decided that flexibility was more important than speed, with some downspeed which can be seen in benchmarks, compared to Atari TOS. Such flexibility includes ability to compile code optimized for any CPU, including ColdFire.
I guess you already considered it, but you probably could have the best of both worlds. As is done in many cases (I'm not claiming I'm inventing the idea :) ), you can implement the routines both in assembler and C. Then, depending on the target architecture and build switches, you would use one or the other.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

Post Reply