 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here are some point i would like to contribute.
1. Compatibility to the existing scripts and user base is needed.
2. I suggest mixing "old and New".
TO switch from the "Old SDL" to the new SDL, maybe the #version (and a new
#endversion) directive could be used. Using the "#endversion" a second part of
the script could be formulated in the "old" SDL.
I assume that there will be people out there who slowly change their existing
code-base to the new version.
At the end they will just stick with the "Old SDL", if the new one can not be
mixed with the old SDL.
3. I suggest a "Humand readable Frontend" and then a "Machine friendly Backend"
As a multi-Pass system.
4. Possibly a multi-pass system would save work and makes it possible to have
multiple people working on this at the same time.
Seeing that in some (for example "plant growing") scenes, the POV uses still a
lot of time in "reading Tokens", i suggest a Multi-Pass Parsing system with a
human readable front-end and a machine-token (fast to parse) Backend.
A) On Top is a SDL. Theoretically this can be defined by an Editor-PlugIn.
If somebody wants to make an own "specialized SDL" as a Plugin it could be
possible to just "link it into the Editor" and then have a specialized or
enhanced version of the SDL.
B) The second Pass can "expand Macros" until completely expandeded, and
interpret "Compiler Variables".
C) The Output should bow be converted to a definite Standard, could be an
"XML-readable Format" that can also be generated by Exporters (Blender, etc.)
from 3D-Programs.
D) In the last step this XML should get converted to Byte-based "Speedcode".
Based on "4 Byte Tokens". These can be parsed in maximum speed by an
"Interpreter". Also the resulting size of the code is very small this way and
fits in CPU/GPU Caches this way. Which is difficult if whole long words are
shifted around as "strings".
As these are multiple Passes, multiple persons can work on it at the same time.
The important point is just that the definitions are "clearly defined".
Once that is done, the rest could be coded in short time.
PS: Error Messages would start like this "Level 4 Error: Memory Limit reached"
or "Level 1 Error: Syntax ERROR expect NEXT for FOR in LINE 4 ".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.02.2016 um 09:04 schrieb Theogott:
> Seeing that in some (for example "plant growing") scenes, the POV uses still a
> lot of time in "reading Tokens", i suggest a Multi-Pass Parsing system with a
> human readable front-end and a machine-token (fast to parse) Backend.
The current plan is to compile the scene script directly into bytecode
for a virtual machine, and only then actually start executing it. The VM
will most certainly be a pre-existing one, most likely LLVM, giving us
access to optimization, JIT-compilation and the like at virtually no
implementation effort on our part.
As for a 4-level parser, I suspect that would add unreasonable
complexity to the whole thing. It might be justified if we had a team of
half a dozen people working on the parser alone, but at present I don't
see that happening anytime soon.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 13.02.2016 um 09:04 schrieb Theogott:
>
> > Seeing that in some (for example "plant growing") scenes, the POV uses still a
> > lot of time in "reading Tokens", i suggest a Multi-Pass Parsing system with a
> > human readable front-end and a machine-token (fast to parse) Backend.
>
> The current plan is to compile the scene script directly into bytecode
> for a virtual machine, and only then actually start executing it. The VM
> will most certainly be a pre-existing one, most likely LLVM, giving us
> access to optimization, JIT-compilation and the like at virtually no
> implementation effort on our part.
>
> As for a 4-level parser, I suspect that would add unreasonable
> complexity to the whole thing. It might be justified if we had a team of
> half a dozen people working on the parser alone, but at present I don't
> see that happening anytime soon.
What you do is, you expand the Macros and "Compiler-IF's" in the first Pass.
I just said "This is pass 2"
Until here we have just a defintion question.
About the suggestes XML-Backend. I understand that you prefer to use predefines
components. My contribution was more or less just to show some points.
Of course not anything that we can imagine is in reality doable, due to limited
time and resources.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
