On Wed, 12 May 2010, Szak�ts Viktor wrote: Hi Viktor,
> > I thought that you want to introduce full separation of compiled > > PRG modules specified at command line so hbmk2 which now passed > > all prg modules to harbour compiler in single call can be safely > > used without any interactions between compiled files. > Not to hack, but solve. IMO #pragma settings and > macros are two different issues, though for me > it's not a problem to handle them together and > come up with a fuller solution. The only problem > is that I can't really add any valuable input to > the macro side. > My only slight, and maybe not justified concern > is that if we reset everything between files, it > may cause a performance hit compared to current > state, at least it looked like so by reading your > prev mail. IOW, I don't know how much do we want > to complicate this and introduce undesired > side-effects, other than that a full solution is > always a good thing. the #pragma low level behavior strictly depends on current compiler implementation. It may change in the future or may need some completely different implementation for modified compiler code so it should not be sth what we can define as strict part of language because we can block farther modifications, i.e. current behavior of -km switch needs online PCODE generation, if we add support for multiline expressions to intorduce interline optimizations on expression level (now we only have them in very limited way operating on generated PCODE) then this switch will stop to work and to implement it we will have to make some deeper compiler modifications and decide what is the expected behavior for code generated for merged lines when some of them were compiled with and some other without -m optimization. Some other pragmas effects only some chosen compiler phases and it's less important where they are located in the source code, i.e jump optimization (-kj) is executed after compiling whole function in PCODE generated for full function body. In the future we may introduce inter procedural optimization or even inter module optimizations. It means that we may have pragmas with such scope so there is no clear "solution" that we can reset all pragams between modules. Now some pragmas has effect only on newly compiled modules, i.e. -n. If we add resetting for all pragmas then support for -n does not make any sense and should be removed. If you want the we can add such resetting but in such case we should start from updating current list of programs to check which are usable in such case (I hope that so far no one used current functionality using files with compiler pragma settings without real code to control switches between compiled modules). Anyhow I would like to note that this may change in the future and such functionality cannot be sth what may block farther compiler optimizations. The cost of resetting PP should be acceptable if user does not use -u harbour compiler switch with his own long list of PP directives in .ch file. Parsing such .ch file for each .prg module for sure will be noticeable in the total compilation time. BTW we can also introduce #pragma push/pop which can be used by user to resolve the problem of interaction between compiler switches in much more flexible way. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
