Move the editor help files (currently nasmtok.el) to the editors/
subdirectory in anticipation of having more such files.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Use a really hacky way to run the NASM binary and extract automatic
builtin macros. As this is not something normally supported during the
NASM build process, the output is canned and will need to be run
manually.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Resolved Conflicts:
misc/emacstbl.pl
This also reverts the token names to the version without the -token-
infix.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
- Add improvements to omfdump from Bernd Böckmann.
- Add misc/Makefile with option to install omfdump and auxiliary NASM
data files.
- Use compiler.h and friends in the misc directory.
- Use -std=c23 if the C compiler supports it.
Cc: Bernd Boeckmann <bernd-github@boeckmann.io>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Include the version number in the output (misc/nasmtok.el) and add a
rule for generating it to the Makefiles.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add a simple script to auto-generate token lists for an emacs major
mode, e.g. https://github.com/skeeto/nasm-mode
It is recommended to use "require" this file separately from the main
code, so it can be automatically kept up to date.
If this ends up being used, I will include the generated result in the
NASM release distribution.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There is absolutely no reason not to include <string.h> globally, and
with the inline function for mempcpy() we need it there anyway.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Currently out code is rather a mix of space/tabs
with sometime different indent level. Mostly because
some of developers are came from kernel space. Lets
shift to kernel coding standart with small steps,
file by file. It really helps when you're sitting
in front of laptop more than 10 hours long.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Some OMF toolchain can make use of file dependency information
embedded in the object files. As implemented here, we don't try to
absolutize the filenames, as that prevents moving around trees and is
OS-dependent.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Make the source code easier to understand and keep track of by
organizing it into subdirectories depending on the function.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
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.
