Re: A86: Attention! Module Draft Available

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

Re: A86: Attention! Module Draft Available

On Fri, 12 Sep 1997, B. Nagel wrote:

> >     Now, it's just fine for him to include a .db in his module that the
> > function checks, but how is the program that uses the module going to know
> > where that .db is?  It needs to be exported in addition to the function.
> 
> Two solutions to this, have the .db somewhere in free system memory (I
> know a number of places which I can release later on) or use offsets.

There needs to be a way to let both the program and the module agree on
where the shared data are, and there needs to be a way to allocate shared
data so that modules don't clobber each other's data.  Putting the data
inside a library and using the normal relocation function is a nice clean
way of doing both.

> Also, instead of using a .db you could use flags or maybe registers.
> 

True, but flags and registers aren't persistent like a byte in RAM.


> > 2.  Some functions depend on other functions.  If we limit our modules to
> > one function, they will have to have their own import tables.  This makes
> > a ballsup of the load sequence.  (Do you *really* want to program a
> > recursive load sequence, Bill?)
> 
> Have any examples?

Line calls FindPixel.  PutSprite calls FindPixel.  Circle calls FindPixel 
and possibly Fill.  Polygon calls Line and possibly Fill.  Fill calls
FindPixel.


> Libs might depend on other libs too.

Not in our design.  All the dependent functions go in the library.

  
> > Now, I'm all for keeping libraries as simple as possible to avoid memory
> > wastage, but there are situations for which we need multiple exports.
> 
> Can you name any?

I just did in the previous message!

1. Shared data.
2. Dependent functions.


> I have many ideas for modules and there wont be any problems.  Asm progs
> have 10K max size, and it needs to be preserved as much as possible.

What are your ideas?  Remember: if you have inter-dependent modules you
have to have a way to keep them from being loaded multiple times.  This is
easier when you only have to worry about functions within self-contained
libraries.  The tables are smaller, and you don't have to call RST 20/10
as often.

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