rustc_codegen_clr VS MicroPython

I don't have something that could be of Crafting Interpreters level on hand, but the general suggestion given to this question on DotNetEvolution discord by Roslyn team members was to start with the spec itself: https://ecma-international.org/publications-and-standards/st...

This might be a bit of a learning curve if you don't have experience with writing compilers like that though.

There are other materials that might prove useful should you go down this path:

- A series of blog posts of a student who is writing a Rust to .NET compiler which you could follow along: https://fractalfir.github.io/generated_html/home.html The project itself: https://github.com/FractalFir/rustc_codegen_clr

- A video series on writing a compiler for .NET from scratch: https://www.youtube.com/watch?v=wgHIkdUQbp0&list=PLRAdsfhKI4... Notes: https://github.com/terrajobst/minsk/tree/master/docs

As for CLR via C#, while it has certain facts that remained the same, the ecosystem has changed a lot since then, you really want to target the latest LTS to get best experience and performance.

p.s.: if it's any consolation, the promise in CLR via C# of JIT having the advantage of dynamically profiling code execution and compiling to profile-guided version, tuned to the exact hardware and environment is finally fulfilled, many years later :)

The author answers the "why" in the FAQ https://github.com/FractalFir/rustc_codegen_clr?tab=readme-o.... I didn't find it very convincing but I'm sure the author will learn a lot of neat things along the way.

After adding support for statics and many bug fixes related to pointers/slices, my compiler backend targeting .NET can finally build a barely working version of the standard library. It can be loaded into the .NET runtime, allocate memory (e.g. for a Box, Vec or String), push elements to Vec's and String's (currently without relocations). There are also some other parts of the standard library that already work, but I want to stress that the project is still fairly early into development (I started working on it late August), and you should expect most things in std to not work at all. Things working is the exception, not the rule. This newest set of commits allows you to use a small subset of the standard library, within code running inside the .NET runtime. | Here is some Rust code that I wrote to demo the ability to use the Rust std within the .NET runtime:

This is a small update about my rustc backend, which is supposed to allow compilation of Rust code into .NET assemblies. This would allow you to use Rust crates in C#, and C# libraries in Rust.

I am currently working on a rust codegen targeting .NET. One of the features I currently work on is a .NET interop layer, mycorrhiza, and I am having some trouble modeling certain type constraints. There are 2 ways to store a reference to a GC type in Rust: 1. By a handle - this type has some cost associated with it, but can be stored anywhere (heap, stack). 2. By a raw reference - raw references may only live on the stack. They can be copied, and behave almost exactly like a normal rust type (with exceptions related to transmutes and enums), as long as they are stored on the stack.

Just putting my hand up to say that MicroPython is awesome (and runs on the RP2040). https://micropython.org

Gah, I just ordered one on impulse [1]. I've wanted to build out a WiFi PDA for quite some time now and I like this hardware.

I'm quite liking the idea of running tulip MicroPython [2] on it, or going back to pure MicroPython [3] and writing some drivers. Apparently something like ampy can be used to upload/download Python files [4].

Threads could be quite exciting for running multiple programs at once [5], although I have no idea what it means for two programs to fight over GPIO! It does seem as though MicroPython can only utilise a single core [6].

[1] https://www.lilygo.cc/products/t-deck?variant=43087936487605

[2] https://github.com/bwhitman/tulipcc/tree/main/tulip/tdeck

[3] https://docs.micropython.org/en/latest/esp32/tutorial/intro....

[4] https://www.digikey.co.uk/en/maker/projects/micropython-basi...

[5] https://docs.micropython.org/en/latest/library/_thread.html

[6] https://github.com/micropython/micropython/issues/8197

If you really want to engage in the travesty that is shoehorning a high level scripting language into an environment that has 512 bytes of RAM and less clock cycles than an electric toothbrush, there is micropython.

There is some work to implement a common CAN interface in micropython but it's some way off yet: https://github.com/micropython/micropython/pull/13149

https://github.com/raspberrypi/pico-sdk/ links to a PDF about connecting to the interwebs with a pi pico.

micropython/micropython//ports/rp2/boards/RPI_PICO_W: https://github.com/micropython/micropython/tree/master/ports...

raspberrypi/pico-sdk /lib: btstack, cyw43-driver, lwip, mbedtls, tinyusb https://github.com/raspberrypi/pico-sdk/tree/master/lib

raspberrypi/pico-examples//pico_w/wifi/access_point/picow_access_point.c:

https://github.com/raspberrypi/pico-examples/blob/master/pic...

There's an iperf opkg pkg, or is it just netperf (which works with fluent)?

raspberrypi/pico-examples//pico_w/wifi/iperf/picow_iperf.c:

Needed for hobby project, maintained by very small team. Haven't decided on specific microcontroller. Needed for general bit-banging, speed and code size are not priorities.

So far have considered MicroPython [0] [1] and Lua [2] [3], but open for suggestions for others.

What are experiences?

[0] https://micropython.org/

Python is also a general-purpose programming language. It's typically used on desktop / laptop computers. But Micropython is a variant that can be used to program embedded devices.