How to port to a new CPU platform?

[snikeguo]

How to port to a new CPU platform? I want to port coreclr to MCU platform, such as NXP I.mx.rt series / ST Stm32h7 series (arm cortex-m7, 600 + MHz, thumb2 instruction , chip contains 1MB SRAM, 4MB NOR Flash), MCU can access external SDRAM, nor flash. and it can run programs directly in NOR flash. (by the way, 64MB SDRAM is about $0.7.) So I am reading the PAL source code of coreclr, and I have encountered many problems that API functions cannot be transplanted, such as:

1.PALAPI CreateThread(
IN LPSECURITY_ ATTRIBUTES lpThreadAttributes,
IN DWORD dwStackSize,
IN LPTHREAD_ START_ ROUTINE lpStartAddress,
IN LPVOID lpParameter,
IN DWORD dwCreationFlags,
OUT LPDWORD lpThreadId)；

I think you should have forked the CLR code of. Net framework to make the dotnet project development faster. Similar to these “ LPSECURITY_ ATTRIBUTES lpThreadAttributes” parameters bring great difficulties to porting. For FreeRTOS, the creation thread has the following parameters:

BaseType_ t xTaskCreate(
TaskFunction_ tp vTaskCode,//entry
const char * constpcName,//thread name
unsigned short usStackDepth,//stack size
void *pvParameters,//thread arg
UBaseType_ t uxPriority,//priority
TaskHandle_ t *pvCreatedTask
)；

2.

PALAPI
MessageBoxW(
IN LPVOID hWnd,  // NOTE: diff from winuser.h
IN LPCWSTR lpText,
IN LPCWSTR lpCaption,
IN UINT uType);

Because there is no GUI

I think you should make a migration Manual of minimum coreclr to support JIT, GC and thread.

3. Why don't I choose nanoframework? Because it's too slow. Nanoframework is interpreted and executed without JIT. But SDRAM is big enough, MCU can use JIT completely. 4.ReadyToRun(R2R) For MCU? input： ilcode、HelloWorld Image Offset out put:(HelloWorld NativeIamge+ILCode).hex

   HelloWorld IL code--------------------> |         | 
                                       |  R2R.exe | ------->(HelloWorld NativeIamge+ILCode).hex
   HelloWorld Image Offset --------------->|          |

   then download to mcu:

   nor flash:
   8000000 -------------------------------80010000---------
   NativeDriver+CoreClr   |  align    |   HelloWorld NativeIamge+ILCode

   In this way, MCU directly runs HelloWorld native image in NOR flash

[dotnet-issue-labeler[bot]]

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.

[hoyosjs]

@davidwrighton helped with writing a rough overview of what needs to be done to bring support https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/guide-for-porting.md We know to some extent the PAL was more of a "make system API look like windows" more than "here is a base functionality needed to support different OS's", and there's been conversations of what can be done around that. For example, what used to be CoreRT did more of a layer of functionality. The PAL in coreclr comes from a lot of history and different projects - and while not ideal and a bit organic in that sense - it works pretty well for most cases. A lot of these emulations can be made work pretty well, as seen with all the Linux distros that have been supported under it. As for Native AOT as you point out, it's something that has been investigated and continues to be - we consider it part of the form factors as described in .NET Runtime Form Factors, and there's still some active work in ways to provide better experiences in that area. Maybe @janvorli also has some tips for the PAL layer for such an OS?

[snikeguo]

https://docs.microsoft.com/en-us/cpp/build/overview-of-arm-abi-conventions?view=msvc-160

The instruction set for Windows on ARM is strictly limited to Thumb-2

It seems that coreclr has completed the JIT compiler of thumb-2 instruction set? If so, does it mean that I only need to port PAL layer code?

Can the coreclr team optimize the PAL layer code architecture to make coreclr more portable? such as:

HANDLE
PALAPI
CreateFileW(
        IN LPCWSTR lpFileName,
        IN DWORD dwDesiredAccess,
        IN DWORD dwShareMode,
        IN LPSECURITY_ATTRIBUTES lpSecurityAttributes,
        IN DWORD dwCreationDisposition,
        IN DWORD dwFlagsAndAttributes,
        IN HANDLE hTemplateFile);

Some projects have no file system. only RTOS（only thread, queue, semaphore, mutex, task notification） So I think PAL layer code architecture needs ：1. highly modular,2. portable 3.configurable .

[hoyosjs]

Yes, CoreCLR is thumb aware. A lot of the ARMv7 sfp support is mostly best try, and might have some hidden bugs. It's unlikely the PAL will change any time soon. That would be a pretty large undertaking. The PAL would still have file api's, other with things like System.File.IO would make no sense. What you are asking is a bit more extensive - basically for such OS's a lot of API's in the .NET surface would need to be marked as disabled, given the platform wouldn't support them (or support them by creating an abstraction on top of memory or something). That's quite more than just a port.

[snikeguo]

@hoyosjs OK, I'm looking forward to the new pal framework, otherwise I can only port the JVM to mcu, although I hate Java. As for file operation, I think like rust language,the CORE only includes basic things, such as thread, collections, diagnostics, reflection... And STD includes file operation API. In order to distinguish the API of core and STD, you can change the namespace of thread to Core.Threading.Thread , while the file operation is still in progress Std.Io (or System.Io ) hahaha.I don't think Microsoft will do that...........

[snikeguo]

I'm going to port the JVM to arm mcu.so close the issue.

[hoyosjs]

Just to be clear, this PAL work is not planned for anytime soon as I am aware. And the "core"part that you say is a major rework of a lot of components. While it's great to hear there's interest for coreclr to be used in these scenarios, the team won't get to work on this in the foreseeable future in the current order of priorities. I was just trying to explain what it would entail to try to port to such architecture.

[snikeguo]

@hoyosjs thank you very much for your answer

[snikeguo]

I'm going to try to read the PAL code... and try to port it.