Add a "nohi" code flag for the \325 byte code, which sets the REX_NH
flag. That is, REX_P not required to support high registers, high
registers are not supported and spl/bpl/sil/dil enabled even in
non-64-bit mode.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The global symbol offset is a loop invariant; no need to compute it
over and over. The compiler probably will not be able to do this for
us due to global variables and function calls.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Clean up the arithmetic for global symbols; in particular, make it
clear where the dependency on the debug format comes from (DWARF needs
three symbol table entries all by itself.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Bump GLOBAL_TEMP_BASE so far that it *cannot* conflict for ELF32
(which has 24-bit symbol table indicies) and is *unlikely* to conflict
for ELF64 (which has 32-bit symbol table indicies.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Eliminiate hard-coded section numbers, at least to the best of our
ability. There is still a very odd piece of computation in
elf_build_reltab() which I can't really figure out...
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The dependency machinery relies on properly rooted includes, so give
it to them... the path syntax munging machinery in the dependency
script handles it from a Makefile syntax perspective, and then we can
hope that C compilers are smart enough to deal with forward-slash
paths even when that is not the native syntax.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add something approaching real ELF header files.
Begin merging the common ELF code, beginning with the section name
detection.
Drop automatic generation of .comment section, and in particular the
treatment of .common as a special section (if we decide generating
.comment is still a good idea, we should just do it as a macro.)
Augment the list of known sections, and make it table-driven.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add a byte code to explicitly support instructions which only uses the
low 8-bit registers (as if a REX prefix always was present.) This is
usable for instructions which are officially documented as using "the
low byte of a 32-bit register" and so on.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Change the relaxed forms to the compact representation. This
*deliberately* does not fix bugs where the relaxed form does not match
the official form; this is strictly a "no change in output" checkin.
All remaining open-coded relaxed forms are very likely bugs, and need
to be individually audited. Furthermore, it is questionable if the
Intel FMA instructions, being destructive, should have relaxed forms
at all.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Allow a * to be put on an operand, indicating that it is optional and
should be replaced with the immediately preceding operand if it is
omitted. This allows official and relaxed forms of nondestructive
instructions to be written on one line.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
1) A number of PMA -> VPM misprint fixed.
2) Spec points to ymmreg in mnemonics even for L=0 instructions. Fixed.
The instructions are still sorted in order of specification follows.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Introduce base XOP/FMA4/CVT16 instructions (SSE5)
based on official specification from AMD (rev 3.03).
Some fixes from Peter Johnson and H. Peter Anvin
included (not updated in AMD spec yet).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We already have such kind of aliases for L field
(via l0 and l1). Via p0,p1,p2 it's become easier
to follow AMD docs while encoding VEX/XOP commands.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Preexisting code seems to rely on %+ being processed even during early
token replacement, e.g. Syslinux contains the following code:
%macro superb 1
bx %+ %1 equ SuperInfo+($-superblock)*8+4
bs %+ %1 equ $
zb 1
%endmacro
... which is expected to work when invoked as:
superb Media
As a result, set handle_paste_tokens to true at all times; assuming
this turns out to be the way things are we can really just remove it
as an option.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Use lower case for VEX and XOP ("vex", "xop") to avoid visual
confusion (and in the future potential real confusion) with upper-case
hexadecimal numbers.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Handle AMD's XOP prefixes; they use basically the same encoding as VEX
prefixes, so treat them simply as a variant of VEX.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Some vendors get nervous about parameterized printf patterns;
furthermore, it's completely unnecessary in this case.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Unify the token-pasting code between the macro expansion and the
preprocessor parameter case. Parameterize whether or not to handle %+
tokens during expansion (%+ tokens have late binding semantics.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Recognize $ and $$ as TOKEN_OTHER; they aren't really either
TOK_NUMBER nor TOK_ID, even though we have traditionally considered
them TOK_NUMBER.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
"+" can be a separate token that ends up having to get pulled into the
middle of a floating-point constant. It's not even that strange.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Especially when token pasting involves floating-point numbers, we can
have some really strange effects from token pasting: for example,
pasting the two tokens "xyzzy" and "1e+10" ends up with *three*
tokens: "xyzzy1e" "+" "10". The easiest way to deal with this is to
explicitly combine the string and then run tokenize() on it.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
