Guidelines for using ports/embed

[yf13]

I am now using ports/embed on NuttX and can run a simple REPL, however, a lot micropython features are still missing. I noticed that ports/embed/README.md says that:

This port essentially targets the C language, instead of a particular hardware architecture or platform.

I am wondering if this means that having import machine is not an intended use case?

Going forward, I am wondering where should we put NuttX specific stuffs if more features are enabled? For example, it might be improper to have NuttX specific code in ports/embed/port/mphalport.c and a mphalport.c at NuttX side maybe better?

On one side, NuttX has its own build system thus feels like a use case for ports/embed; on the other hand, its feels like another POSIX port thus needs its own mphalport.c. The ports/embed/port/mphalport.c feels confusing here?

[cwalther]

I am wondering if this means that having import machine is not an intended use case?

I don’t think any predisposition for or against having a machine module is intended. Of course you need to write it yourself, because the port cannot know anything about your machine environment.

For example, it might be improper to have NuttX specific code in ports/embed/port/mphalport.c and a mphalport.c at NuttX side maybe better?

Agreed.

The ports/embed/port/mphalport.c feels confusing here?

See here for how I solved that confusion: #11430 0b2d967

(A real-world application of that draft PR is here.)

[yf13]

@cwalther I appreciate your comments. I noticed that pull/11430 commit dropped `port/mphalport.c`, this equals to my overwriting it in generated `micropython_embed/port` folder.  So things under `ports/embed` needs be really target independent. From this regard, probably the folder `ports/embed/port` needs be further reviewed to see whether they are really target independent? For example, the `port/mpconfigport_common.h` has target adaption contents now. it may work for Linux, xxxBSD or NuttX, but may fail to work on other targets.

…

On Sun, 2025-08-03 at 03:09 -0700, Christian Walther wrote: > I am wondering if this means that having `import machine` is not an intended > use case? I don’t think any predisposition for or against having a `machine` module is intended. Of course you need to write it yourself, because the port cannot know anything about your machine environment. > For example, it might be improper to have NuttX specific code in > ports/embed/port/mphalport.c and a mphalport.c at NuttX side maybe better? Agreed. > The `ports/embed/port/mphalport.c` feels confusing here? See here for how I solved that confusion: [#11430 0b2d967](0b2d967 db71ad527d5ad3dd5c4adede730131b17) (A real-world application of that draft PR is [here](https://github.com/cwalther/pew-playdate).)

[cwalther]

What parts of mpconfigport_common.h look problematic to you? I didn’t have any trouble with it on the Playdate, which certainly isn’t Linux or BSD. If you are thinking of a platform/compiler that does not have alloca(), then you would probably rather have to review the entire codebase for uses of that.

[yf13]

So far they are fine for me. There is one case that I am unsure is the `rv64ilp32` toolchain case where `uintptr_t` is 32bit and CPU word is 64bit. My micropython knowledge too limited now to tell if changes are needed.

…

On Mon, 2025-08-04 at 03:01 -0700, Christian Walther wrote: What parts of mpconfigport_common.h look problematic to you? I didn’t have any trouble with it on the Playdate, which certainly isn’t Linux or BSD. If you are thinking of a platform/compiler that does not have `alloca()`, then you would probably rather have to review the entire codebase for uses of that.