hex number format in .net 7 jit assembly

[kasperk81]

jitdisasm in .net 7 is printing h suffix for hex numbers. h suffix may be allowed by intel assembly spec and normal for microsoft assemblers, but clang/gcc don't support it. it's unfamiliar to users and their disassemblers (which don't print h suffix) and their assemblers (which don't recognize the h suffix). please replace %02XH with 0x%02x or keep it readable decimal as it was before .net 7.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[kasperk81]

.net 6: using decimal recognized by masm, clang, gcc, nasm, ptx etc. and their users

.intel_syntax noprefix

x:
  mov    [rsp+16], rdi
  mov    rdi, [rsp+9]

.net 7: using hex with h suffix (instead of 0x prefix) recognized only by masm and its users

.intel_syntax noprefix

x:
  mov    [rsp+10H], rdi
  mov    rdi, [rsp+09H]

[EgorBo]

Overall JitDisam is not a real asm code, e.g. it contains pseudo instructions like mov gword

cc @BruceForstall on hex formatting

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

jitdisasm in .net 7 is printing h suffix for hex numbers. h suffix may be allowed by intel assembly spec and normal for microsoft assemblers, but clang/gcc don't support it. it's unfamiliar to users and their disassemblers (which don't print h suffix) and their assemblers (which don't recognize the h suffix). please replace %02XH with 0x%02x or keep it readable decimal as it was before .net 7.

Author:	kasperk81
Assignees:	-
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-

[kunalspathak]

Overall JitDisam is not a real asm code, e.g. it contains pseudo instructions like mov gword

Correct. This was changed in .NET 7 in #73816 to ease the search of given address offset displayed in local variables table.

[kasperk81]

#73816 (comment)
change to 0x format for readability

[kasperk81]

@BruceForstall feedback about reverting to well known 0x prefix was from the user when i enabled dotnet daily build on https://godbolt.org public website (compiler-explorer/compiler-workflows@226373d). this feedback echoes your comment: #73816 (comment). i think it should be changed

[kunalspathak]

Agree. I will revert the format of disassembly, and instead make changes in local variables table to make search easier.

[kunalspathak]

I was looking into this and the original change done in xarch was to make it consistent regardless of how much is the displacement. Prior to my change, it was showing a mixed of decimal and hexadecimal and some of them also included H as seen below.

runtime/src/coreclr/jit/emitxarch.cpp

Lines 10311 to 10326 in c240ade

	if (frameRef)
	{
	printf("%02XH", (unsigned)disp);
	}
	else if (disp < 1000)
	{
	printf("%02XH", (unsigned)disp);
	}
	else if (disp <= 0xFFFF)
	{
	printf("%04XH", (unsigned)disp);
	}
	else
	{
	printf("%08XH", (unsigned)disp);
	}

This makes me feel that we should retain the original change or update all the above references to eliminate H. Is there an instruction manual that guides what is the right format to display? @tannergooding - you might know this.

[tannergooding]

There is no "official" format for x86 assembly and what exactly is supported can differ based on assembler.

That being said, most assemblers support 0x (MASM is a notable exception) while the support for h is definitely more variable. The majority of official samples from the Intel/AMD architecture manuals use 0x as well.

[kunalspathak]

That being said, most assemblers support 0x (MASM is a notable exception) while the support for h is definitely more variable. The majority of official samples from the Intel/AMD architecture manuals use 0x as well.

Thanks @tannergooding . A follow-up question, do they distinguish between displaying the address that is less than 1000, the way we are doing? I am ok with using 0x or h format as long as they are consistent for various address and not restrict it based on the actual address value.

[tannergooding]

There isn't really a standard there either and which is "better" depends on context.

If you're doing something like "field offsets" then decimal may be better. If you're doing arbitrary addresses or displacements, then hex may be better.

The same goes for practically any immediate value. For shufps, using hex for the immediate is almost always better even for small constants, as an example.

[kunalspathak]

@jakobbotsch - can you please take a look?

[jakobbotsch]

@kunalspathak What is the work item here? To update the places in the xarch backend where we print hex numbers with "H" suffix to instead print with "0x" prefix?