Drew Northup wrote:
> Sorry to tell you Kev, but you seem to have forgotten that we will have to
> write it 20 different ways--script or no script. For example, what is
> handled by insmod in LINUX is done by a kernel32 library call in Win32, and
> so on, and so forth. Many of the things that you have mentioned seem to me
> as if they would be better handled by system() calls anyway. Since we will
> have to write up different sections for different OS's in any case, why not
> put those sections to some use here.
You are talking about something different. That kind of stuff is
hidden by code abstraction. What I'm talking about is at the
script file level. You may have one routine which initializes
the CPU to a certain state, and which you pass a filename
of an image file. This would logically be a function
in a scripting language. If you want to control behaviour
of downstream script code with having to continually
edit it, that would necessitate implementing variables.
And if-then-else clauses, and loops, and...
There are some other features that would be damn helpful.
It would be helpful to do something like this. Load a
user module at the command prompt. Run some tests.
Be able to init it or reset it at will. Unload the module,
reload a different version of it, and retry some tests.
All on the fly, interactively. You just can't do this
with a KISS script.
BTW, the modules I'm referring to are user space dynamically
linked routines. What method is use to do this, is abstracted,
another good reason to use an already implemented scripting language.
With a more powerful script language, you can code arbitrary
tests and control language. If you were to code this into
the C code of plex86, first you are bound to having only
the functionality you code, and also pollute the code with
all kinds of #ifdefs.
> Anyway, if it isn't already clear, I side with Ramon. Make whatever we end
> up using simple, clear, braindead, and local (built-in). I hope that
> somebody takes this and does something more constructive with it than the
> squabbling that has thus far defined this thread.
So far, this discussion has been quite useful. The biggest issue is in
defining the needs and reasons for using a better script language.
If we don't take the time to do this, we will end up with a very limited
piece of software, and it's going to be a bitch to debug.
Also, FWIW, some of the people who have been interested in plex86 from
the beginning have been OS design teams. I'm sure they will make use
of every ounce of functionality we add to plex86. And I sure could
use a ton more of it myself for testing/developing/implementing plex86.
-Kevin
