Re: A89: kernel/no stub
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
> Also, what is the deal with the nostub (and what exactly is stub :)???
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
... 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
... 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."