Re: A86: Libraries and Loaders

[Prev][Next][Index][Thread]

Re: A86: Libraries and Loaders

On Mon, 4 Aug 1997, B. Nagel wrote:

> If you think about it, programs that import functions cant be called by
> the TI system anyway.  Actually it does belong in a shell, because the

This comes back to our standards issue.  If 10 people make 10 shells and
they all work differently, then either a user will only be able to run 10%
of the programs, or he will have to have more than one shell on his calc.

If 10 people make 10 shells and they all work the same underneath (though
they may have different interfaces and user-features), then any program
written for one will work with all the others.  This is why we need to
agree upon a standard.

Also, I think I mentioned that AShell writes-back EVERY program, whether
the program wants it or not.  This is bad.

> shell already contains:
> 
> The program's location and ram pages
> The program's size

What if those things change during the course of execution?  If the
program you run creates a new variable, there's a good chance the memory
will be shifted around and the will write back into the wrong place.
It would be prudent to get look up the program's address again.


> I'm working on adding AShell support for libraries.  I think it will
> save a lot of memory if libraries held only one function, plus it would
> making writing programs that import functions easier.  Martin Hock was
> telling me how most programs that share libraries for Usgard dont even
> use all of the functions, what a waste of memory!

Okay, then, let's talk.  Don't go hastily making a library service,
calling it "standard" and hoping that people will follow it.  Let's get
people to agree to a standard first.  Most of all, let's not rely on
ourselves too much.  You said Martin Hock has experience--good!  Please
ask him to subscribe to the list so we can pick his brain.  I'd like to
try to get David Ellsworth (Fargo) to give us some tips, too.

> I really like how you've taken all of our ideas and put them in one
> place to organize things.  I have a little suggestion about the fixup
> table:
> 
> > Each element in the fixup table points to an address that must be
> > changed when the function is relocated.
> 
> If the library starts with a .org $8000 then anything in the range of
> $8000 - $BFFF would be relocated, because there is no reason that any
> function would make a call or jump into that area.

Ah, but then it gets complicated to decide between "ld hl,$8000" and
"ld hl,($8000)."  With the table, there's no question about which
addresses need relocation--every fixup is explicitly addressed, which
means no mistakes can be made.

Besides, a program can be executable _and_ export functions at the same
time.  In this case, it would have to start at _asm_exec_ram.

If you're worried export tables taking up a lot of memory in libraries,
don't.  Think about the kinds of functions that are useful in libraries:
FindPixel, FastLine, WriteBack--they would all need few fixups.  After
all, the only things that need fixing are absolute jump and data accesses
within the part of the function that gets relocated.

If you're worried about import tables taking up a lot of memory in 
programs, don't.  There's an easy solution if a function is called so
frequently that it would require many fixups:  create a stub function.

         FindPixel:  call slGraph.FindPixel  ; call from graphics lib
                     ret

Then, there's only one fixup in the whole program.

--------
Dan Eble (mailto:eble@cis.ohio-state.edu)
         (http://www.cis.ohio-state.edu/~eble)
Follow-Ups: References: