NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/atari/st/16809

Text File | 1992-11-18 | 6.0 KB | 117 lines

Newsgroups: comp.sys.atari.st
Path: sparky!uunet!microsoft!hexnut!darekm
From: [e-mail] (Darek Mihocka)
Subject: Re: New TOS versions?
Message-ID: <[e-mail]>
Date: 19 Nov 92 02:44:38 GMT
Organization: Microsoft Corporation
References: <[e-mail]>
Lines: 103

In article <[e-mail]> [e-mail] (Dr. N.A. Affara) writes:
>As I understand it, things like NVDI and Warp 9 replace parts of TOS which
>was written in C, with bits written in assembler, which is faster.
>
>Would it be possible to rewrite the whole of TOS in assembler, and would this
>make it faster than NVDI etc?


Since I spent several years working on Quick ST / Warp 9, here is my
_extremely biased_ two cents worth:

There are several different issues here. One is C vs. assembler. The other is
the efficiency of the algorithms used by TOS.

What I did when I wrote Quick ST was to replace a large number of the text and
graphics routines in the BIOS, GEMDOS and VDI portions of TOS with my own very
fast assembly language code.

In the case of BIOS (the VT52 text functions), those were already written in
assembler, or at least the code didn't look like it was compiled. You can
easily spot compiled C code by looking at the VDI code, because it is of such
poor quality. So why were the routines in TOS slower than the ones Quick ST?

The problem with the VT52 routines wasn't that they were slow, but that
they did some stupid things, like each time you print a character, it also
redraws the cursor which can almost double the time it takes to print a
character to the screen. If your program is using the Cconws() function in
GEMDOS to print an entire string of characters to the screen, what do you
think that TOS does? It does the slowest thing possible: it sits in a loop,
fetches a character from the string and does a TRAP #13 call to the BIOS
to print the one character. BIOS prints the character, redraws the cursor,
and returns to GEMDOS. Then it does all this again for the next character.

This is stupid code. What Quick ST / Warp 9 does is draw all the characters
at once in a very tight loop, then just draws the cursor once. This eliminates
much of the overhead of repeated TRAP #13 calls and eliminates a lot of
redundant cursor redraws. It is no wonder that you can get Quick ST giving
you 1200% to 2000% speed increases in the speed of VT52 text. Gemulator
uses the same trick to speed up the VT52 output speed by making such a patch
directly in the TOS ROMs (because in an emulator, you can! <grin>)

Another example of inefficiency is in VDI. VDI has about 100 graphics
operations, such as line drawing, rectangles, circles, text, setting colors,
setting clipping regions, etc. When a dialog box is being drawn, only a
handful of operations eat up most of the CPU time - text drawing using v_gtext,
rectangle fills (for buttons, scroll bars, window title bars, etc) using
v_rectfl, and v_pline (for drawing outlines, zoom boxes, etc). But about 30%
of the CPU time is eaten up in little helper functions, like setting the color
of text, setting the clipping region, setting the fill pattern etc. These
are very simple operations and should be very fast, but TOS's TRAP #2
handler which dispatches the VDI operations has an incredible amount of
overhead, hundreds of instructions in fact, just to do ANY operation.
By comparison, on the Mac you simply write a value through a pointer to
accomplish the same thing.

By checking for these helper functions and handling them very quickly in
Quick ST / Warp 9, I was able to get about a 20% speed up in GEM operations
without even touching the big 3 (text, lines, rectangles)!

Now, the second issue is C vs. assembler. Most of GEM (AES and VDI) is written
in C. Unfortunately, Atari seems to be using a really brain dead compiler
that generated the worst possible compiled code you could imagine. It uses
32-bit addresses where 16-bit addresses will work, it doesn't use MOVEQ
when it could, it copies variables to other variables then copies them
back (which is redundant), and it doesn't actually seem to do much register
optimizing at all.

So when I rewrote the major VDI calls like v_gtext, v_pline, v_rectfl, etc
in assembler, all I did was use similar algorithms as what TOS used, but
used registers instead of memory locations and other things that a smart
C compiler could have easily done. The result of simply writing efficient
is a 2 or 3 times speed increase. Anyone who's ever played around with
optimizing C compilers on the PC like Watcom or MS C knows that there is
a huge difference in the quality of code produced when you compile with
/Ox or with /Od optiomization options.

Looking at code that is generated by newer compilers like Laser C and
Turbo C, and comparing it against the brain dead code of Alcyon C that
I believe that Atari used to compile the TOS ROMs, I am convinced that
a simple recompile of the TOS ROMs would easily bring the size of TOS
down to below 192K again, and at the same time double the speed of most
TOS operations. Easily.

Remember in 1985 when TOS 1.0 was released on floppy disk it was about
210K in size. To get it down to 192K, what did Atari do - use a better
compiler? NOT! They came up with this line F mechanism that shrinks
the code but at the same time slows it down about 20%. They also used
that as an excuse for not implementing the full font functionality of
the PC version of GEM, so instead they came out with the hack GDOS which
slowed down the system even more.

So in my opinion, trying to rewrite all of TOS in assembler would be
a bigger waste of time than simply having Atari recompile TOS using an
optimizing 68000 compiler instead of relying on a 1985 compiler. Sure,
the hand coded assembly language version might be a little smaller and
a little faster, but you'd be surprised at what a good C compiler could do.

My two cents worth.

- Darek

--
/--------------------------------------\
| Darek Mihocka. net: darekm@microsoft |
| Views expressed are my own, I think. |
\--------------------------------------/