NASM Forum > Announcements
NASM - Official Recursive Macro Support!
cm:
--- Quote from: Cyrill Gorcunov on November 10, 2010, 08:19:07 PM ---The fix pushed upstream as commit 55cc4d04235cb884a885682b5a52f367ec7d50c3.
Please give it a shot by using nasm snapshot. Thanks for report!
--- End quote ---
Okay, that appears to fix this problem. (Though I had to recompile on my own using OW 1.9 and the OW makefile doesn't contain the perl commands and I had to execute these manually.)
I see other issues now: Assembling my project will take a lot longer than with previous releases. During that time, NASM uses up to 50% CPU time (as I have a dual core system, this means the core NASM runs on is fully utilized) for as long as one minute. The resulting binaries appear correct.
Notably, several warnings about unterminated strings are displayed after periods of waiting. Investigating these, I found that they were generated by "code" in %if 0 blocks, which I use for long comments because of the lacking %comment in previous releases.
Further testing reveals that replacing %if 0 by %comment where appropriate does not change anything: assembling still takes long and the "unterminated string" warnings are still displayed. (This is a minor bug. I do not want these syntax checks in %comment blocks, and arguably they shouldn't be done in disabled parts of %if either.) Even more testing (with a file that contains lots of long %if 0 or %comment blocks) reveals that the time issue does not appear related to the parsing of the commented lines that results in warnings. If I find out what exactly is causing the long delay I'll let you know.
Edit: One thing I found is that in preproc.c, line 5319 (where there is a comment "sanity check: is this supposed to be here?"), the commented function call (to free_tlist) should indeed be executed. Of course I'm not very familiar with the source, but it seems the right thing to do. Assembling my project with this line commented (as in the repo) takes about 50 seconds, and peaks at a memory usage of 70 MiB. With the line uncommented, it takes about 30 seconds and peaks at 45 MiB. Notably, with 2.10rc1 the same action takes about 3 seconds and peaks at 6 MiB. All produce the same result. So the current revision certainly has some leaks and possibly other stuff slowing it down. The mentioned function call appears to solve some of these.
Cyrill Gorcunov:
--- Quote from: cm on November 11, 2010, 12:57:31 PM ---
--- Quote from: Cyrill Gorcunov on November 10, 2010, 08:19:07 PM ---The fix pushed upstream as commit 55cc4d04235cb884a885682b5a52f367ec7d50c3.
Please give it a shot by using nasm snapshot. Thanks for report!
--- End quote ---
Okay, that appears to fix this problem. (Though I had to recompile on my own using OW 1.9 and the OW makefile doesn't contain the perl commands and I had to execute these manually.)
I see other issues now: Assembling my project will take a lot longer than with previous releases. During that time, NASM uses up to 50% CPU time (as I have a dual core system, this means the core NASM runs on is fully utilized) for as long as one minute. The resulting binaries appear correct.
Notably, several warnings about unterminated strings are displayed after periods of waiting. Investigating these, I found that they were generated by "code" in %if 0 blocks, which I use for long comments because of the lacking %comment in previous releases.
Further testing reveals that replacing %if 0 by %comment where appropriate does not change anything: assembling still takes long and the "unterminated string" warnings are still displayed. (This is a minor bug. I do not want these syntax checks in %comment blocks, and arguably they shouldn't be done in disabled parts of %if either.) Even more testing (with a file that contains lots of long %if 0 or %comment blocks) reveals that the time issue does not appear related to the parsing of the commented lines that results in warnings. If I find out what exactly is causing the long delay I'll let you know.
Edit: One thing I found is that in preproc.c, line 5319 (where there is a comment "sanity check: is this supposed to be here?"), the commented function call (to free_tlist) should indeed be executed. Of course I'm not very familiar with the source, but it seems the right thing to do. Assembling my project with this line commented (as in the repo) takes about 50 seconds, and peaks at a memory usage of 70 MiB. With the line uncommented, it takes about 30 seconds and peaks at 45 MiB. Notably, with 2.10rc1 the same action takes about 3 seconds and peaks at 6 MiB. All produce the same result. So the current revision certainly has some leaks and possibly other stuff slowing it down. The mentioned function call appears to solve some of these.
--- End quote ---
ok, new preproc code needs to be polished that is why we pushed it out early and want the feedback ;)
If this is not a secret -- what kind of project you have and if it's open-sourced mind to provide the
code so we could be able to compile it and figure out what eats cpu time.
Cyrill Gorcunov:
I read inaccurate -- you've explained what is happening. Will take a look. Thanks!
cm:
--- Quote from: Cyrill Gorcunov ---ok, new preproc code needs to be polished that is why we pushed it out early and want the feedback ;)
--- End quote ---
Eh yeah. I appreciate it I guess. It has good new features and maybe we can make the speed-ups noticeable for me too :D
--- Quote ---If this is not a secret -- what kind of project you have and if it's open-sourced mind to provide the
code so we could be able to compile it and figure out what eats cpu time.
I read inaccurate -- you've explained what is happening. Will take a look. Thanks!
--- End quote ---
Yeah, but with that it still takes multiple times longer than the revision from before the preproc-rewrite merge. So there is still some work to do. My stuff isn't ready so there are no public releases yet. But it is free software (2-clause BSD) so if you point me to where I can find your e-mail address, or write me a PM with it or something, it's no problem for me to send a current copy to you. Uncompressed it is about 600 KiB large. (It's also a program for DOS, but since the only build tool used is NASM (with multi-section bin output :)) that shouldn't be an issue for you.)
Cyrill Gorcunov:
yup, gorcunov@gmail.com
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version