[clr-interp] Interpreter for ARM32 SOFTFP #120688

clamp03 · 2025-10-14T06:50:45Z

Enable interpreter for arm32 softfp.

Implement Assemblies for args and return values
Fix some minor bugs
Tested with simple test cases

However, it crashes right after HellWorld print.

Need to test the implementations

This reverts commit b3ba6ec.

src/coreclr/interpreter/inc/interpretershared.h

src/coreclr/vm/interpexec.cpp

src/coreclr/clr.featuredefines.props

src/coreclr/clrfeatures.cmake

janvorli · 2025-11-28T18:54:16Z

src/coreclr/vm/callstubgenerator.cpp

    }
-    else if ((m_currentRoutineType == RoutineType::FPReg) && (type != RoutineType::FPReg))
+#ifndef TARGET_ARM
+    else


I don't understand why this ifdef is needed.

There can be multiple pending ranges to handle. ex. A struct can pass some of them by registers and remains by stacks. So it needs to check all ranges in some cases like example in #120140.

But single routine handles only a stack or registers. For the case you have described, there would need to be two routines. In the current method, this added ifdef seems to have no effect. If the m_currentRoutineType was RoutineType::GPReg, then it would not enter the if below with or without the else. And if the m_currentRoutineType was RoutineType::FPReg, then again, the else would have no effect.

Also, the case when a struct is split between registers and stack also exists on x64 Linux. The ArgIterator has the GetArgLocDescForStructInRegs() for this purpose. The code in the ComputeCallStub uses that to pretend the parts of the struct are "separate arguments" from the further processing point of view. The stuff around it is quite complex due to the complicated classification mechanism defined by the Unix amd64 ABI, but it seems we could handle the case of args split between regs and stack at that place too and I think we would not have to handle that here then.

janvorli · 2025-11-28T18:54:33Z

src/coreclr/vm/callstubgenerator.cpp

 #endif // TARGET_ARM64
-    else if ((m_currentRoutineType == RoutineType::Stack) && (type != RoutineType::Stack))
+#ifndef TARGET_ARM
+    else


The same here

src/coreclr/vm/callstubgenerator.cpp

janvorli · 2025-11-28T19:10:54Z

src/coreclr/vm/interpexec.cpp

 // Use the NOINLINE to ensure that the InlinedCallFrame in this method is a lower stack address than any InterpMethodContextFrame values.
 NOINLINE
-void InvokeUnmanagedMethodWithTransition(MethodDesc *targetMethod, int8_t *stack, InterpMethodContextFrame *pFrame, int8_t *pArgs, int8_t *pRet, PCODE callTarget)
+void InvokeUnmanagedMethodWithTransition(UnmanagedMethodWithTransitionParam *pParam)


Can you please add a brief comment explaining why we are passing the args via this struct instead of directly so that people can understand the reason in the future?

I added a comment. If it isn't good enough, I will update again. Thank you.

- Because of async support, some methods need arguments more than 4. I changed arguments passing. - Fixed some build errors.

clamp03 · 2025-12-10T11:11:34Z

Merged Upstream branch and fixed some errors.
However, I didn't update to support async. I will add async support after this PR is merged.
Thank you.

janvorli · 2025-12-10T22:14:02Z

src/coreclr/vm/callstubgenerator.cpp

    }
-    else if ((m_currentRoutineType == RoutineType::FPReg) && (type != RoutineType::FPReg))
+#ifndef TARGET_ARM
+    else


But single routine handles only a stack or registers. For the case you have described, there would need to be two routines. In the current method, this added ifdef seems to have no effect. If the m_currentRoutineType was RoutineType::GPReg, then it would not enter the if below with or without the else. And if the m_currentRoutineType was RoutineType::FPReg, then again, the else would have no effect.

janvorli · 2025-12-10T22:22:12Z

src/coreclr/vm/callstubgenerator.cpp

+#ifdef TARGET_ARM
+    if (argLocDesc.m_cGenReg == 2 || argLocDesc.m_byteStackSize >= 8)
+    {
+        /* do nothing */


Can you please help me understand why arguments with 2 registers or 8 or more bytes passed on stack don't get any routine classification here?
The goal of this part of the code together with the TerminateCurrentRoutineIfNotOfNewType call is to identify when we cannot extend the range of registers / stack that we copy using a single routine. So with this change, any time we get an argument that is passed in two regs or an argument that is passed on stack with 8 or more bytes, we would not extend the previous range of registers / stack and I am not sure why.

But single routine handles only a stack or registers. For the case you have described, there would need to be two routines. In the current method, this added ifdef seems to have no effect. If the m_currentRoutineType was RoutineType::GPReg, then it would not enter the if below with or without the else. And if the m_currentRoutineType was RoutineType::FPReg, then again, the else would have no effect.

I am so sorry. When I have implemented it in the first time, removing else statements was valid . After the TerminateCurrentRoutineIfNotOfNewType function is introduced, I didn't read codes carefully.I will check GetArgLocDescForStructInRegs which you mentioned in another comment.

Can you please help me understand why arguments with 2 registers or 8 or more bytes passed on stack don't get any routine classification here?
The goal of this part of the code together with the TerminateCurrentRoutineIfNotOfNewType call is to identify when we cannot extend the range of registers / stack that we copy using a single routine. So with this change, any time we get an argument that is passed in two regs or an argument that is passed on stack with 8 or more bytes, we would not extend the previous range of registers / stack and I am not sure why.

I intended to block to extend of the previous ranges for long bytes and to enable to extend 4-size single register / stack. Because for 4-byte arg and 8-byte arg are handled differently. For 4 byte, it load a single interp stack to a register or stack. For 8 bytes, it load a single interp stack to two registers or stacks. If 4-byte and 8-byte args are mixed in a range, I think it is hard to identify how to handle.

Removed the def in TerminateCurrentRoutineIfNotOfNewType. And for arg which has both reg and stack, execute ProcessArgument for each. Could you review again?

janvorli · 2025-12-10T22:41:10Z

src/coreclr/vm/callstubgenerator.cpp

    }
-    else if ((m_currentRoutineType == RoutineType::FPReg) && (type != RoutineType::FPReg))
+#ifndef TARGET_ARM
+    else


Also, the case when a struct is split between registers and stack also exists on x64 Linux. The ArgIterator has the GetArgLocDescForStructInRegs() for this purpose. The code in the ComputeCallStub uses that to pretend the parts of the struct are "separate arguments" from the further processing point of view. The stuff around it is quite complex due to the complicated classification mechanism defined by the Unix amd64 ABI, but it seems we could handle the case of args split between regs and stack at that place too and I think we would not have to handle that here then.

janvorli · 2025-12-10T22:45:33Z

src/coreclr/vm/callstubgenerator.cpp

+#ifdef TARGET_ARM
+        if (argLocDesc.m_cGenReg == 2)
+        {
+            pRoutines[m_routineIndex++] = GetRegRoutine_4B(argLocDesc.m_idxGenReg, argLocDesc.m_idxGenReg + argLocDesc.m_cGenReg - 1);


Have you considered / tried changing the interpreter stack so that on arm32, the slot size would be 32 bit? It seems it would then eliminate the need for these special _4B variants. However, I am not sure if there are any blockers / issues with changing the stack slot size. I've asked in a private discussion why Mono doesn't use 32 bit interpreter stack on arm32 and the answer was that there was no reason for trying to do that there.

Have you considered / tried changing the interpreter stack so that on arm32, the slot size would be 32 bit? It seems it would then eliminate the need for these special _4B variants. However, I am not sure if there are any blockers / issues with changing the stack slot size. I've asked in a private discussion why Mono doesn't use 32 bit interpreter stack on arm32 and the answer was that there was no reason for trying to do that there.

At first, I implemented with 32 bit slot size and the tests passed because I thought 32 bit slot size is better in 32 bit arch. After #120688 (comment), I changed it to 64 bit. I am not sure which is better for .NET runtime interpreter. Could you please let me know your idea?
Thank you.

- To support structure arg which has reg and stack, split it for each

clamp03 added 22 commits October 14, 2025 10:35

[CLRINTRP] Port to ARM

c2b6454

[CLRINTRP] Make dummy asssembly functions

ad24b45

Disable Float

04b980f

[INTRP] Print HelloWorld Done

8cd71fa

However, it crashes right after HellWorld print.

[INTRP] HelloWorld Done

55560c4

[INTRP] Update X to R for arm register

7df0312

[INTRP] Call methods with 2 args and return value

5b3ef8e

[INTRP] Implement Args Load and Store Assemblies

02320b0

[INTRP] Add Load_Ref and Store_Ref

cb816e6

[INTRP] Return I8

0cc0032

[INTRP] Update I8 to I4 for ARM32

a09723d

[INTRP] Call to Method with LONG args

07d975a

[INTRP] Initial Support for Float and Double

9875d8b

[INTRP] Update for ARM SOFTFP

4d7d19f

[INTRP] Update all assemblies for arm softp

ab7eca6

Need to test the implementations

[INTRP] Can Pass Arguments using Stack

1cf65b7

[INTRP] Remove Redundant Codes

aabd45b

[INTRP] Support Struct

e6a79a0

[INTRP] Support RetBuff

a5e1bd5

[DO NOT MERGE] For Test

b3ba6ec

[INTRP] Fix release build errors

30e25e0

Revert "[DO NOT MERGE] For Test"

82769b4

This reverts commit b3ba6ec.

clamp03 self-assigned this Oct 14, 2025

github-actions bot added the area-VM-coreclr label Oct 14, 2025

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Oct 14, 2025

clamp03 added the area-CodeGen-Interpreter-coreclr label Oct 14, 2025

clamp03 mentioned this pull request Oct 14, 2025

[interp] Fix a minor bug #120140

Closed

Workarounds for errors

f402453

kg reviewed Oct 14, 2025

View reviewed changes

src/coreclr/interpreter/inc/interpretershared.h Outdated Show resolved Hide resolved

Revert INTERP_STACK_SLOT_SIZE

4d48c03

jkotas reviewed Nov 10, 2025

View reviewed changes

src/coreclr/vm/interpexec.cpp Outdated Show resolved Hide resolved

jkotas reviewed Nov 10, 2025

View reviewed changes

src/coreclr/vm/interpexec.cpp Outdated Show resolved Hide resolved

clamp03 added 2 commits November 10, 2025 14:31

Fix: Apply review feedback

48c8744

Remove a header inclusion

acc84c3

This was referenced Nov 10, 2025

System.IO.Tests.File_GetSetTimes_SafeFileHandle.WritingShouldUpdateWriteTime_After_SetLastAccessTime failing #97020

Open

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

clamp03 added 3 commits November 11, 2025 11:26

Merge remote-tracking branch 'origin/main' into intrp_arm

7e42431

Merge remote-tracking branch 'origin/main' into intrp_arm

17e23bb

Merge remote-tracking branch 'origin/main' into intrp_arm

146eba1

am11 reviewed Nov 27, 2025

View reviewed changes

src/coreclr/clr.featuredefines.props Outdated Show resolved Hide resolved

am11 reviewed Nov 27, 2025

View reviewed changes

src/coreclr/clrfeatures.cmake Outdated Show resolved Hide resolved

clamp03 added 2 commits November 28, 2025 10:28

Updated based on reviews

d625e46

Merge remote-tracking branch 'origin/main' into intrp_arm

605008e

am11 requested a review from janvorli November 28, 2025 08:00

janvorli reviewed Nov 28, 2025

View reviewed changes

clamp03 added 5 commits December 2, 2025 13:57

Updated based on reviews

3da428c

Merge remote-tracking branch 'origin/main' into intrp_arm

6fe4663

Update special handling for arm32

1bb6d41

Merge remote-tracking branch 'origin/main' into intrp_arm

f1a5b0d

Fix errors after upstream merge

661e3a1

- Because of async support, some methods need arguments more than 4. I changed arguments passing. - Fixed some build errors.

Fix build error

66e32f6

janvorli reviewed Dec 10, 2025

View reviewed changes

clamp03 added 3 commits December 11, 2025 11:55

Fix a mistake

1095749

Update ComputeCallStub

ca8dfc1

- To support structure arg which has reg and stack, split it for each

Merge remote-tracking branch 'origin/main' into intrp_arm

463a0da

build-analysis bot mentioned this pull request Dec 11, 2025

[Android][CoreCLR] System.Security.Cryptography.Tests killed by lowmemorykiller #118603

Open

[clr-interp] Interpreter for ARM32 SOFTFP #120688

Are you sure you want to change the base?

[clr-interp] Interpreter for ARM32 SOFTFP #120688

Uh oh!

Conversation

clamp03 commented Oct 14, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clamp03 commented Dec 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clamp03 Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

clamp03 Dec 11, 2025 •

edited

Loading