195 réponses à ce sujet

[SkywingvL]

henesua wrote...

For the record I have noticed that declarations and implementations of functions can differ in other ways as well, and not generate compile errors.

With the new compiler or the standard one?  The standard one does not check many things.  I'd like to hear what the remaining unchecked mismatches are for the new compiler.

(Different identifier names for parameters don't count; I consider that by design and C/C++ certainly permit that.)

[SkywingvL]

I am adding an additional pragma extension:

#pragma pure_function(function-symbol-name)

For example, #pragma default_function(foo)

The function-symbol-name must be declared as a function before the pragma is parsed. The effect of the pragma is to mark the function as having no side effects in the compiler. This allows the compiler to optimize calls to that function away in certain cases (currently the optimizer's dead subexpression optimization is very limited, however; if someone is interested in contributing a better optimizer framework, there's some infrastructure to use it). It also allows a non-const global variable whose initializer expression involves a call to foo to be considered for making the global variable an inlined constant if the global was suitable.

This may change program behavior if applied incorrectly. A function tagged as a 'pure function' must not modify any globally visible state, i.e. it should not write to global variables or call functions that modify global state or call engine functions that modify global state. The compiler doesn't enforce any of these rules, it is up to the programmer to only tag appropriate functions.

For an example, consider the following:

int purefunction(int x, int y) { return x + y; }

int global1 = purefunction(1, 2);
int global2 = purefunction(global1, 3);

void main()
{
if (d100() < 50) return;
PrintInteger(global2);
}

Without the pure_function declaration, global2 is created as an actual global variable and its initialization code runs every time before main(). With the pure_function declaration, global2 (because it is not written to and follows the other rules for inline promotion eligiblity) is not created as a global if optimizations are turned on; instead, its initializer expression is substituted in every place global2 is referenced.

Modifié par SkywingvL, 21 janvier 2012 - 11:20 .

[SkywingvL]

Release 10 posted of the Advanced Script Compiler. Direct download link (same as always): http://www.nynaeve.n...iptCompiler.zip

You may use NWNScriptCompiler.ndl from the 'ToolsetPlugin' directory with NWNTX for NWN1. The standalone compiler EXE is also updated.

Release 10:
-----------

- A longstanding bug dating back to nwnnsscomp, where global variables that
were readonly and had initializers with assignments might be improperly
inlined if optimizations were enabled, has been fixed.

- The compiler can now optimize away dead sub-expressions in simple cases, such
as multiplication by zero or shift by 32 bits.

- The compiler can now optimize a multiply operation into a shift by power of
two.

- The compiler can now optimize addition by one and subtraction by one into a
decrement or increment operation.

- The compiler now issues a new warning, NSC6023, should function prototypes be
declared for the same function but with conflicting literal values for a
default value argument. It is legal for a prototype that does not set a
default value for an argument to follow a prototype that does set a default
value for an argument, but if a default value was set, it must match.

- A new pragma directive, #pragma pure_function(function-identifier), is now
supported. This pragma hints to the compiler that function-identifier, which
must be an already-declared function symbol, does not modify global state and
generates no side effects. This enables calls to the function to be elided
in certain circumstances, or for global variable initializer expressions that
invoke the function to be inlined in certain circumstances.

The programmer bears responsibility for ensuring that pure_function tagged
functions actually follow the rules for a pure function. Otherwise, program
behavior may be incorrect.

[henesua]

SkywingvL wrote...

henesua wrote...

For the record I have noticed that declarations and implementations of functions can differ in other ways as well, and not generate compile errors.

With the new compiler or the standard one?  The standard one does not check many things.  I'd like to hear what the remaining unchecked mismatches are for the new compiler.

(Different identifier names for parameters don't count; I consider that by design and C/C++ certainly permit that.)

NWNScriptCompilerDll.ndl    11/20/2011
nwntx_compiler.dll                   6/26/2011
nwntx_optimizations.dll           12/13/2011

Yes, different identifier names
 (of function vars) . C/C++ may permit that, but I don't believe the functions work properly in compiled NWScript if the identifiers are different. I haven't pinned this down but I recall my script was not working properly when these were in disagreement.

[edit: crap! I wish this forum would let you know when another reply has been posted since you clicked reply...]

Modifié par henesua, 22 janvier 2012 - 12:18 .

[SkywingvL]

The functions should work properly if the identifiers are different. The identifier is just a local name; compiled NWScript accesses functions arguments by position and not name.

Can you show the differing disassembly (and, preferably, .ir-opt) for a function that is behaving differently based on differing identifier names in the prototype versus implementation? Use the -d option to disassemble a script and generate the .pcode, .ir, and .ir-opt files.

[Rolo Kipp]

<holding his head...>

SkywingvL wrote...
Release 10 posted of the Advanced Script Compiler. Direct download link (same as always): http://www.nynaeve.n...iptCompiler.zip

You may use NWNScriptCompiler.ndl from the 'ToolsetPlugin' directory with NWNTX for NWN1. The standalone compiler EXE is also updated.

...

Ok. Now I'm confused. <normal, isn't boss?> Hush.

Disclosure: I've avoided installing NwNTx simply because the oToolset has been "good enough". Finally convinced that I *need* this, I installed it (root NwN directory). Cool :-) I *like* it.

Now, having gone that far and having ASCv10 sitting around...
Wait. Toolset directory for NwN1? Plugins directory? Don't exist.
Also, in the NwNTx toolset I see no options for plugins.

To upgrade the ASC that Virusman includes in 1.0..5, do I just overwrite the NWNScriptCompilerDll.ndl? That is, there is nothing else I need do and that will break nothing?

<...so it doesn't explode>

[eeriegeek]

Rolo,

I just started playing with this and couldn't find installation instructions for NWN1 either. I just put all the NWNTX files in the main NWN directory and then overwrote the ASC dll with the new version. That seems to be working fine, everything compiles, and I get new logs with new compile warnings and such.

I do have one weird bug with NWNTX. The "Show Preview Window" tool now only shows the last item selected from the palette, not the the last item selected in the editing window. Normally you can select any item in the area and click on "Show Preview Window" to see its resref and such. With NWNTX running, clicking on an object and clicking Show Preview Window just shows a blank window until you select something from the palette. Then it only shows that item in the preview until you click another palette item even if you click on other objects in the area editing window. Loading the same module without using the launcher goes back to the normal behavior.

[wyldhunt1]

SkywingvL focuses mostly on the NWN2 version. He has a DLL that works in NWN by placing it in the NWN install folder.
You need Virusman's latest install first. Check page.. 5, I think? for his newest NWN1 version. If you want, you can overwrite the DLL with SkywingvL's newest version. Virusman's is the override for NWN1 toolset though.

EDIT:
Here:
http://social.biowar...45830/5#8824390

Modifié par wyldhunt1, 09 février 2012 - 07:39 .

[Rolo Kipp]

<nods...>

Yup, had that, but was unclear if overwriting the NWNScriptCompilerDll.ndl was sufficient.

Thanks both.

<...thanks>

[Calvinthesneak]

virusman wrote...

NWN Toolset Extender 1.0.0 + Compiler plugin
Required CRT: http://www.microsoft...ls.aspx?id=5555
Download: http://data.virusman...piler-1.0.0.rar
Install: Just unpack the files to your NWN folder and use NWNTX Loader.exe to launch the Toolset. The compiler will be switched seamlessly.
Thanks a lot to Skywing for the help and for his compiler library.

There's your instructions.

[Rolo Kipp]

<donning barrister lenses...>

Thank you CtS :-) I do appreciate people who try to be helpful.

Technically, however, those instructions imply that whenever I "use NWNTX Loader.exe to launch the toolset, the compiler will be switched seamlessly". Er, I *could* assume that means the AdvancedScriptCompiler v8 (ASCv8) that he bundled with 1.0.5 would automatically update itself to ASCv10... ;-) Now, I understand that *actually* means the bundled ASCv8 will be used in place of the bioware compiler.

That wasn't, however, the *precise* instructions I was looking for.

Specifically, Skywing said:

You may use NWNScriptCompiler.ndl from the 'ToolsetPlugin' directory with NWNTX for NWN1. The standalone compiler EXE is also updated.

This confused me as there *is no* toolset/plugin directory with NwN1. I *think* he meant NWN2.

Eeriegeek and Wyldhunt assured me that simply overwriting the v8 NWNScriptCompilerDll.ndl with v10 was sufficient.
And it is :-)
Works like a charm.
So far.

<...and overlooking them>

[wyldhunt1]

I think the ToolsetPlugin diectory that he was refering to in that sentence may have been the ToolsetPlugin directory in the downloaded RAR. If I remember correctly, the RAR has a folder named ToolsetPlugin (For ease of use w/ NWN2) which contains the NWNScriptCompiler.ndl.

So, I translate that quote as

You may use NWNScriptCompiler.ndl from the 'ToolsetPlugin' directory in the RAR with NWNTX for NWN1. The standalone compiler EXE has also been updated.

Modifié par wyldhunt1, 10 février 2012 - 09:39 .

[Rolo Kipp]

<nods...>

Makes more sense than a typo on Skywing's part :-P
Confused me, it did. <we know>

<...considerately>

[Calvinthesneak]

Dunno if this is a problem on my end or the compiler. I got this error opening an area, so probably nothing that Skywing/Virusman can control.

[Cryolithic]

Hmmm, this^^ name here seems familiar

[The Amethyst Dragon]

Just gotta say I'm liking the updated compiler. When it gives me error messages, it give much more detailed information than the default script compiler, making it easier to track down and fix what I messed up.

[Shadooow]

seems that compiler uses linux newline would be possible to fix it so it does break lines even at windows? its a bit mess when there is more errors as new compiler doesnt report only one error

[SkywingvL]

The script compiler core itself is agnostic as to whether it is used with NWN1 or NWN2.

NWNScriptCompilerDll.ndl is the dynamic linked (DLL) version of the compiler core that I produce. Both the Advanced Script Compiler NWN2 toolset plugin I produce, and NWNTX NWN1 toolset plugin which virusman produces, consume this compiler version for toolset integration.

When I release a new version of the compiler, it is typically in the form of a new Advanced Script Compiler bundle (including standalone (exe) version, and DLL version for the toolset plugins). You can take NWNScriptCompilerDll.ndl from a new ASC release and drop it in for use with NWNTX to pick up the new compiler itself. Typically, virusman will also package an updated NWNScriptCompilerDll.ndl into his NWNTX distribution, but the module is compatible with both the NWN2 and NWN1 toolset plugins.

[SkywingvL]

Calvinthesneak wrote...

Dunno if this is a problem on my end or the compiler. I got this error opening an area, so probably nothing that Skywing/Virusman can control.

This is not an assertion from the compiler core itself.  Either it is an assertion in the NWN1 toolset itself (this would be my guess) or from within NWNTX.  It's probably something that virusman is best suited to look at as he is the most familiar with the NWN1 integration work that he's done.

Modifié par SkywingvL, 15 février 2012 - 07:33 .

[SkywingvL]

ShaDoOoW wrote...

seems that compiler uses linux newline would be possible to fix it so it does break lines even at windows? its a bit mess when there is more errors as new compiler doesnt report only one error

The standalone (EXE) version of the compiler displays errors properly here.  That is a standard function of the console I/O functions.

If this is within NWNTX, it's probably best something for virusman to take a look at and reformat the line endings of the compiler core to be what the NWN1 toolset expects (whatever that happens to be for whatever GUI element is in used).  The compiler core puts a \\n at the end of message lines that it returns to the host program and that could be mapped to whatever is desired by the host program for its GUI purposes.

Modifié par SkywingvL, 15 février 2012 - 07:33 .

[Shadooow]

have issues with the hak loading problem, haks sometimes wont properly re-load even after I restart toolset and anytime I want to edit creature/door I end up with access violation. Thats very annoying and I had to stop using the NWNTX because of that, often I need to switch between two modules and it always mess with haks, very bad...

[virusman]

NWNTX Optimizations plugin has always been in experimental state, with this exact limitation: do not load another module when NWNTX Optimizations is running. If you have to switch between modules frequently, either restart the toolset every time or do not use NWNTX Optimizations.

Modifié par virusman, 12 avril 2012 - 05:11 .

[Carcerian]

Best... thread... ever...

Just found this thread, installed the C++ libs, Virusman's 1.0.5 build, then SkywingvL's upgrade...

(just in case, rather than replacing stuff, i backed up everything...)



Loaded NWNTX Toolset, and oped PW.mod...

First Impression: WOW! Areas load soooo much faster...

Second: And they save faster too!

Trying compile scripts...



(heh, bet i know what that is...)

Tried subrace demo same results.

Tested a few simpler mods, compiled fine, tested great.

(Ok, no biggie, shayans pushes the limits, multiple authors, does database functions, flagsets and letoscript, kinda expected...)

Rolled back to Virusmans 1.0.5 and PW and Shayans both compiled perfectly.

Tested both vers on lots more demos, not a single error otherwise...

(so guess better gotta go back over shayan code, asap...)

Most important, is the end result, pw loads faster and it runs lots smoother, in addition to the toolset.

Final Impression: This makes the toolset work the way it should have all along. Well worth it!

Modifié par Carcerian, 13 mai 2012 - 11:26 .

[SkywingvL]

Are you using a computer without support for SSE2 (i.e. Athlon XP or other very old processor)?

[Carcerian]

SkywingvL wrote...

Are you using a computer without support for SSE2 (i.e. Athlon XP or other very old processor)?

Yes.

I've been testing this a lot since i posted, and SSE 3.0.6.9 b13 (Starry Night Build) is still the only system that makes it crash. (As previously mentioned, its a very complicated mod, so just it mentioned for the sake of debugging.)

Shayan's compiled fine with V-Man's 1.0.5 build, and as far as i can tell it seems to run much smoother now...

All in all, awesome work guys

Modifié par Carcerian, 17 mai 2012 - 08:46 .