User Tag List

Results 1 to 5 of 5

Thread: Fixing the Parser Scoping Issues

  1. #1
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%

    Verified Bug Fixing the Parser Scoping Issues

    @DarkDragon : In looking for ZScript parser bugs to fix, I would consider this scope bug to have a rather high priority, as no-one was ever able to resolve it:

    Code:
    ffc script foo{
        void run(){
            int x = 10; int w; 
            for ( int q = 0; q < x; q++ ) {
                    if ( q % 5 == 0 ) {
                        int y = q * 2;
                        w += y -q;
                    }
             }
        }
    }
    The issue, is that using this example...

    1. The value' q', declared in the for loop, uses stack space, perpetually. It is only available to the scope of that for loop, and the if statement, but it always uses a register. This particular issue has ruined the day of many scripters, who declare for loops in scripts, and expect variables to only be in use when their scope is active. Repeated declarations of a loop condition, particularly in for loops, will cause stack overflows.

    2. Likewise, the variable 'y' is only available to the scope of one if statement, and yet, it also eats up stack space at all times. Essentially, any variable declared inside the scope of a function, even at a lower scope such as a statement, is not released until the function exits.

    3. Because run() is a function, and it never exits, variables inside these scopes in scripts eat up stack space at all times.

    Clearly, variables at the run() scope need to remain in use, but variables declared at lower scopes should pop off the stack when their scope exits; yet they do not at present behave in the expected manner. This is an easy way to confuse scripters when the stack overflows from no apparent cause, because they expect variables to pop off that never do.

    I don't know if you can give this any attention, but it is one of the more serious flaws in the parser.

    At present, most of us just try to train users to declare arrays at the scope of run() and never declare loop operators at a scope lower than run(). THis is a very bad system for handling an issue of this sort, as you can likely imagine. Any ideas on how to resolve this one?

  2. #2
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Ok. The current behavior is like C: nested blocks delimit variable scope, but there is only one stack frame, created on function entry and destroyed on function exit. This is not a bug, but I do see why it limits the complexity of individual functions given the fixed stack size.

    What you want is something like C++, where variables are actually destroyed, and not merely inaccessible, when they go out of scope. This is not entirely trivial, but also, not impossible: when it comes time to assign stack offsets to local variables, instead of just laying them out in linear order on the stack, you put them into a tree with one scope block per tree node, and allow tree siblings to share stack space.

    I'll put it on my short list.

  3. #3
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by DarkDragon View Post
    Ok. The current behavior is like C: nested blocks delimit variable scope, but there is only one stack frame, created on function entry and destroyed on function exit. This is not a bug, but I do see why it limits the complexity of individual functions given the fixed stack size.

    What you want is something like C++, where variables are actually destroyed, and not merely inaccessible, when they go out of scope. This is not entirely trivial, but also, not impossible: when it comes time to assign stack offsets to local variables, instead of just laying them out in linear order on the stack, you put them into a tree with one scope block per tree node, and allow tree siblings to share stack space.

    I'll put it on my short list.
    If you didn't know, I brought this up because the present method of handling scoped vars, leads to potential crashes, stack corruption, and at the best, script failure. Scripters who do not know to use a single variable for multiple for loops, as an example, and to refresh it with each new loop typically have resulting stack errors when a dozen loops with similar variables flood the stack as every variable is allocated as soon as the script runs. Obviously, array use is preferable in general, but if there is a resolution to this, it would clean up some issues that aren't pretty.

  4. #4
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Sure. It's a clear problem, whose solution doesn't affect old quests, doesn't touch the .qst file format, and doesn't introduce any new features needing future support. A home run in my book :)

  5. #5
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    I think this is working. I've pushed it to the experimental DD/zscriptstack.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social