home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / atari / st / 16921 < prev    next >
Encoding:
Text File  |  1992-11-20  |  3.3 KB  |  60 lines
  1. Newsgroups: comp.sys.atari.st
  2. Path: sparky!uunet!pipex!warwick!dcs.warwick.ac.uk!leo
  3. From: leo@dcs.warwick.ac.uk (Leo Hendry)
  4. Subject: Re: New TOS versions?
  5. Message-ID: <1992Nov20.160320.11380@dcs.warwick.ac.uk>
  6. Sender: news@dcs.warwick.ac.uk (Network News)
  7. Nntp-Posting-Host: stone
  8. Organization: Department of Computer Science, Warwick University, England
  9. References: <1992Nov17.122627.16049@crc.ac.uk> <1992Nov19.024438.22369@microsoft.com>
  10. Date: Fri, 20 Nov 1992 16:03:20 GMT
  11. Lines: 47
  12.  
  13. In article <1992Nov19.024438.22369@microsoft.com> darekm@microsoft.com (Darek Mihocka) writes:
  14.                 :
  15.                 :
  16. >So in my opinion, trying to rewrite all of TOS in assembler would be
  17. >a bigger waste of time than simply having Atari recompile TOS using an
  18. >optimizing 68000 compiler instead of relying on a 1985 compiler. Sure,
  19. >the hand coded assembly language version might be a little smaller and
  20. >a little faster, but you'd be surprised at what a good C compiler could do.
  21.  
  22.   I agree entirely - I have looked at the VDI/AES code too and it is
  23. absolutely dire and hasn't changed in later versions of TOS.  This lead me to
  24. the conclusion that Atari must have lost the entire GEM source code at some
  25. time - this would explain why they haven't recompiled it and why they have had
  26. such difficultly making modifications to it (And when they do, more bugs creep
  27. in).  However, the source to the example CPX that Atari provide compiles to
  28. literally half the size using Lattice C5 compared to their precompiled
  29. version.  What is more their code is totally non-ANSI (no prototypes etc.)
  30. which seems to indicate they are still using the same old compiler.
  31.   Another possiblity is that Atari are unable to recompile the GEM parts of
  32. the operating system due to legal problems - I remember a few years back that
  33. Apple or Microsoft (or somebody, although not Xerox!) took action that
  34. meant Atari could not update to the latest PC version of GEM in their
  35. machines.
  36.   Back to what you said about algorithms - why is there an incredible pause
  37. after the desktop reads a directory from the disk and before it starts drawing
  38. the icons?  What is it doing?  I can only assume it is doing something like a
  39. bubble sort on the filenames, except instead of juggling pointers copying the
  40. filenames backwards and forwards.  Does anybody know?
  41.   I didn't know the story behind the inclusion of Line-F system before - I
  42. always thought it seem an extreamly slow way of doing things.
  43.   Interestingly some of the line A functions are actually very well written
  44. - I tried to write a fast resolution dependant line drawing routine in
  45. assembler once, using the best algorithms I could find in books and in the end
  46. used line A because it was so very nearly as fast.
  47.  
  48. Conclusion:
  49.   Rewrite the VDI and AES in C then compile it with a good compiler this
  50. should give a 40% speed up at the very least (switching on all optimisations
  51. on Lattice C gave literally a 50% improvement in a Dhrystone bench mark, and
  52. the code with all optimisations off looks alot better than that in TOS).  You
  53. can then always hand assembly code time critical sections.  The entire code
  54. should take up less than 100K of RAM (remember it's just the GEM parts you're
  55. rewriting).
  56.   Then sell the source to Derek for recompilation to 386 code for his
  57. Gemulator which would then be usably fast on a sub #1000 PC (if not too fast).
  58.  
  59. - Leo
  60.