IRC channel logs

2022-11-03.log

back to list of logs

<stikonas>128 KB would need quite a few tweaks for cc_*
<oriansj>muurkha: very true but the programmers of that era were able to create things like GEOS and the average size of hello world in this era is 50MB
<stikonas>we use way more stack space right now
<oriansj>stikonas: only because we used recursion instead of iteration for outputting the final text
<stikonas>but we still need to read quite a lot of source code
<stikonas>M2-0.C is already 128 KiB
<oriansj>stikonas: you can drop buffering and only keep 3 tokens in memory at a time
<stikonas>well, yes, that would work
<oriansj>and that isn't even counting the dirty hacks to cut memory usage that is certainly possible
<muurkha>oriansj: that's just a matter of what you spend effort on. and there's probably more people today writing 8-bit assembly code than ever before, and a lot of it is for processors with well under a kilobyte
<oriansj>muurkha: I used to buy that class of argument; but I don't think enough people have kept those skills sharp enough to make a GEOS today. The closest we have is contiki which uses 10KB for the core and an extra 30KB just to have GUI (and 30KB of ROM)
<oriansj>vs GEOS which was 20K ROM of which 7 KB Kernal and the rest of the 64KB was used for the application running
<muurkha>I think that's mostly because Contiki is written in C by one guy
<muurkha>part time
<muurkha>while GEOS was written in assembly by like five people full time
<muurkha>it takes longer to get stuff running in assembly but it takes up less space
<oriansj>Contiki has been in development for 19 years
<oriansj>vs GEOS which from start to finish was 3 months
<muurkha>no, GEOS was developed for many years
<muurkha>it was runnable after 3 months
<muurkha>also I don't see 40K as so dramatically different from 27K
<muurkha>though admittedly if you have 48K there is a major practical difference
<muurkha>but I mean it's not like Dunkels's compiled C is taking up twice or three times as much memory
<oriansj>well 64KB was all one had on a C64 running GEOS
<muurkha>you could make it a lot smaller if you could afford to keep most of it in the form of a compact bytecode
<muurkha>on the C64 that would have made it run too slow
<oriansj>atleast it ran
<muurkha>have you seen https://rossumblog.com/?
<oriansj>not yet
<oriansj>but the ESP32 hacks seem neat
<muurkha>the neater stuff to me is what he did on much more limited hardware than the ESP32
<muurkha>like, I was pretty sure that synthesizing the NTSC color subcarrier on an ATMega328 was impossible: https://github.com/rossumur/Arduinocade
<muurkha>he didn't just write the cycle-accurate color waveform synthesis code on an overclocked ATMega though
<muurkha>he also wrote four games
<oriansj>definitely neat
<oriansj>although I'd say I am partial to: https://nanochess.org/index.html
<oriansj>as BootOS is probably the most compact OS I know of
<oriansj>but that is more of the exception that kind of proves the rule. (exceptionally few people have the chance to grow up in a family with such programming talent)
<oriansj>but perhaps it is an ecosystem argument. Where if a given class of problem is solved enough, that the skilled needed to push that domain farther decays over time. (aka Unity existing has reduced the number of people who work on Game engines by an order of magnitude and as people age out (or die) the skills needed disappear)
<pabs3>that comment reminds me of https://berthub.eu/articles/posts/how-tech-loses-out/
***ChanServ sets mode: +o oriansj
<oriansj>pabs3: good link and the pdf reference inside is a great find as well
***civodul` is now known as civodul