Path: utzoo!utgpu!water!watmath!watcgl!lily!jafischer From: jafischer@lily.waterloo.edu (Jonathan A. Fischer) Newsgroups: comp.sys.atari.st Subject: Re: TRAP handler question Message-ID: <3838@watcgl.waterloo.edu> Date: 31 Mar 88 22:25:24 GMT References: <3738@watcgl.waterloo.edu> <197@bdt.UUCP> <444@nikhefh.hep.nl> Sender: daemon@watcgl.waterloo.edu Reply-To: jafischer@lily.waterloo.edu (Jonathan A. Fischer) Organization: U. of Waterloo, Ontario Lines: 39 In article <444@nikhefh.hep.nl> t68@nikhefh.hep.nl (Jos Vermaseren) writes: >The reason that some programs like Tempus have such a fast screen has several >reasons: >1: The screen routines are user routines that are directly accessible > for the program. They are written in such a way that it is not > necessary to save registers. The saving of registers actually represents a very tiny fraction of the time used by a typical "fastprt()" (as mine is called) routine. This is because fastprt() is called with a whole string, rather than a character at a time. The bulk of the time consumed is the simple loop that loads a character, finds the offset into the bitmap array, then copies 8 or 16 bytes of bitmap data to the screen. >3: Absolutely no interpretation of tabs takes place. A good tab handler > would slow the output down by about a factor two (guestimate). Actually, handling tabs adds perhaps 0.1% of overhead, with respect to time taken. The same goes for handling the ESC codes, too, since all that is added is one compare instruction, as in: cmpi.b $ESC, bgt not_ESC ... /* Processing of ESC, TAB, CR, LF, ... */ not_ESC: ... /* Regular character handling */ As you can see, if a given character is _not_ a control character (i.e. it is greater than 27), then all that is executed is the "cmpi.b" instruction. This adds essentially no time, when compared to the total time taken to print a typical string. -- - Jonathan A. Fischer, jafischer@lily.waterloo.edu ...{ihnp4,allegra,decvax,utzoo,utcsri}!watmath!lily!jafischer Pascal SUCC()'s.