legal: check opcodes xml license

[mmcloughlin]

legal: check opcodes xml license

[mmcloughlin]

Commit 6d6ff3c includes the license files.

[dgryski]

Can xed not yet been used?

[mmcloughlin]

Can xed not yet been used?

In retrospect, I wish I had considered XED more seriously. At the time I thought it would be easier to use existing databases with Go support: the Go arch sub-repo and PeachPy's Opcodes XML file. Unfortunately neither of these data sources are quite accurate, so some of the most ugly code in this entire project deals with merging these two sources and fixing up any mistakes. See internal/load/load.go.

To somewhat insulate the rest of the project from this nastyness the output of load.go is written to a Go database package internal/inst. The avogen tool is backed by this database and generates various other files across the project.

Note also that the following test generates a massive file with one instruction per entry in the instruction database and runs it through go tool asm, to confirm compatibility with the toolchain. Writing load.go above was basically a long game of whack-a-mole with this test.

avo/internal/inst/table_test.go

Lines 73 to 80 in f2315d5

	func TestAssembles(t *testing.T) {
	g := gen.NewAsmTest(printer.NewArgvConfig())
	b, err := g.Generate(inst.Instructions)
	if err != nil {
	t.Fatal(err)
	}
	test.Assembles(t, b)
	}

Anyway, this is a long way of saying that it should be possible in future to swap out the way the instruction database is generated, since I hope the details of the underlying data sources are contained within internal/load.

I would be interested in revisiting this once the rest of the project is more stable.