> scsh.vm -o scsh.vm
I think you can do just scsh.vm at that point
I cannot do just "scsh.vm" because the VM expects to be able to look up a
bunch of symbols.
I have to admit that its been quite a while since I looked at the vm
internals. I though that with the static areas that we were punting the
lookup because as you say they are fixed at that point. maybe running
the executible without the -o option will convince it.
It appears that symbol lookup is still being done.
> I need to make scsh start faster, because I have an application
> that starts a Scheme shell when a user hits a button on a GUI.
I'd suggest dumping an image with (dump-scsh-program main fname)
usually it is a big win. that is what most people do that use scheme 48
or scsh for CGI scripts on webservers. also, in that case, having the
staticly linked heap helps out with hitting the file cache on a busy web
server.
Using dump-scsh-program does not work. I tried dumping the "ekko.scm"
program, and it still took 6 or 7 seconds to run. The external symbol lookup
is still the problem here.
> I have also taken a peek at the NextStep "rld" routines, but haven't
> tried to make them work yet.
We'd love to have it.
I just replaced the nlist calls in unix.c with the NextStep rld equivalents.
Unfortunately, the result will not link, because the VM is compiled with
"-posix" and the POSIX library is incompatible with the NextStep "sys_s"
shared library that defines the "rld" functions. I am so angry I could kill
someone ... hmmm, guess that means I should eat breakfast ... must be low
blood sugar.
Anyway, the right solution now is probably calling lookup_external_name less
often, which gets me back to the ideas I sent you in a previous note.
bob
|