x86 Instruction Support

(work in progress)

Base Includes:

Making sense of the instruction support within fasmg is a walk down x86 memory lane. Early on, advancement came in the form of a secondary processor for floating-point calculations (8087). The secondary chip was coupled with extensions to both over the years. We can see that in the first two groups below. [The arrows indicate the file on the left include other files - forming dependent branches.]

At the 80386 we have such a substantial change that Tomasz Grysztar has decided to break the dependency - which doesn't happen again until the amd64 extension (file x64.inc). Also of note, is the merger of x86 and x87 into a single processor with the P5.

8086.inc
80186.inc -> 8086.inc
80286.inc -> 80186.inc
80386.inc
80486.inc -> 80386.inc

8087.inc
80287.inc -> 8087.inc
80387.inc -> 80287.inc

p5.inc -> 80486.inc, 80387.inc
p6.inc -> p5.inc

x64.inc -> 80387.inc ext/sse2.inc

Map of x86 Extension Includes:

Here we begin with a very long dependency branch from AVX2 to MXX. (With a slight branch for xsave.) Note that amd64 support includes SSE2 - merging the middle of this branch to the main trunk!

mmx.inc
sse.inc		-> mmx.inc
sse2.inc	-> sse.inc
sse3.inc	-> sse2.inc
ssse3.inc	-> sse3.inc
sse4.1.inc	-> ssse3.inc
sse4.2.inc	-> sse4.1.inc
avx.inc		-> sse4.2.inc	xsave.inc
avx2.inc	-> avx.inc

Independent Addons

As you've gather by now the x86 instruction map is a mess. These little leaflets (continuing the tree metaphor) sprout in various places depending on the processor being coded for and aren't strictly required by previous extensions - their support is tied to a CPUID flag.

smx.inc
rdtscp.inc
cet_ibt.inc
hle.inc
rdrand.inc
rdseed.inc
ptwrite.inc
movdiri.inc
fsgsbase.inc
movdir64b.inc
adx.inc
xsave.inc
rtm.inc
vmx.inc
cet_ss.inc
mmx.inc
mpx.inc

bmi1.inc	-> avx.inc
bmi2.inc	-> bmi1.inc
f16c.inc	-> avx.inc
fma.inc		-> avx.inc

pclmulqdq.inc -> AVX
	sse.inc

gfni.inc -> AVX_512 or AVX
	sse.inc

aes.inc -> AVX
	sse.inc
vaes.inc -> AVX_512 or avx.inc
	aes.inc

vpclmulqdq.inc -> AVX_512 or avx.inc
	pclmulqdq.inc

AVX512 addons (all linked to avx512f.inc -> avx2.inc)

The Wikipedia article has a lengthy write-up on AVX512. fasmg has a common set defined in avx512.inc, but any individual extension can be included by itself due to the variability of support in processors.

	avx512_4vnniw.inc
	avx512_bitalg.inc
	avx512_ifma.inc
	avx512_vbmi.inc
	avx512_vbmi2.inc
	avx512_vnni.inc
	avx512_vpopcntdq.inc
	avx512bw.inc
	avx512cd.inc
	avx512dq.inc
	avx512er.inc
	avx512pf.inc
	avx512vl.inc

avx512.inc
	avx512f.inc	avx2.inc
	avx512cd.inc
	avx512vl.inc
	avx512bw.inc
	avx512dq.inc
	avx512_ifma.inc
	avx512_vbmi.inc

Transitioning From Other Languages

How do these instruction groupings compare to compiler (gcc/clang) options?

In most cases the naming is the same or very similar:

		clang option		fasmg file
		-mpclmul		pclmulqdq.inc
		-mx87			8087.inc
		-m80387			80387.inc
		-mpopcnt		sse4.2.inc
		-mlzcnt			bmi1.inc

For some options fasmg has the instructions in the core set: -msahf, -mfxsr, -mcx16, ...

Not present in fasmg are some of the most recent extensions and some legacy AMD extensions (3dNow, LWP, XOP, SSE5, TBM). Looking at the plentiful examples, it's not too difficult to add instructions when needed.

Q & A - Question and Answer:

• Downloaded fasmg, but only get errors when including additional instruction support?

This can happen in a couple instances that I'm aware of. Especially for 32-bit, the default processor support in /fasmg/packages/x86/include/format/format.inc is P5.inc, and would need to be changed:

include 'x64.inc'
use32

Another case is the need for /fasmg/packages/utility/xcalm.inc.