Re: A86: Functions and libraries

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

Re: A86: Functions and libraries

On Wed, 6 Aug 1997, James Yopp wrote:

> I'm leaving out the quoting because otherwise, this would be ridiculously 
> long.
> 

Good idea, since you really didn't need any of it to explain your point.


>      TableEntry(id_FindPixel)  ;Shell looks up funcID in libs, moves fn,
> id_FastLine    .equ    $13     ; and puts pointer in Jump table.


Remember:  A shell doesn't have anything to do with libraries or 
relocation.  That's the loader's job.

As far as a jump table goes, that could be done in conjunction with the
format we have on the web page, without any addition to the standard 
Whether or not the programmer chooses to do so is his choice.  That's
speaks well of the versatility of what we have so far.

The loader's job is to eliminate the need for special handling of calls,
jumps, and data access at run-time.  Here's an example:
-----------------
Imports:
     .db $0B,$08,"Lfindpix",$00 ; this program requires function $00
                                ; from the library "Lfindpix"

     .dw Call001 + 1            ; this is a list of addresses in
     ...                        ; the program that must be fixed
     ...                        ; with the address of the findpix
     .dw $0000                  ; function

[then later in the source, inside the A86Prog segment]

     ...
Call001:
     call $0000	; findpix
     ...

---------------------------
Before you reply complaining about this horrible format, read the rest of
this message, specifically the part marked with ***.


> Function calls for the libraries will be defined as follows:
> Libraries can contain multiple functions, but only one function is 
> exported at a time, by its unique ID. Libraries MUST contain ONLY 
> relative jumps, unless they call out to ROM.

These are both too restrictive.  Why bother including multiple functions 
in a library if only one can be used?


> #Define libCall(x)  call 3*(x-1)+2*x+JumpTable     ;I don't know if TASM 
> accepts this stuff


*** One thing is clear: it's going to be inconvenient to use any of the
available assemblers.  Someone's going to have to write one specifically
for the 86.  I will do it, unless someone else wants to.  Let's not talk
about the assembler yet... let's concentrate on the loader first.  We can 
create whatever sort of programming tools we need to make our lives easy,
but we shouldn't sacrifice flexibility or performance just because our
current assemblers don't handle libraries well (or at all, I should say).

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