[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[glob2-devel] Language demands
From: |
Bo Lorentsen |
Subject: |
[glob2-devel] Language demands |
Date: |
Wed, 15 Jun 2005 23:31:50 +0200 |
User-agent: |
Debian Thunderbird 1.0.2 (X11/20050602) |
Hi ...
I have been working on my new version of TEA, and have been trying to
take all things in account that have been discussed in the last
"scripting language" thread.
I have a few issues left that I like to ask about :
1. as I see it now, the current language have the possibility to run a
certain number of instructions, and then return control to the game to
be able to control CPU usage (time share). There are tree ways to do
this in TEA as I see it :
a. Limit the number of VM instructions performed per "tick" (store
the pc and cont. at next pos on return)
b. Make some kind of cooperative multitasking (locally allocated
stack, and wait instructions)
c. use the existing thread system (semaphore locked), and the wait
instruction.
a. sounds simple, but I dislike to put too much complexity into the
language code (there is plenty already :-))
b. I am not sure this is possible at all in a modern OS, but I have used
this and longjump in the past for tasks like this. but I dislike it and
it will be very hard to debug.
c. This sound to me, like a nice way to do it. We allocate to threads,
and when we like to make a script run, we unlock one semaphore and wait
on another, and then the script engine will run until the next "wait"
instruction, that will give back control, using the same semaphores.
There will not be any thread related problems, as only one thread runs
at a time, and debugging will be likewise easier.
How does that sound ? Am I totally off track ?
2. License, I like LGPL but I also like to add the same note as the
folks at LUA did, that say : "If the syntax and semantics of the
language (that is, the parser and the virtual machine) remain the same,
then the language is still Lua. If you simply add new libraries, or even
replace the standard libraries by your own, the language is still the
same, and you don't need to give it a completely different name."
Does anyone know if this is possible to combine ?
But beside this, TEA are heading in the right direction, after a big
cleanup (and addintion of param. function) and addition of a real stack
vm :-)
/BL