Would a "higher level" AGI compiler be useful?

[Nick Sonneveld]

sorry about the spelling mistake.. you'll notice I spelled it correctly the second time

how about this for grammar..

Code: [Select]

global
{
 v55 var_that_has_to_be_55;
 var any_var;
 var timer;
}

room toilet
{
 flag toilet_flushed;

 if (isset(new_room))
 {
   ..
 }

 ..
}

room postoffice
{
 var people_timer;
 pic postoffice_bg;
 // or
 pic bg postoffice_bg;

 if (isset(new_room))
 {
   ..

   load_pic(postoffice_bg);
   // or
   load_pic(room_no);  // pic is associated with room ??
 }
 ..

 if (..)
 {
    new.room(toilet);
 }
}

- Nick

[Nick Sonneveld]

PS this format would be nice because you wouldn't have to have rooms in separate logics
PPS plus you could associate names with your rooms
PPPS do you do this all the time?

[eidolon]

Nick: I wasn't serious about the 32 bit integers.
However, I contend that such abstractions are in no way unfeasible, just very exhausting.

I take it we don't need values beyond 255 anyway.


I also want to cast a vote for your proposed scripting format!


And now a word about functions:
Functions would not need to be very different to room definitions. They could be inlined and their parameters could be treated just like any temporary variable. If a parameter is not modified by the function, its original variable could just as well be used directly.

[df]

on the fly translation of logic to z80! :> hehehehe

[Joel]

inlining of functions could work, but again functions couldn't call other functions without a stack.

as for backward compatibility: not trying to discourage you guys from doing this, but if it's not 100% backwardly compatible I probably just won't use it. With the script as you wrote it, what if I write some code that looks like that but I also have a line that says

#define vCounter v200

instead of
v200 vCounter;

Will the compiler be able to recognize that v200 is already in use?

also, something to mention, that pic data type in the script you wrote would also require a temporary variable, because load.pic(), etc., take var arguments.

How would you implement it such that rooms didn't have to be declared in separate logics? That sounds like more temporary variables to me.

My feelings on this whole issue:
if I can keep my source code exactly as it is right now and the compiler will compile my code and generate absolutely no temporary variables of its own or anything like that, then it's fine if there are extensions that do generate temporaries. However, extensions such as for loops, while loops, switch statements, and object.method syntax would not require temporaries and so they should not generate them. I can understand it if an expression such as 2 + 3 * 7 or v1 = 2 + 2 + v1 generates temporaries, but expressions that are already supported by AGI syntax without temporaries should not generate temporaries. Neither should simple expressions such as v1 = 2 + 2 + 8 + v2. I shouldn't have to give up precise control over what variables are used for what just to use the extensions that I think would be useful. If I did, the new compiler would have no value to me.

By the way, AGIC was written with lex and yacc. If it was well-written, it shouldn't, in theory, be too terribly difficult to modify that. I haven't really taken a good look at it, though.

[Nick Sonneveld]

eidolon: I just think the abstraction helps with creating a game, instead of worrying about resource management.  It depends on what features you use, most wouldn't complicate things.  

functions could work inline, but remember that some agi commands only accept a number constant, not a var number.

The scripting format's just an idea.. I think it might need some work.  I want to take into consideration logics that aren't associated with rooms and other things.

joel: The lack of stack does restrict things..

Should we stick with the same format as before?  We could have a header to tell the compiler it's a new format.. we could make the compiler accept logics without a room definition, and just use a number supplied in the filename or command line.

If we use a separate preprocessor, we wouldn't be able to parse the #defines.. the least you would have to do is replace all of them with a global{} (if we decide to use such a thing)

btw, I realised the picture problem while I quickly wrote that script idea.  The plan was for "pic bg postoffice_bg" to make sure that the picture had the same number as the logic.  If we wanted another pic, then we'd have to use a temp var anyway.

I meant logic scripts sorry.. ie, define a group of small rooms in the same script, and the compiler would manually separate them into their own logics with different numbers.

Basically, I don't think we can use temporaries with the original code unless we read them all in, parse the defines, and then create temporaries around that.  How will the compiler know that var 50 in the first room isn't going to be used in the last room too?  We could add while's and things like that to the original syntax but we would be limited if we couldn't use temps.

why do you want precise control over the use of variables?  what sort of "algorithm" do you use to make sure that a variable isn't used anymore later in the game so you can use it in a later room?  We could apply the same sort of concept to the compiler  somehow to do that same concept.

- Nick

[df]

use variables like a stack. you have 255 of them.
have a low order one (20?) whatever, be a base pointer.

when you go into a room, you know you are using 5 vars,
do push/pop's. (inc/dec on stack pointer) to get the variable.
starting at 255, would be a piece of cake!

[Nick Sonneveld]

The problem Joel was pointing out is if you're got pre-written scripts that #define those particular variables..

- Nick

[Joel]

What I do to separate my variables is I reserve all variables below 200 for global use. All variables 200-255 are for local use. I have no problem with the use of temporaries defined by the compiler if I can say, "use v200-v255 for temporaries but don't use v199 and below for them". Other people might want fewer or more temporaries. I think that there should be a way to tell the compiler which variables it is allowed to use.

I guess this is actually more of an issue with flags, since I so far have only 2 global vars in my game and about 11 global flags. Temporary flags I guess would only be used with the evaluation of boolean expressions, but I still want the ability to say which vars and flags the compiler can use for temporaries and which are off-limits.

As for determining when global vars can be recycled, that's more or less determined on a variable by variable basis, but it could be handled by a state system.

The main issue I want to avoid is having to rewrite my code. If it were absolutely necessary, I guess I could rewrite my defines for the new declaration method, but rewriting should be kept to a minimum.

The thing is, if the new compiler forbids #define vCounter v200, then will it also forbid v200 = 2; ? I think, as much as possible, the new AGI compiler should be able to handle old logic syntax the way C++ compilers can handle C syntax. C++ has a few additional restrictions, but for the most part any C program is also a C++ program. Unfortunately, using the preprocessor for variable naming I can see is a problem. Getting the define names into the compiler's symbol table as if they were var declarations would be tricky at best.

[Nick Sonneveld]

joel:
I'm thinking more of a variable definition system where the programmer will only have to define variable numbers for the system variables.

The whole script syntax that we're using was made by fans, I don't see why we can't create a new one.  Backwards compatibility is a problem.  The original syntax is very simple, and working around it would seem like a kludge.. what's wrong with clean slate?  C/C++ at least handled variables the same way, I'm trying to propose a different way of handling them.

If we add a decent preprocessor to the compiler, we could share it between two languages.. the original and the new syntax.  I don't know if it would be possible for a game to use both types of syntax in their logic though.

- Nick

[Joel]

There's nothing wrong with it, but unless this new compiler comes out very, very soon then there wouldn't be much chance of me using it, because by that time I would have a whole lot of code to rewrite to make the move to the new compiler, and I doubt I'd be willing to do it unless the new compiler was just really, really something.

This issue with temporary variables is not something that can just be abstracted away, though. Programmers shouldn't have to actually WRITE the temporary stuff, but they will have to be AWARE of it for the simple fact that AGI is a limited resource system. It's a very real possibility that adding a global var declaration could break code throughout the game, and then the programmer would suddenly have to understand that the compiler needs temporaries to evaluate expressions, array syntax, etc. That's why I think it would be helpful in this regard if a programmer could say, "I don't really care WHICH variables you use for what, but only use variables in THIS set of variables".

[Nick Sonneveld]

The way I'm planning it is that variable numbers don't get assigned until linking stage.  Global variables will get assigned numbers, and they will only be used for globals..  then you define "chapter" states.. rooms could associate with a certain state, so rooms using vars in one state would share the var numbers with another.  The idea being that the player progresses through the states and can't go backwards.

Programmers shouldn't have to write the temporary stuff, that's why I want the compiler to handle it.  I don't see how adding a new global will break the game though.. the compiler would just set aside a variable number for that global variable.  All variable numbers should be assigned when all compiled logics are linked together.

I don't know how soon a workable compiler will be working though.. we still need to figure out the new syntax.

- Nick

[Nick Sonneveld]

I want the programmer to say "I've got variables called this.. I don't care what actual number they have but make sure they're available to me, some all the time, some when the player is at a certain stage of the game.. if there's any left over, use those for temporaries."

- Nick

[Joel]

The "if there's any left over" part is how adding a global declaration could break existing code. In the best case, the compiler would catch the problem at link time and say it can't find any way to link the logic; at worst, the compiler's temporaries could start overwriting global data.

[Nick Sonneveld]

I think I understand now..  if the linker can't assign enough variable spaces for temps because they're taken up.. then it would just quit with an error..  The programmer would have to use less variables or share them across the game.  I don't see how the linker break down and start using other variables..  It wouldn't break code, it just wouldn't compile.

It would be the same if you manually #defined the vars and you needed another global but all the vars were taken up.  At least the linker would have the possibility of allocating vars efficiently.

- Nick