Specs for new way to call functions.
Author: LTH
Version: .02

EKS and I did some talking about doing a call table for functions. Here is a slightly
different idea.

My thought is that in a table (the system16 table?) there would be a pointer to a function
that would look up an address for a module. You would pass to the function a unique ID for
the module. This would allow for multiple modules without having to have a set offset in
a table for different modules to be kept up with. A value would be returned back to tell
where to call to for a function call in that module. This can be done fairly fast if this
is pointing to a call table in the module (but it could be a function that then does the
call for the function you want). When a program would start it would go thru and find the
call addresses for the modules it needs. If a module values comes back as 0h then the
module is not loaded and hence the program can stop running without finding this out later.
Here are the pro's and con's to this type of layout.

Pro:
1. No call table needed, just a function to look up with and possibly another entry in the
   module info
2. very quick for the call. just call [some_variable] after the registers are set for the
   function to call to. (doing a call into a table in the module could be more work but
   could also be done).
3. if the ID for the modules was 4 characters long (32bit) there would be a max of 2^32
   modules.
4. you could swap out modules in an app for something else my possibly telling the app what
   ID to use for the module (in hex?). This is useful for a file system, video, sound, etc.
5. quick finding if a module needed for an app is loaded
6. Possibly more stable kernel (read below)
got any others?

Cons:
not sure...

I also think the current kernel should be more modular by moving the functions to modules
and doing multiple modules. anything doing with the screen (text to write, etc) would be 1
module, the mem calls would be another, etc. If this is done then the kernel could see that
a module crashed and asked if it should be reloaded. If the modules are done right then i
think that the kernel itself would be very stable as there would not be much to mess it up.
it would be more in the modules than the kernel itself.

If the modules follow a "standard" for functions then it would make it easier to swap things
out. this standard would have to come out of either the 1st module written for something
or 2 people that want to do the same type (ie video modules) talking about what function
does what.

If anyone has any comments on things to change, ideas, or problems I will be glad to hear
them.
LTH (Lightning@Lightspeed.dhs.org)