Without a manifest, Windows applications force a fixed PATH_MAX limit
to any pathname; this is unnecessary.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Comment was missing a semicolon; fix to avoid unnecessary warning and
to make sure the documentation is generated correctly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
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>
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>
