195 réponses à ce sujet

[SkywingvL]

Is this with the same script source text? Are you sure that you rebuilt it with the new compiler?

If you link me the .ncs file, I can check that (if it's the .ncs for the source text you provided above).

[ShadowM]

No it not with sample script it with a bunch of other scripts. A lot of it runs though a big include, prob. my lousy scripting practices that why I did not go into it. I started to read how I messed up. What are stack underflows? Could you give me a sample of one?  When I do searches it go to old forum or does not mention nwn. Sorry for all the trouble. I find one of the scripts it saying it and all custom functions in it if you want.

Modifié par ShadowM, 25 juin 2011 - 05:33 .

[SkywingvL]

It generally means that something has mismanaged the execution stack of the script. If the script works with the BioWare compiler, then it's probably a code generation issue of some sort. If you can isolate a specific script that is having problems, drop me a copy of it and the include dependencies that I will need to compile it, and I can take a more detailed look.

[ShadowM]

Yeah , these only pop up after a full compile with the latest .ndl you gave me. If I compile with bioware old compiler or the other compilers I do not get the stack underflow errors. I get you that stuff, prob. tomorrow thank you for the help.

Modifié par ShadowM, 25 juin 2011 - 05:54 .

[virusman]

I can confirm this: I'm having issues with DMFI and other scripts in my module after compiling with the latest version. Previous build (from NWNTX 1.0.1) worked fine.

[SkywingvL]

The fix for the problem with globals being incorrectly optimized into constant expressions exposed several other pre-existing code generation bugs relating to usage of global variables that reference other global variables in their initializer expressions. I'm working on a fix for these.

[SkywingvL]

ShadowM: Please give this build a shot:

http://valera-ext.ny...CompilerDll.ndl

There were several problems here.

1) There was a longstanding bug in the compiler (also in the PRC builds) where, in the event that a global variable was assigned to during global variable initialization but never written to afterwards, it would be promoted into a 'constant expression' even if the assignment included a function call. The 'constant expression' was then inlined every time the global was referenced. This behavior was erroneous as replicating the function call changes program behavior and can in some cases lead to stack mismanagement (which was the original issue ShadowM reported). This issue only occurred if optimizations were enabled.

2) There was a seperate longstanding and very subtle bug in the compiler (also in the PRC builds) where assigments to global variables during global variable initialization would use an incorrect stack offset in the event where the global variable initialization expression referenced another global variable, and the initialization expression was of the optimized form (enabled if optimizations are turned on) and not the 'traditional' form used by the BioWare compiler. The issue occurred because the compiler was not correctly taking into account that, while traditional initialization results in storage space for the variable being reserved at the start of the initialization expression, optimized initialization results in storage space for the variable being reserved at the end of the initialization expression. As a result, references to globals during optimized global initialization would read the wrong global. This bug was hidden by the fact that, due to the global constant expression optimization issue, most of the global references that would be impacted were being inlined out of #globals.

3) There was an additional separate longstanding bug in the compiler (also in the PRC builds) where assignments of a variable to itself during initialization would not work correctly if a constant or global was involved. This was also partially hidden (in some cases) by the global constant expression optimization bug.

I've made the following code generation changes to fix these problems:

- The compiler scans the initialization expressions of all globals to determine whether a function call, action service handler call, or internal compiler intrinsic call is present before permitting promotion of the global to a constant expression. This fixes the issue with globals that involved function calls causing the function call to be improperly replicated to each call site if optimizations were enabled.

- When processing a global variable initializer, the compiler now correctly takes into account whether storage space for the global variable on the execution stack is logically allocated at the start of the expression or at the end of the expression. This fixes the problem with global initializers that referenced other global variables working improperly if optimizations were enabled (and the global wasn't treated as a constant expression).

- When processing a variable initializer expression where the variable being initialized is referenced within the expression itself, the initializer expression is forced to the traditional, non-optimized form so that stack space for the variable is available throughout the expression. This allows operators that operate on the variable to work correctly even if optimizations were turned on.

Additionally, the compiler previously did not allow default initialization for some esoteric corner cases such as "struct mystruc global1 = global1;" that the BioWare compiler permits (though not particularly usefully); these are now allowed.

Modifié par SkywingvL, 26 juin 2011 - 04:38 .

[ShadowM]

Ok took a break from playing pen and paper D&D with friends and checked on this. I tried the new ndl and everything seem to be working. This is with just some quick tests before going back. Thank you for you hard work tracking this all down. I do some more testing and give some more feedback some time tomorrow. Thank you again.

[virusman]

New release!
NWNTX Compiler 1.0.2
http://data.virusman...piler-1.0.2.rar
Added an ini file to enable/disable compiler optimizations and extensions.
Also, the compiler now generates debug data if it's enabled in nwtoolset.ini.
New compiler dll and msvcr100.dll are bundled with the package.

Modifié par virusman, 26 juin 2011 - 09:23 .

[FunkySwerve]

Had a thought, though this isn't entirely compiler related. Figured I'd mention it on the off chance it was workable with NWNTX, and not too complicated.

At present, the toolset does not recognize function comments in this format:

/* Return a StringList struct containing strings extracted from sString
 * separated by sSep. */
struct StringList GetStringList (string sString, string sSep=" ", int nLimit=16);

/* Return an IntList struct containing integers extracted from sString
 * separated by sSep. */
struct IntList GetIntList (string sString, string sSep=" ", int nLimit=10);

/* Justify a string to a given number of pixels wide. */
string JustifyString (string sStr, int nPixelWidth, int bRight=FALSE, int nFont=0, string sJustifyWith=" ");

/* Return either the resref or playername of oObject. */
string GetObjectString (object oObject);

/* Return vPos in string form X, Y, Z. */
string GetPositionStringFromVector (vector vPos);

They simply won't appear in the help section - only // comments will. Unfortunately, we use an auto-formatter which converts comments to the /* */ format. Any chance there's a magic switch you can flip somewhere? I know this is pretty nitty gritty stuff without much broad utility.

Funky

[virusman]

This change is not trivial, in fact replacing the compiler is much easier task because it doesn't involve UI.

[ShadowM]

Sorry for not reporting back sooner, but everything seem to be working great from my testing. The new system is great. Thank you SkywingvL and virusman for putting this out and fixing everything.

[Karvon]

Yes, indeed. This sort of work often goes unappreciated by most, as players don't directly see the results like they do with most new CC.

Regards

Karvon

[SkywingvL]

New compiler DLL: http://valera-ext.ny...CompilerDll.ndl

Changes include:

- The 'const' qualifier is now forbidden with struct declarations (compliance improvement)
- Compilation performance in extensions mode is significantly improved relative to the previous build that introduced preprocessor conditional comilation support
- Overall compliation performance for larger scripts is slightly improved due to some tweaks to the compiler's symbol hash table.

[ShadowM]

Full compile no errors, no error so far testing in game. Wow nice, around twice as fast as bioware compiler now. Around 25 seconds full compile with yours and around 50 with bioware base. Thanks.

[FunkySwerve]

SkywingvL wrote...

New compiler DLL: http://valera-ext.ny...CompilerDll.ndl

Changes include:

- The 'const' qualifier is now forbidden with struct declarations (compliance improvement)
- Compilation performance in extensions mode is significantly improved relative to the previous build that introduced preprocessor conditional comilation support
- Overall compliation performance for larger scripts is slightly improved due to some tweaks to the compiler's symbol hash table.

Does this build include the #pragma defaulting functionality as well? I haven't seen you mention it outside of pms. We're still running error-free, by the way.

Thanks,
Funky

[SkywingvL]

Yes, it does.  It's up to the toolset plugin to ask to enable it (but I believe the NWN1 plugin does).

Modifié par SkywingvL, 28 juin 2011 - 03:09 .

[Sylrae]

Hmm.

When I try to run it I get "MSVCS100.dll is not a windows image". (Running on XP Pro SP3)

[Karvon]

This was working for me, till today I'm now getting an error message when I try to run it...

"Windows can not access the specified device, path or file. You may not have the appropriate permissions to access the item."

Grrr

Karvon

[SkywingvL]

Have you made any configuration changes to your computer since it last worked?

[Karvon]

Did some routine monthly sw updates, but nothing really significant that I remember. I've checked thru my various security programs logs thinking maybe one of them might be the culprit, some sorta false virus/trojan problem, but didn't see anything noted.

I tried redownloading and reinstalling the program a couple of times, but that didn't make any difference.

Quite puzzling to me.

Karvon

[Thayan]

SkywingvL, I apologize for never getting back to you in regard to my issue. I banged my head against a wall for ages and I think I have figure out what the problem is/was with my issue.

Say you have a simple script -

#include "test_inc"
int StartingConditional()
{
  object oPC = GetPCSpeaker())))))))))))));
  return TRUE;
}

And the test_inc script looks like this:

void TestFunction(object oPC)
{
  //whatever this function does, etc, etc
}

/*IMPORTANT: Make sure you end this script with comments that start with the forward slash-asterisk at the end of it, but don't close it!!!!

If there is a /* at the end of the include, but no */ to close it up, it will allow the obviously messed up script above to compile without a problem! I'm not a coder or scripter by trade, so I assume just having a /* is not recommended practice. But it appears that was causing all of my scripts using this 'bad' include to compile without errors, when really they were not compiling at all. I'm not sure if it is something you can fix, but I just wanted to let you know.

Thanks - and again, this kicks butt!

Modifié par Thayan, 18 juillet 2011 - 05:07 .

[Baaleos]

Im happy to say the latest version of the NWNTX Compiler is not leaving scripts out now.

It even caught a problem that the normal bioware debugger wasnt helping me out with much.


I had declared

void FunctionName(int arg1,int arg2);


and then called it via

object = FunctionName(int arg1,int arg2);


and having the definition as

object FunctionName(int arg1, int arg2)
{


}




When run in the bioware compiler, it returned a non-helpful message of

Unknown identifier ()

with no line number.


With the new compiler, it told me the line number, and function causing the problem.

Modifié par Baaleos, 18 juillet 2011 - 10:13 .

[SkywingvL]

Thayan wrote...

SkywingvL, I apologize for never getting back to you in regard to my issue. I banged my head against a wall for ages and I think I have figure out what the problem is/was with my issue.

Say you have a simple script -

#include "test_inc"
int StartingConditional()
{
  object oPC = GetPCSpeaker())))))))))))));
  return TRUE;
}

And the test_inc script looks like this:

void TestFunction(object oPC)
{
  //whatever this function does, etc, etc
}

/*IMPORTANT: Make sure you end this script with comments that start with the forward slash-asterisk at the end of it, but don't close it!!!!

If there is a /* at the end of the include, but no */ to close it up, it will allow the obviously messed up script above to compile without a problem! I'm not a coder or scripter by trade, so I assume just having a /* is not recommended practice. But it appears that was causing all of my scripts using this 'bad' include to compile without errors, when really they were not compiling at all. I'm not sure if it is something you can fix, but I just wanted to let you know.

Thanks - and again, this kicks butt!

You should get a warning if you have an unmatched comment at the end of the translation unit.  Perhaps virusman can chime in on how warning-only notifications are communicated to the user with the NWN1 toolset integration.

[virusman]

All warnings go to logs/nwntx_compiler.txt