Add support for VEX-encoded SHA512-NI instructions.
Signed-off-by: Tomasz Kantecki <tomasz.kantecki@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Kind of embarrassing... I had not implemented the FRED instruction,
despite personally being one of the architects of FRED ;)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Legacy backends like obj/omf may depend on the offset being zero if
not in use.
Reported-by: Bernd Boeckmann <bernd-freedos@boeckmann.io>
Reported-by: Vladimir Chebotarev <vladimir.chebotarev@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We should always support up to 8 characters, i.e. 64 bits, in a
string-to-numeric conversion.
Reported-by: Aleksandras Krupica <vaikutisasa@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Require the second colon before the grouped parameter count; otherwise
the syntax is ambiguous since an expression can start with (.
Update/complete the documentation and the examples.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add the ability to have fixed arguments in %map. This is extremely
useful for parameterizing the invoked macro using arguments to a
surrounding macro.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Separate out counting and parsing smacro parameters into separate
functions. This not only makes the code *way* easier to read, but
these can be re-used e.g. for %map().
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add the %map() function which can apply arguments to a macro from a
list.
Allow the user to specify the desired radix for an evaluated
parameter. It doesn't make any direct difference, but can be nice for
debugging or turning into strings.
As part of this, split expand_one_smacro() into two parts: parameter
parsing and macro expansion. This is a very straightforward splitting
of two mostly unrelated pieces of functionality.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The production "value := type value" was not correct; should have been
"type atom", which can be merged with the "atom" production to "[type]
atom".
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Nothing wrong, but the text of the warning message has changed after
subordinating it to another warning.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When expanding %rep blocks, if any of the %rep blocks are empty, there
may be need to unwind the %rep stack multiple times. The code would
not do so -- there was a break; in the loop, which incidentally turned
it into something that wasn't a loop at all.
Reported-by: E. C. Maslock <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Make it possible to add a base prefix to %num().
Add the %hex() function, producing hexadecimal values that are
nevertheless valid NASM numeric constants.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The user would generally expect the parameter number to be counted
from 1 for human purposes, and that is also consistent with %1, %2,
... for multi-line macros.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
%expr() was a pre-release development name for this function, however,
the released name is %eval().
See BR 3392837.
Reported-by: Michael <mikar_gibbros@yahoo.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
"LOCK XCHG reg,mem" would issue a warning for being unlockable, which
is incorrect. In this case the RM encoding is simply an alias for the
MR encoding. Add a "LOCK1" bit to deal with that.
However, XCHG is *always* locked, so create a new warning to
explicitly flag a user-specified LOCK XCHG; default off.
Consider optimizing that prefix away in the future, but for now, let's
stick to the user-requested code sequence.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The dependency list needs to be updated for all passes, not just the
last one. The dependency list is already uniquized, so it doesn't
cause problems with multiple entires.
The reasons it needs to be done for all passes is first of all that an
%include could be pass-dependent, and secondly that we only record a
dependency for an %include or %require for the first occurrence of
that file, when pathnames are resolved.
Reported-by <michael@mehlich@com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The fix for BR 3392414 introduced a fairly serious memory
leak. C. Masloch was kind enough to track down the proper root cause
and fix it correctly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Variadic macros are really useful, even if we can only use them
conditionally.
Unfortunately this means removing -Wc90-c99-compat, because apparently
-Wno-variadic-macros is broken in gcc 13.2. Fortunately it is 2023...
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Some target environments may have specific restrictions on what kinds
of relocations are possible or allowed. Allow users to opt-in to
specific warnings as to the relocations they cannot support.
Requested-by: C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
NASM would try to "eat the comma token" in db expressions, even for
cases where the token was not a comma. Fix that and error out
properly.
To give better error messages, track where in the input string a token
starts or ends. This information is only valid as long as the input
string is kept, but that is just fine for error messages during
parsing.
Reported-by: Peter Cordes <pcordes@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Exposed a bunch of problems with the autoconf m4 macro
library. Hopefulyy fix it, and tidy it up in the process.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The dependency on the warning files breaks when we are building in a
directory *and* the files already exist from being shipped with the
distribution tarballs. The make VPATH simply isn't sophisticated
enough to deal with it, so let the C compiler handle it by #including
the generated file from a dummy C file.
Reported-by: Rudi Heitbaum <rudi@heitbaum.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Things used by "make dist" haven't been updated for a while, it seems;
in particular have not kept up with the existence of autogen.sh.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
misc/nasmtok.el is a generated file.
The whole rdoff directory is obsolete; if someone still has it it can
be ignored.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
