bdiscoe@tybalt.caltech.edu (Ben W. Discoe) (05/17/89)
I'm trying to find Execbase. I seem to remember reading somewhere that it's always at 0000004 in memory, but it doesn't seem to be there, and I can't find my reference any more. Could anyone tell me where it is or how to find it? Thanks in advance....
thomas@cbmvax.UUCP (Dave Thomas QA) (05/18/89)
In article <10702@cit-vax.Caltech.Edu> bdiscoe@tybalt.caltech.edu.UUCP (Ben W. Discoe) writes: > > I'm trying to find Execbase. I seem to remember reading somewhere that > it's always at 0000004 in memory, but it doesn't seem to be there, and > I can't find my reference any more. Could anyone tell me where it is or > how to find it? The pointer to ExecBase is in address 4. In other words: struct ExecBase *ExecBase = (struct ExecBase *) 4; > Thanks in advance.... Your Welcome! Dave -- Dave Thomas, Commodore Amiga Test Engineering UUCP ...{allegra,rutgers}!cbmvax!thomas
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (05/23/89)
In article <6913@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes: >The pointer to ExecBase is in address 4. In other words: > struct ExecBase *ExecBase = (struct ExecBase *) 4; I think that should be: struct ExecBase *ExecBase = *(struct ExecBase **) 4; -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.commodore.com - The Unix Programmer's Manual, ...!ucsd!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
ecarroll@csvax1.cs.tcd.ie (Eddy Carroll) (05/24/89)
In article <31472@sri-unix.SRI.COM>, thomas@cbmvax.UUCP (Dave Thomas QA) writes: > In article <10702@cit-vax.Caltech.Edu> bdiscoe@tybalt.caltech.edu.UUCP > (Ben W. Discoe) writes: >> >> I'm trying to find Execbase. I seem to remember reading somewhere that >> it's always at 0000004 in memory, but it doesn't seem to be there, and >> I can't find my reference any more. Could anyone tell me where it is or >> how to find it? > > The pointer to ExecBase is in address 4. In other words: > struct ExecBase *ExecBase = (struct ExecBase *) 4; > Shouldn't this be: #include <exec/execbase.h> struct ExecBase *SysBase; ... main() { ... SysBase = *(struct ExecBase **) 4; ... } i.e. set SysBase to the contents of the location which contains the pointer to ExecBase? Also, the initialisation has to be done at run time rather than compile time (after all, ExecBase could move around depending on the memory installed etc), so the expression given above can't be used as an initialiser expression for the declaration of SysBase. All of which is pretty academic anyway, since Lattice initialises SysBase for you, and I'm sure Aztec does too. So all you need to say is: extern struct ExecBase *SysBase; anywhere, and it will be automatically setup for use. Eddy (who will probably find a large number of other people have also replied to this, but what the heck :-) -- Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until INTER: ecarroll@cs.tcd.ie | until you've died in UUCP: {..uunet}!mcvax!ukc!cs.tcd.ie!csvax1!ecarroll | MUD!" - Richard Bartle
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/25/89)
:In article <31472@sri-unix.SRI.COM>, thomas@cbmvax.UUCP (Dave Thomas QA) :writes: :> In article <10702@cit-vax.Caltech.Edu> bdiscoe@tybalt.caltech.edu.UUCP :> (Ben W. Discoe) writes: :>> :>> I'm trying to find Execbase. I seem to remember reading somewhere that :>> it's always at 0000004 in memory, but it doesn't seem to be there, and :>> I can't find my reference any more. Could anyone tell me where it is or :>> how to find it? As people have already noted, the pointer to ExecBase can be found at location 4. assembly: move.l 4,A6 C: SysBase = *(struct ExecBase **)4; 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. The proper way to access the execbase is to assign it to a variable at program startup/init and then reference it from the variable. For example, one always references 'SysBase' from C... the C startup module always does a 'move.l 4,_SysBase'. Since SysBase will be in FAST memory if the machine has fast memory, the processor will never freeze trying to access it no matter what video mode you are in. The people at C-A have been moving towards getting as much stuff out of CHIP memory as possible in hopes of eventually making CHIP memory DMA-only memory for the custom chips, thus making all programs run much faster in the higher video modes. The main problem is that currently the exec library vectors are created before fast memory is turned on and thus usually gets put into CHIP memory.... the infamous location $676 (p.s. NEVER EVER assume ExecBase is at $676!). Also: The 68010 and beyond allow you to change the vector base and this most certainly will be implemented in a future release so the interrupt vectors can be moved out of CHIP memory. This is one reason why serial at high baud rates currently goes to hell when you are in HAM or 640xNx4 mode. -Matt
thomas@cbmvax.UUCP (Dave Thomas QA) (05/25/89)
In article <10702@cit-vax.Caltech.Edu> bdiscoe@tybalt.caltech.edu.UUCP (Ben W. Discoe) writes: > > I'm trying to find Execbase. I seem to remember reading somewhere that > it's always at 0000004 in memory, but it doesn't seem to be there, and > I can't find my reference any more. Could anyone tell me where it is or > how to find it? In article <31472@sri-unix.SRI.COM>, I wrote: > The pointer to ExecBase is in address 4. In other words: > struct ExecBase *ExecBase = (struct ExecBase *) 4; In article <45382@csvax1.cs.tcd.ie> ecarroll@csvax1.cs.tcd.ie (Eddy Carroll) writes: > Shouldn't this be: > > #include <exec/execbase.h> > struct ExecBase *SysBase; > ... > main() > { > ... > SysBase = *(struct ExecBase **) 4; > ... > } > > i.e. set SysBase to the contents of the location which contains the > pointer to ExecBase? > Eddy is correct. I must stop posting when I come in to work in the morning. I don't wake up until lunch :-). Sorry if I misled anyone... Dave -- Dave Thomas, Commodore Amiga Test Engineering UUCP ...{allegra,rutgers}!cbmvax!thomas
rwallace@vax1.tcd.ie (05/31/89)
In article <8905242209.AA20811@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > As people have already noted, the pointer to ExecBase can be > found at location 4. > > assembly: > move.l 4,A6 > > C: > SysBase = *(struct ExecBase **)4; > > 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. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (06/02/89)
In article <44325@vax1.tcd.ie>, rwallace@vax1.tcd.ie writes: > In article <8905242209.AA20811@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) 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 If you are using one of those video modes that take up `all' bandwidth (such as many under the new ECS, or hires four-bit plane) that *one* instruction can easily take an entire scan-line, or 63us. Most library routines (such as exec) are not as inefficient as this. Listen to Matt; he knows whereof he speaks of. Wherefor dost thou question him?
doug@xdos.UUCP (Doug Merritt) (06/02/89)
In article <9641@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: > >Listen to Matt; he knows whereof he speaks of. >Wherefor dost thou question him? Thus spake the Apostle Tomas, in those dark days before the Reckoning. For knew not Tomas of the revelations of St. Matt? Verily did he recount the portent: "I saw seven angels with seven plagues. And I saw something like a glassy sea mixed with fire, and those coming off victorious over the beast and over his statue and over the number corresponding to its name; I saw them standing on the sea of glass, holding the harps." "The first angel departed and emptied his bowl upon the earth. And a loathsome and malignant ulcer attacked the men who bore the mark of the beast and worshipped its statue." If thou wisheth not to meet this fate, follow then the creed of Matt, favored of the favored. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)
bartonr@psu-cs.cs.pdx.edu (=> robart <=) (06/02/89)
In article <9641@polya.Stanford.EDU> writes: > Most library routines (such as exec) are not as inefficient as this. > Yes, but what if the library routines themselves access location 4 directly, as many of them do?
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/03/89)
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 | +----------------------------------------------------------------------+
dillon@HERMES.BERKELEY.EDU (Matt Dillon) (06/13/89)
:In article <9641@polya.Stanford.EDU> writes:
:> Most library routines (such as exec) are not as inefficient as this.
:>
: Yes, but what if the library routines themselves access location 4 directly,
:as many of them do?
Which ones? Tis a bug 4-sure! Some of my libraries did but I've
since fixed the problem.
I posted that message, left for two weeks, came back, and now find
3 responses on the chain that, together, are very funny :-) Thanks for
the Angel status guys but I think the only living person who rates *that*
is Mother Teresa! It brings to mind other connotations of my name that
people don't normally think about!
-Mattdoug@xdos.UUCP (Doug Merritt) (06/13/89)
In article <8906122254.AA02139@hermes.Berkeley.EDU> dillon@HERMES.BERKELEY.EDU (Matt Dillon) writes: > I posted that message, left for two weeks, came back, and now find >3 responses on the chain that, together, are very funny :-) Thanks for >the Angel status guys but I think the only living person who rates *that* >is Mother Teresa! Glad you liked it. Puts a whole new light on the subject of getting religious about computers, doesn't it? :-) >It brings to mind other connotations of my name that >people don't normally think about! You mean the fact that in Mongolian "matt" means sheep herder? But remember that in those areas that's a respected career. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
bartonr@jove.cs.pdx.edu (Robert Barton) (06/26/89)
dillon@HERMES.BERKELEY.EDU (Matt Dillon) writes: > (I wrote:) >: Yes, but what if the library routines themselves access location 4 directly, >: as many of them do? > Which ones? Tis a bug 4-sure! Some of my libraries did but I've > since fixed the problem. Graphics is one that does, like when it wants to allocate or free some memory, call an alert, etc. Intuition doesn't have to because it keeps the pointer in the IntuitionBase structure so it can fetch it from there. I would think that any library that didn't save ExecBase in its own LibBase would have to use AbsExecBase instead.