Re: A86: Libraries and Loaders

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

Re: A86: Libraries and Loaders

Dan Eble wrote:
> 
> On Tue, 5 Aug 1997, B. Nagel wrote:
> 
> > > To simplify things, could we compromise by saying that when a library is
> > > used, the entire thing is loaded, but also that up to 256 entry points may
> > > be specified?
> >
> > Okay, I guess that works.
> 
> Good.  I thought of another example: Suppose a library contained
> fonts--maybe a roman, italic, and bold version of the same font.  In that
> case there would be three "entry points" into the library.

The more I think about it, libraries should have only one function.  For
fonts, each font would be its own library and if a library had more than
one font, the same function would be used.  You said earlier:

> You have a library, Lsprite (or something) that has a function to
>        do the logical OR of a bitmap to the screen.  If you sometime want
>        to to XOR, it would be convenient if you could just call a second
>        function within that same library, since all the code except for a
>        few lines is the same.

This kind of sprite function is slower.  Games that need speed will use
libs with only one function.

> > > .dw ProgLen      ; number of bytes to load into _asm_exec_ram
> >
> > I dont think this is necessary, because a shell should be smart enough
> > to figure this out on its own.
> 
> Maybe it's not _necessary_, but it's a good idea.  Think about how easy it
> would be to put this into BC, then put the start address into AHL and
> start looping.  Besides that, since there's no fixed location for the
> import table (etc), and since there's no need to waste memory in
> _asm_exec_ram by loading the import table, this provides a good way for
> the programmer to control exactly what gets loaded.  Here's an example:
> 
>         A86Prog:
> 
>                 blah
>                 foo
>                 smee
>                 grep
>                 ret
> 
>         Imports:
>                 sfasfaf
>                 yiyuiyuu
>                 bnmbnmbn
> 
> If the loader automatically loads everything from A86Prog on, then there
> would be space wasted by the import table.
> Additionally, knowing the length of the code segment would put a check on
> write-back (so that the import table is not overwritten, for example).

true, but, its
another reason why libs with more than function really complicates
things.
 
> *** I think I need to emphasize the difference between a shell and the
> loader.  In the scheme I envision, a shell would be essentially the same
> as your AShell is now.  All it would do is find programs, display their
> titles and icons, and call Asm() or A86() to run them.  A86() would be our
> plug-in loader that would take care of library fixups, data write-back,
> and anything else we think of that belongs in the loader.

Its already bad enough that there will be different shells that are
bound to have some incompatabilites.  Come on, separating the loader
from the shell only makes things worse.  We'll have this shell that
needs that loader which cant be used by another shell which needs its
own loader, which might sometimes work with the first shell.
 
> > > AsmStart:            ; program run when invoked via Asm( )
> > >      ; This could print an informative error message,
> > >      ; actually do something useful, or just return..
> > >      ret
> >
> > I was thinking, if a prog used libraries, it could simply replace nop
> > with ret.
> 
> But this way is much more versatile, and 4 bytes is not that much to pay
> for the flexibility this method offers.

Yeah, actually I do like this method.

> > Your import table is perfect :)
> >
> 
> Great!  I tried to make it compact and easy to process.  Does anyone else
> see any problems with the import table?

Now, if it was only made to handle one function ;)
 
> > > .dw LibLen       ; number of bytes to load
> > > .dw pStartAddr   ; pointer to first address to load (.org 0)
> >
> > These are needed either, since libraries cant executed.
> >
> 
> Those aren't for execution.  Those are for loading BC and AHL and looping
> to stuff the library's code into _asm_exec_ram.  Like I said before, we
> shouldn't count on the "code" being everyting between the tables and EOV
> (end of var).

I kinda agree with you and I kinda dont, this part will need some
thinking.
 
BTW, I got AShell to relocate single function libs onto the ends of
progs and it worked on the first try!

Bill
Follow-Ups: References: