Hi again! Some of you asked about Doom in my previous post about my BreezyBox shell for ESP32-S3. In my family, Celeste is more popular, so I ported it instead. Doom is left as an exercise for the reader.
Also, I extracted a few things as separate components (vterm, BT keyboard, display driver), because they have their own uses outside of BreezyBox, and some of them run on other chips, too.
I wonder if I could get the whole thing to run with some limitations e.g. on C6. Most of it compiles on RISC-V just fine (except my xcc700 compiler would be useless there). Having no PSRAM makes it tight. But some useful tiny apps can actually fit in just a few kilobytes.
What other apps do you think would be a great fit for this platform? I already noticed many people interested in ssh; I'll have a look what it takes.
BreezyBox is at an early development stage. What you see in the demo is mostly all there is so far. There is no telling if it will catch on, with more developers adding apps and features.
Some sort of web access for remote config should be possible, if anyone cares to implement that. The web server is already there; getting it to run some server side code may take extra effort.
It should be possible to get most of it compiled for C3, C6, or P4. But xcc700 is specific to the Xtensa CPU, so that would be a bigger effort. And the ELF binaries you install with eget would need to be recompiled (with existing gcc) and published for RISC-V. When it gets to that, we should make some minimal manifest support to eget and the release conventions, to distinguish between ELF files for different platforms. Also keep in mind how much PSRAM is available, if any.
Are you interested in having xcc700 ported to RISC-V, or want to keep it focused on Xtensa? I have a dream of building a simple C89 compiler that targets RISC-V and Wasm and runs on esp32-c6 someday.
I would like to explore the RISC-V systems more as well eventually, but for the nearest future I will probably stick with one platform, try to get my actual device to do more of the fun things I like.
Right, people were asking about the shell used in the xcc700 demo, so that is released now too, and I tried to make it convenient to reuse as a component.
Esp32-s3 can do so much more, we are just scratching the surface. You might remember FabGL, that ran some nice demos in the realm of games and DOS emulation. Unfortunately, seems to be hard to update for modern versions of ESP-IDF. I am trying to build something more modular, with hope that some parts of it will survive longer.
I think someone also ran an old version of MacOS simulated on it, too, that is also an indication of the general capability.
Some parts of it, very likely. The shell is just linenoise with some glue code. How are things with ELF loading on rp2350, I did not check. May be possible, the question is, how much effort. In ESP-IDF that is a standard component now.
The memory model is flat enough. The problem with the memory is, you only have about 200kB traditional RAM. But then, you have 8MB of PSRAM. But it requires strict 4-byte alignment, and is noticeably slower.
What makes traditional OSs difficult on this platform, is the lack of memory protection. But I am a simple man, I am not writing an OS, all I wanted was a usable shell and an apps installer, so I made that work.
Things change when the underlying assumptions change. Memory protection is mostly useful for multitasking, but traditional multitasking isn't always needed when your entire app starts faster than Windows can minimize a program.
There is the TCC. Adapting that would probably be a faster path to a full featured C compiler on esp32 than building up my xcc700. This is more of an educational sandbox project.
I would love to see how you handle variably-modified types, the way I retrofitted them onto chibicc never felt quite right, and I've never seen another non-gcc/clang compiler fully support noplate's VM type patterns.
Maybe I fill find the time to clean it up and make it public. But did not find VM-types difficult to implement, the type just depends on some run-time value, so at the point in time where the size expression is evaluated, one stores the result in a hidden variable which the type refers to.
What I found troublesome were not really the caching of array count, but when and where should the side effect be represented in AST, for example this one: https://godbolt.org/z/rcT1d8WWe the puts() call is a side effect for automatic variable but completely ignored for static variable.
Yes, it is a bit of mess. We started to make this more precise in the C standard when those expression have to be evaluated, but there are still issues. And when this is involved extensions there are more issues. I think in this example, such initializer would not be allowed in ISO C. I also fixed many bugs in GCC .
Also, I extracted a few things as separate components (vterm, BT keyboard, display driver), because they have their own uses outside of BreezyBox, and some of them run on other chips, too.
I wonder if I could get the whole thing to run with some limitations e.g. on C6. Most of it compiles on RISC-V just fine (except my xcc700 compiler would be useless there). Having no PSRAM makes it tight. But some useful tiny apps can actually fit in just a few kilobytes.
What other apps do you think would be a great fit for this platform? I already noticed many people interested in ssh; I'll have a look what it takes.
Git repo with the updated demo firmware: https://github.com/valdanylchuk/breezydemo
Celeste port repo: https://github.com/valdanylchuk/ccleste
Youtube demo video: https://www.youtube.com/watch?v=nufOQWBmwpk
reply