Re: A89: kernel/no stub

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

Re: A89: kernel/no stub


On Mon, Aug 14, 2000 at 04:42:10PM -0400, S43R80@aol.com wrote:
> 
> I'm not understanding how the kernel will allow faster access to certain 
> functions...what do you mean?  How do you make the 'applications do 
> everything themselves'?  What functions in the kernel need to be called which
> if not done from the program code will dissallow it from being used by the 
> ti???
> Also, what is the deal with the nostub (and what exactly is stub :)???
> ...Steven


Kernel-based programs can ...
  ... not run unless a kernel is installed.
  ... call library functions.
        The kernel does all the hard work in determining the actual address
        of the function (if the library exists on the calc at all!)
	Library functions usually expect their arguments in CPU registers as
	opposed to on the stack like AMS. The register calling convention is
	faster.
  ... call ROM functions directly with "JSR (xxx).L".
        The kernel looks up the addresses of all ROM functions that the
	program uses and patches the program appropriately.
  ... use a smaller relocation table.
  ... use something called "RAM calls".
        This is deprecated. I don't know and I don't care what it is. Never
	use RAM variables directly -- your program will probably not run on
	newer AMSes!
  ... use an automatically allocated and freed BSS section.
        The references into the BSS are also relocated appropriately before
	the program execution begins. BSS can be thought of as "scratch
	data" for a program: there's no need to remember it when the program
	finishes and therefore it's only actually allocated to the program
	when it's running.
  ... have its entry point anywhere in the program.
        The programmer can specify at what instruction execution will begin,
	in the middle of the program if he pleases. The kernel will make the
	CPU jump to this instruction when all relocation etc is done.

nostub-programs can ...
  ... theoretically run on any AMS anytime.
        The calc owner does not need to install a kernel. Some programs may
	require the existence of special ROM functions that don't exist in
	all AMS versions though. (This problem applies to kernel-based
	program too, of course.)
  ... not call library functions.
        Well, technically they CAN. To find the address, the program must
	first determine if and where the library is, then initialize
	(relocate etc...) the library and finally lookup the address in the
	library header. If you can write the code for doing everything
	above, you certainly have the skill to write your own version of the
	library function instead... :)
  ... call ROM functions indirectly through the ROM function table.
  ... have AMS relocating them at the cost of a larger relocation table.
  ... not use an automatic BSS section.
        The program can of course allocate and free memory at will with
	HeapAlloc() and HeapFree().
  ... only start at offset 0.
        AMS always jumps to the very first instruction in the program.

To accomodate with the library support etc, the kernel-based programs must
begin with a special piece of code that tells the kernel that this program
needs some "help" to get started. This piece of code is called the "stub".
  Windows' programs has a stub that says something like "This program
requires Windows" when you start them from plain DOS. Some programs actually
launch Windows if they're started from DOS and this is very similar to how
kernel-based programs work -- the "stub" activates the kernel that in turn
runs the "real" program.


/Johan  "100 bytes is enough."
Follow-Ups: References: