There are special tools (like valgrind and etc)
to track memory leaks, no need for own trivial
tracker.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
asciidoc/xmlto are not tools we require every users to have, so each
tarball should contain them. That means the release script needs to
know about them.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Use the -9e compression level when doing xz compression. It only
saves a few kilobytes, but since our files are pretty small it doesn't
really take all that much time.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
In case if the commiter has a main repo configured as remote
one and also has various tags (and don't want to push every
tag he has out to the main repo) he may use misc/tag-release
new functionality.
For example I have NASM remote repo as well known
git://repo.or.cz/nasm.git
and a number of my own local tags/branches which I
would like to not sprinkle into a master repo.
So to make a release (say 2.08) I may just type
misc/tag-release 2.08 git+ssh://xxx@repo.or.cz/srv/git/nasm.git master
and this command will push master branch into main repo with "nasm-2.08" tag.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
A so-called "generalized CRC" is a form of hash function based on a
table similar to the conventional bytewise software implementation of
CRC. For each byte in each data set, it contains a random
byte permutation table.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Small utility program to generate CRC tables in both C and Perl
formats. Note: we don't actually need a true CRC, which is what this
generates. We may want to consider going to a "generalized CRC",
meaning a randomly generated set of 8 bytewise permutations. These
have the advantage of not being linear, while having the same software
implementation as a true CRC.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Beginnings of a crude utility to dump the contents of an OMF (obj)
file. At this point all it does it breaks it down into the individual
records and dumps those, but it is still easier to read than a pure
hexdump.
See http://www.azillionmonkeys.com/qed/Omfg.pdf for the format spec.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Two bugs with respect to the FMA instructions:
- the variant increment is supposed to be 0x10, not 0x01.
- the base opcode for scalar VFNMADD is 0x9d, not 0x9c
The Perl script which auto-generated the VFM instructions had
incorrectly conflated the VEX.W and VEX.L bits, with the result that
only half the valid instructions were generated.
1. Allow included files in rdsrc.pl
2. New program inslist.pl to generate instruction list from insns.dat
3. Mark certain comments in insns.dat as documentation subheaders
4. Add Instruction List appendix to nasmdoc.src
5. Update build process to invoke inslist.pl
Intel's docs diverge from AMD's docs (MASM follow AMD's docs);
formally document what we're doing and include a file of macros in
case someone wants to use alternate names.
The current version of "git tag" seems to demand that the options
precede arguments; the name is an argument, but the -m option and its
parameter is an option.
actually *use* the resulting configuration file, but it keeps autoconf
from creating an insanely long compiler command line, which can cause
problems all by itself. Eventually we can do:
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
... to get the same information.
