Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/arch/x86/x86asm: missing instructions: FLDZ, FLDLN2 #18665

Closed
minux opened this issue Jan 15, 2017 · 19 comments
Closed

x/arch/x86/x86asm: missing instructions: FLDZ, FLDLN2 #18665

minux opened this issue Jan 15, 2017 · 19 comments

Comments

@minux
Copy link
Member

minux commented Jan 15, 2017

package main

import "golang.org/x/arch/x86/x86asm"

func main() {
	text := []byte{0xd9, 0xee} // fldz
	_, err := x86asm.Decode(text[:], 64)
	if err != nil {
		panic(err)
	}
}

I found two missing instructions (they're also missing in x86.csv, which suggests that x86.csv is not complete):
0xd9 0xed: FLDLN2
0xd9 0xee: FLDZ

There are also some missing AVX instructions: e.g.
c4 c1 f3 2a cc vcvtsi2sd %r12,%xmm1,%xmm1

/cc @rsc

@minux
Copy link
Member Author

minux commented Jan 26, 2017

This is blocked by lack of access to the x86spec program that generated x86.csv.
Fixing this issue is easy, but I want to also fix x86spec program to make sure there aren't other missed instructions.

/cc @rsc

@mewmew
Copy link
Contributor

mewmew commented Apr 8, 2017

Thanks @minux for raising this issue.

I would also be very happy if support for these instructions were added to arch/x86. Back in 2015, I tried to submit a pull request to add these instructions rsc/x86#1

I'd also be very interested in the x86spec program which converts the Intel 64 and IA-32 Architectures Software Development Manual's PDF to x86.csv.

@rsc, did you ever make the source code of this program public?

mewmew added a commit to decomp/exp that referenced this issue Jun 3, 2017
@mewmew
Copy link
Contributor

mewmew commented Oct 16, 2017

This is blocked by lack of access to the x86spec program that generated x86.csv.

@minux With rev golang/arch@c6bf551 the source code of the x86spec tool has now been added to the repo.

@rsc
Copy link
Contributor

rsc commented Oct 16, 2017

I believe @quasilyte is working on generating x86.csv from Intel's description tables as open sourced as part of xed, which will replace the x86spec pdf reader.

@mewmew
Copy link
Contributor

mewmew commented Oct 16, 2017

Ah, glad to hear! Thanks!

@quasilyte
Copy link
Contributor

I can confirm that XED-based x86.csv contains such instructions:

$ grep FLDZ x86xed.csv
"FLDZ","FLDZ","fldz","D9 EE","V","V","","","","",""
$ grep FLDLN x86xed.csv
"FLDLN2","FLDLN2","fldln2","D9 ED","V","V","","","","",""

$ grep FLDLN x86.csv
$ grep FLDZ x86.csv

It's a quite long way to fixing x86.csv-based tools though.
But at least XED files reader|CL88015 and new x86.csv generator (CL not mailed yet) are on their way.

@gopherbot
Copy link

Change https://golang.org/cl/104496 mentions this issue: x86/x86spec: enable XED-based x86.csv generation

@mewmew
Copy link
Contributor

mewmew commented Apr 6, 2018

@quasilyte That's great to hear! Thanks.

@mewmew
Copy link
Contributor

mewmew commented Nov 13, 2018

I tried again today at rev golang/arch@b19384d of x/arch, and I get the error unrecognized instruction for fldz instructions.

@quasilyte I understood from your comment that fldz should be supported by XED, and with https://golang.org/cl/104496 the tables should be generated based on XED. Is there some step missing to resolve this issue?

Cheers,
Robin

@gopherbot
Copy link

Change https://golang.org/cl/149438 mentions this issue: x86asm: add support for FLDZ and FLDLN2

@quasilyte
Copy link
Contributor

@mewmew, there were some unresolved format and implementation related questions that made XED-based csv generation abandoned.

@mewmew
Copy link
Contributor

mewmew commented Nov 14, 2018

@mewmew, there were some unresolved format and implementation related questions that made XED-based csv generation abandoned.

Ok, good to know. I submitted https://go-review.googlesource.com/c/arch/+/149438/ which at least fixes this issue by adding FLZ and FLDLN2 to x86.csv. Is it x86.csv that is the most up-to-date config, or would that be x86.v0.2.csv?

@quasilyte
Copy link
Contributor

@mewmew I believe you should use x86.v0.2.csv.

I'm not sure editing auto-generated file is a good idea though
and it doesn't solve the problem with other missing instructions in the x86.csv.
This discussion can be continued in a CL itself.

@pwaller
Copy link
Contributor

pwaller commented Apr 10, 2019

But at least XED files reader|CL88015 and new x86.csv generator (CL not mailed yet)

@quasilyte - please could you clarify - did you get around to mailing a new x86.csv generator?

@quasilyte
Copy link
Contributor

It was mailed (https://go-review.googlesource.com/c/arch/+/104496/).
Never got through.
That CL can be (to some extent) used as an example of how XED can be used to generate that file, but there is probably a better way, so I would write it from scratch instead of trying to reuse code from there.

I believe the results of that program were mostly correct (probably more correct than the current csv file) and it included AVX512 instructions. But since the generator itself was not submitted, the generated file was left behind as well.

@mewmew
Copy link
Contributor

mewmew commented Sep 4, 2019

I believe @quasilyte is working on generating x86.csv from Intel's description tables as open sourced as part of xed, which will replace the x86spec pdf reader.

@quasilyte and @rsc, I felt very excited to see the XED data being used for the decoding table generation, as it would help resolve issues with missing instructions, such as FLDZ, FLDLN2 reported in this issue.

However, now it seems that the CL (https://go-review.googlesource.com/c/arch/+/104496/) has been stalled?

Are there any technical reasons why the CL has not been merged. From my understanding, it seems that it worked well to use the XED data and also helped resolve issues with missing instructions.

If there are parts missing before https://go-review.googlesource.com/c/arch/+/104496/ could be merged, @rsc or @quasilyte would you help clarify those so that someone else could pick up the torch and get this merged?

Cheers,
Robin

@quasilyte
Copy link
Contributor

To my knowledge, @fexolm was investigating an opportunity to work on x86 decoder.

@mewmew, it might be a problem that this needs an effort and it's already possible to do a workaround without it.

However, now it seems that the CL (https://go-review.googlesource.com/c/arch/+/104496/) has been stalled?

Correct. It's there as a reference for further attempts. One should start a new CL and think about it from scratch, while keeping in mind the context from CL104496.

Are there any technical reasons why the CL has not been merged. From my understanding, it seems that it worked well to use the XED data and also helped resolve issues with missing instructions.

If I understood it correctly, the x86.csv was intended to be used for generating all x86 asm related tools, like encoders and decoders. The problem is, x86.csv is a simplified view of an arch, it had no AVX-512 in the beginning. To generate AVX-512 aware tools, we need it to contain additional data. The CL you mentioned stuck somewhere in:

  • Can't propose simple enough and functionally complete format for updated x86.csv.
  • There were some discussions about implementation complexity.

These 2 problems may not be purely technical, but they come to my mind before anything.

In the end, AVX-512 related code was generated out of XED tables directly to avoid discussions around x86.csv. It can be proposed that we use XED data files instead of x86.csv everywhere, but that format is not well-defined and is not part of the stable API (my knowledge might be outdated). Some kind of version-aware wrapper would be more reliable I guess, but again it's a work that someone should perform. Or x86.csv needs a revisit after we merged AVX-512 and can avoid rushing it.

As another example of how XED data files were used during that, there is avx512test (but it's not pretty).

Hope that helps.

@mewmew
Copy link
Contributor

mewmew commented Sep 4, 2019

Thanks @quasilyte for the writeup and added context.

re:

To my knowledge, @fexolm was investigating an opportunity to work on x86 decoder.

@fexolm how did your investigation go? If you would care to, please share your experiences, good or bad, as it could help us move this along.

Cheers,
Robin

mewmew added a commit to mewpull/arch that referenced this issue Nov 23, 2019
mewmew added a commit to mewpull/arch that referenced this issue Nov 23, 2019
@mewmew
Copy link
Contributor

mewmew commented Nov 26, 2019

🎉

@rsc rsc removed their assignment Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants