Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!van-bc!root
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ExecBase
Message-ID: <2453@van-bc.UUCP>
Date: 3 Jun 89 16:02:52 GMT
Sender: usenet@van-bc.UUCP
Lines: 43

In <44325@vax1.tcd.ie>, rwallace@vax1.tcd.ie (Russell Wallace) writes:
>> 	I strongly suggest though that people who write programs or
>> assembly routines NOT always get execbase from location 4.  The reason is
>> simply that from what I can tell location 4 is in CHIP memory and thus
>> subject to fetch delays when one is in a high bandwidth video mode.
>
>You WHAT? How long is one instruction going to take no matter how high
>bandwidth a video mode you're using? If you're accessing ExecBase at all it
>means you're calling a ROM routine and those are so bloody inefficient the
>execution time will far outweigh the time it'll take to fetch the longword from
>location 4. Not to mention the fact that Exec routines (Alloc/FreeMem,
>Open/CloseLibrary, FindTask etc.) are usually called only at the beginning and
>end of the program.

While the instruction will take the same length of time once it has accessed
it's data, the time spent waiting for CPU access under heavy DMA can be
significant.  Sure, if indeed your particular program only calls a few Exec
functions at the beginning and end of the program, the time saved by getting
and caching AbsExecBase will be minimal.

However, not all programs do things this way. AllocMem and FreeMem mght be
called numerous times throughout a program. Keeping lists of things is a good
example. The IO functions, DoIO, SendIO, WaitIO, CheckIO, and AbortIO could be
called thousands of times throughout the runnin of a program. Then there's
CopyMem and CopyMemQuick, PutMsg, GetMsg, and RawDoFmt, that could all be
called many times.

It may be a relatively small thing, but if you have the choice, it's just as
easy to cache the pointer somewhere in FAST (or 32 bit FAST if you have it),
saving anywhere from some to a lot of time, again, depending on your
application. Paying attention to details is a way to speed up code, and this is
such an easy one to do.

-larry


--
Van Roy's Law:  An unbreakable toy is useful for breaking other toys.
+----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                |
| \X/    lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips  |
|        COMPUSERVE: 76703,4322                                        |
+----------------------------------------------------------------------+