Menu
▾
▴
#68 add support for -t <file>, as well as -bm and -bf
In my local forked version I have added support
for the -t <file>, as well as the -bm and -bf
options. While -bm and -bf buffer the output of
the preprocessor from pass 1 in memory or in a
temporary file, so that it can be re-used during
pass 2, -t <file> can be used to specify a name
for the temporary file used by -bf.
The goal of -bm and -bf is to improve overall
performance, by eliminating the need for using
the preprocessor during both passes.
The goal of -t <file> is to be able to specify
an explicit temporary file name, in case the
file must reside in a particular location, or
in case multiple instances of NASM are to be
run in parallel.
Attached find the necessary changes.
Logged In: YES
user_id=804543
Frank has pointed out that NASM 0.98.x already
uses the -t option to enable its TASM support.
(Which I've dropped from my version.)
Logged In: YES
user_id=804543
One more data point.
I have used Randall Hyde's latest benchmark generator to
spit out 10k equates, 10k data declarations, 10k macros
without arguments, 10k macros with arguments, 10k macro-
based HLL statements, as well as 10k instructions. The
resulting 18.4 MB file contains 1.32M lines, which will
expand to 1.35M lines of code.
normal operation: 91 seconds
with -bf buffering: 89 seconds
with -bm buffering: 73 seconds
This demonstrates the impact of memory allocation versus
disk performance versus preprocessing once/twice.
Logged In: YES
user_id=58697
Originator: NO
tmpfile() is in C89, so at least there is a way to allocate a nameless temporary file without a huge performance penalty. That also takes care of the "multiple instances running in parallel" issue.
Where can we find this benchmark generator? I'm curious how well the current NASM performs compared to 0.98.39. I have run a couple of my own benchmarks, and the performance of 0.99.04 ranges from slightly worse to radically better.
Logged In: YES
user_id=804543
Originator: YES
> tmpfile() is in C89, so at least there is a way
> to allocate a nameless temporary file without a
> huge performance penalty.
Unfortunately tmpnam() and tmpfile() are considered
unsafe and should be avoided -- I have encountered
numerous platforms on which GNU ld warns about this
and I have even seen actual failures. The bad part
is that they are all that's in C89, i.e. they still
present the least common denominator. :(
> That also takes care of the "multiple instances
> running in parallel" issue.
See above. This is why I added another option, for
specifying a particular temp file name. (Not very
nice for manual use, but okay for automated cases.
The latter -- i.e. multiple instances in parallel --
was failing pretty quickly for me, when I left the
temp file name in the hands of the C library.)
> Where can we find this benchmark generator?
http://webster.cs.ucr.edu/AsmTools/RollYourOwn/BM.ZIP
At least that's what I think I used back then. :)