🚀 go-pugleaf

In article <188@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes:
>In article <390@uvicctr.UUCP>, collinge@uvicctr.UUCP (Doug Collinge) writes:
>> Someone said that OS9 68k is capable of "preloading" commands; that is,
>> loading some programs into memory and executing them there when invoked
>> rather than loading them from disk.  This seems to be yet another
>> excellent idea incorporated in OS9 that no-one else seems to have
>> thought of.
>
>Yes, that is one of the many good features of OS9.  Another is
>pre-loaded modules.  You can have "external" modules on OS9 - when
> [...stuff deleted...]
>itself.  You can, of course, pre-load modules.  Nice feature.
>
>> How difficult would it be to hack this into Gulaam?
>
>Probably VERY difficult.  TOS is not setup to handle pre-loaded programs;
> [...stuff deleted...]

Never used gemdos call 0x4b (Exec) with a mode of 4?
You can have preloaded programs on the Atari ST as well, and it works quite
nicely. I used it in a find command and in a shell I programmed for the Atari 
(yes, the Unix find command!), for example:
find .. -type d ! -name . ! -name .. -exec ls -l {} \;
(For those not familiar with find, this one finds all directories beneath 
the current directory's parent (excluding . and .. names) and does a ls -l
on each one of them).

Each time loading ls worked fine on the ramdisk I used to use, but once I
started working on a hard disk, it becomes really slooooooooooowwww!
Then I decided to preload the ls command (with gemdos(0x4b,3,"ls",0,0)).
The gemdos function returns the basepage address of the loaded program.
Now 'find', each time it has to 'ls', copies the argument string into the
basepage; then it runs 'ls' by gemdos(0x4b,4,0,0,0) (I don't remember whether
these are the correct values for the parameters). It is now (nearly) as fast 
as a builtin function!

There are however a few problems (and I have not solved all of them):
1) When the parent program changes directories, the child stays in the directory
it started in (the current directory and disk are saved somewhere on the 
basepage, start+55?).
2) There is also a problem with the memory; the loaded child obtains, as usual
the rest of the memory available (in addresses basepage+4 to basepage+7 the
address of the 'next free location' or something like that is found: 0xF8000 on
my 520 ST+). Thus there is a problem with multiple preloaded childs or childs
requesting additional memory. I've overcome this (sort of) by using setblock
(gemdos 0x4a) and adjusting the 'next_free_location' ptrs on the childs 
basepages. It's better now, but still buggy (I don't know all about Gemdos
memory management, I'm finding out now).
3) There could be problems as well with file descriptors (they're also on the
basepage).
4) Initialized static and extern variables do not regain their initial value
after a run. This is in consequence of the 'once-only' load. It could be
overcome by a) always explicit initializing (by the child process), or 
b) make a copy of the initialized data space (by the parent process) and use 
this to re-initiate from the next time (more expensive, but not breaking 
existing code).

If you manage to overcome these difficulties, it should not be very hard to
code this preloading into a shell (I did it, having still these little problems
...). The shell maintains a list of preloaded programs, their pathname and
their fat number and handles loading/executing depending on memory available,
programs preloaded etc. Preloaded programs are almost as fast as functions
built into the shell.

If anybody has suggestions about the memory management part, or questions 
'about the real code', or want examples, please RESPOND! A commented disassembly
of the gemdos part of the O.S. would also be great ....

		leo.