So, uh, it has to be solar powered only? That sounds fantastically niche and not like something someone would want to design/build.
I think any reasonable "work" performance level would require too large an area of solar cells in order to be practical, especially if it should work indoors.
But last year I learned about two innovations that have been brought to market that dramatically increase the potential abilities of such a device.
— ⁂ —
It's entirely possible that your definition of 'any reasonable "work" performance level' is orders of magnitude higher than my "reasonably convenient programming environment". The VAX reference point is 1 Dhrystone MIPS, and the Macintosh SE (a 7.8 MHz 68000) was also about 1 Dhrystone MIPS. Current ARM7 Cortex designs deliver about 2 Dhrystone MIPS per MHz, so we're talking about 500kHz of ARM7 instructions here.
Without any fancy circuitry at all I was able to squeeze 8 mW out of a 38-mm-square solar panel from a dollar-store garden light, in direct sunlight. Theory predicts it should be capable of 200+ mW (16% efficiency, 1000 W/m²) so hopefully I can get better results out of other panels. The amorphous solar panels normally used on solar calculators, which work well indoors as well as in direct sunlight, are nominally about 10% efficient, which is to say, 10 mW/cm² in direct sunlight or 100 μW/cm² in office lighting. It's easy to imagine dedicating 30 cm² of surface area to solar panels, which would give you 300 mW outdoors or 3 mW indoors. (38 mm square is 14 cm². 30 cm² in medieval units is about 4⅝ square inches, depending on which inch you use.)
— ⁂ —
So, what kind of computer can you run on a milliwatt or so?
Ambiq sells an ultra-low-power Cortex-M4F called Apollo3 Blue with 1MiB Flash plus 384 KiB RAM; the datasheet claims that, when fully active, at 3.3 volts, it uses 68 μA plus 10 μA per MHz running application code, and it runs at up to 48 MHz bursting to 96 MHz. So at, say, 10 MHz (20 VAXen or Macintosh SEs), it should use 170 μA or 550 μW. At 48 MHz (100 VAXen or Mac SEs), 550 μA or 1.8 mW. I haven't tested it yet. SparkFun sells a devboard for US$22 at https://www.sparkfun.com/products/15444.
Remembering, of course, that benchmarks are always pretty bogus, we can still roughly approximate this 20 DMIPS performance level as being roughly the processing speed of a 386/40, 486/25, or SPARC 2, and the 200 DMIPS peak as being roughly the processing speed of a Pentium Pro, PowerMac 7100, or SPARC 20 — but with enormously less RAM, an enormously lower-latency "disk", and a lower bandwidth budget for the disk. And no MMU, so no fork() and no demand-paged executables. You do get memory protection, hardware floating point, and saturating arithmetic, but no MMX-like SIMD instructions.
— ⁂ —
If the computer's output isn't going to be just an earphone or something, though, you may need to spend substantial energy on a screen as well. Sharp makes a 400×240 "memory LCD" display (0.1 megapixels) used in, for example, Panic's Playdate handheld game console (https://youtu.be/uziFTK5c29k) which seems like it should enable submilliwatt personal computing; the datasheet says it uses 175 μW when being constantly updated with a worst-case update pattern at its maximum of 20 Hz. Adafruit sells a breakout board for the display for US$45: https://www.adafruit.com/product/4694
A VT100's character cell was 8×10 (https://sudonull.com/post/30508-Recreating-CRT-Fonts), so its 80×25 screen was 640×250, 0.16 megapixels, while the Macintosh SE was 512×342, 0.18 megapixels. Both of them were 1 bit deep: a pixel was either on or off. So two of these LCD screens together gives you more pixels than either of these two reference-point computers. However, the pixels are physically a lot smaller, which may compromise readability. (On the other hand, as you can see from the Playdate videos, you can do a lot of things on this display that a VT100 or Mac SE could never dream of doing because of lack of compute and RAM.)
— ⁂ —
So, I think it's eminently feasible now, although it probably wasn't feasible ten years ago. But it's going to be a challenge; I can't just compile Linux and fire up Vim. Even if Linux could run on these super-low-power computers, they don't have enough memory to recompile it.
Separate compilation was helpful not just for speeding up the edit-compile-run cycle but also for handling high-level languages in small memory spaces; if your compiler ran out of memory compiling a large source file, you could split it into two smaller source files and link them together. Getting Linux to compile that way would probably be more work than writing a new OS from scratch.
More inspiringly, though, Smalltalk-76 ran on an 8086 with 256KiB of RAM, all kinds of MacOS software ran in 512KiB of RAM, and the Ceres workstation built at ETH in 01987 to run Oberon had 2 MiB of RAM. So I'm confident that a fairly polished IDE experience is possible in 384KiB of RAM and 1 MiB of fast Flash, especially if supplemented with larger off-chip fast Flash. It ought to be possible to do much better than a C-compiler-on-DOS kind of thing.
But you can clearly write a usable GUI environment using a C compiler on DOS or a Pascal compiler on a Mac SE.
But then again, with a single-pass compiler, it shouldn't matter how large the input is, no? I know there are forks of tcc with ARM support...
Declarations change the parsing of C, so even a single-pass compiler needs to keep the declarations in memory somehow; cases like `foo * bar;` can be legally parsed as either a declaration of `bar` of type `foo*` or a (useless but legal) void-context multiplication of `foo` and `bar`, depending on whether `foo` has been declared as a type with typedef. Plus, of course, preprocessor macros can do arbitrary things. In PDP-11 C days it was common to put declarations of library functions directly into your code (with, of course, no argument types, since those didn't appear until ANSI C) instead of in a header file, and the header files were very small. Nowadays header files can be enormous, to the point that tokenizing them is often the bottleneck for (non-parallel) C compilation speed; often we even include extra totally unnecessary header files to facilitate sharing precompiled headers across C source files.
So I think it probably isn't straightforward to enable small computers to compile current C codebases like Linux.
tcc, however, would be an excellent thing to start with if you were going to try it.
Pointer-based trees seem like a natural way to handle compound types to me, but it's true that they can be bulky. Hash consing might keep that manageable. An alternative would be to represent types as some kind of stack bytecode: T_INT32 T_PTR T_PTR T_ARRAY 32 T_PTR T_INT32 T_FN or something for the type of int f(int *(*)[32]) or something (assuming int is int32_t). That would be only 11 bytes, assuming the array size is 4 bytes, but kind of a pain in the ass to compute with.
Interned strings — pointers to a symbol object or indexes into a symbol array — can be bigger than the underlying byte data. Slices of an mmap can be even bigger. This is of course silly when you have one of them in isolation — you need a pointer to it anyway — but it can start to add up when you have a bunch of them concatenated, like in a macro definition where you have a mixture of literal text and parameter references.
However, videos of the display hardware like https://youtu.be/zzJjE1VPKjI show that you can get really astonishing things out of 0.1 megapixels when you drive it with current levels of computation instead of, like, an 8085. (That video is a little misleading in that it claims "60 fps animation", while the datasheet claims the max is 20 fps.)