IRC channel logs

2019-10-08.log

back to list of logs

<dddddd>xentrac, no
<dddddd>rain2, nice!
<OriansJ>janneke: I made a breakthrough in mes-m2
<OriansJ>(I finally found how to eliminate temp.c) and soon I should be able to remove all of the compiling warnings
<xentrac>OriansJ: congratulations!
<OriansJ>Turns out the solution required converting a hundred constants into simple globals that needs only have limited reference
<OriansJ>also I think I broke the garbage collection but I can fix that later
<xentrac>rain2: collapseos looks like fun! "10K transistors" is exaggeration if we're talking about 56K of semiconductor RAM though
<OriansJ>Historically RISC-I had 44,500 transistors and RISC-II had 39,000 transistors but even if you removed nearly all of the transistors used in the Registers; you would still exceed 10K transistors and honestly there isn't much you would want to remove from that instruction set core.
<xentrac>collapseos runs on a Z80; the Z80 chip is a bit under 10K transistors
<xentrac>The MuP21 was a bit under 5K or something
<xentrac>I think the 6502 was 3500 transistors? but you need at least 4K of RAM and ROM for a reasonable interactive programming environment
<OriansJ>xentrac: I honestly believe that any bootstrap on anything smaller than 16bit ends up being the wrong route as it requires alot more complexity to squeeze programs into that memory address space
<OriansJ>one could do M2-Planet in 64KB but not 2^8
<OriansJ>and yes I do that a longer PC + relative displacement or Memory banks can be used to leverage more memory but that comes at a cost of complexity and development time
<OriansJ>DCPU-16 however is an interesting one (pity what happened to the 0x10^c community)
<xentrac>what happened to them?
<xentrac>yeah, I agree that any address space of less than 16-bit would be a mistake; even the PDP-8 with its 12 bits of 12-bit words was really limited
<xentrac>but the Z80, the 8080, and the 6502 all had 16-bit address spaces, as did the DG Nova
<xentrac>the MuP21 had a 20-bit address space of 20-bit words
<OriansJ>xentrac: well the game got cancelled and all of the people who wrote assembly programs for the DCPU-16; fractured into numerous groups all attempting to recreate the excitement the original promise provided. https://en.wikipedia.org/wiki/DCPU-16
<xentrac>the LGP-30 had 31-bit registers; its drum only contained 4096 words, but I think it probably could have had a 15-bit address space, which would be enough with such large words
<xentrac>huh, I wonder why they fragmented?
<xentrac>heh, a friend of mine who first programmed on the PDP-8 points out that you could reduce the number of transistors in your computer by using core memory
<OriansJ>xentrac: true but core memory costs about $1 per bit right now
<xentrac>interesting, at that price it might be worth manufacturing some new
<xentrac>it didn't cost that much in the 1970s, adjusted for inflation
<xentrac>I wonder why nobody is doing these self-hosted micro-OSes like CP/Mish, bootOS, and CollapseOS for ARM
<xentrac>well, bootOS is only sort of trivially self-hosted, but it wouldn't be hard to get there
<OriansJ>xentrac: probably because they don't have a need for one nor a desire to create one for fun
<xentrac>I guess people have different ideas of fun. an STM32F4 seems a lot more fun than a Kaypro to me even if it only has 32K of RAM
<OriansJ>xentrac: absolutely. Personally, I am partial to a good old PDP-10
<xentrac>haha
<xentrac>can't say I've ever had the pleasure
<xentrac>but any of the machines discussed above would be a great deal easier to build than a PDP-10
<OriansJ> http://simh.trailing-edge.com absolutely true
<OriansJ>it was a bitch to make even back when they had all of the parts brand new
<OriansJ>fortunately it can be implemented entirely on a single FPGA these days
<xentrac>oh, sure
<OriansJ>down to just 10 build warnings
<xentrac>congratulations!
<OriansJ>I think 1882 insertions(+) and 10671 deletions(-) is a big enough of a stopping point for tonight
<OriansJ>I am stopping at 4 warnings and 4 notes from the compiler
<OriansJ>(tonight, I'll probably try to clear these up tomorrow)
<OriansJ>and temp.c is finally freaking gone
<OriansJ>now at every point, one can load up gdb and inspect the structs being used and know exactly what they mean
<xentrac>that's wonderful!
<OriansJ>There are still a bunch of pieces that need clean up to make it look the way I prefer (and remove the work-alike functions like car(struct scm* a); when a->car means the same thing)
<OriansJ>and it looks like most of the contents of mes_init.c can be dropped entirely
<OriansJ>up next is figure out how to solve the struct scm** g_stack_array; in an M2-Planet fashion.
<xentrac>that's fantastic!
<xentrac>I've been reading through bootOS. I've read and commented about 20% of it so far
<xentrac>it's surprisingly non-transcendent so far
<xentrac>I mean things are done in simple ways that seem reasonable but it seems like you could maybe bum it a bit further
<xentrac>maybe I'll find out that the apparent optimization opportunities are not real
<xentrac>mostly I mean it seems like code that a normal person could write
<OriansJ>xentrac: most of the impressive pieces of code have to look simple, otherwise they couldn't have grown to the level required. Human minds can only track so much complexity (or engage in so much creativity).
***ChanServ sets mode: +o rekado_
<xentrac>yeah, that's not really what I'm talking about
<janneke> http://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ \o/
<janneke>finally, some of our work landed in guix ^
<xentrac>janneke: congratulations!
<janneke>xentrac: thank you!
<xentrac>:)
<true-grue> https://collapseos.org/why.html
<xentrac>yes, that popped up here the other day :)
<xentrac>not sure I agree with his rationale but it certainly seems like a fun project, and Z80 assembly certainly seems like a viable approach
<true-grue>Yes, it's a fun project :) And I'm also interested in program synthesis techniques too here. It could be a useful approach to bootstrap some complex software.
<xentrac>I agree! To the extent that we can use search algorithms and solvers, we can simplify our source code, sometimes greatly, at the possible expense of compute time and memory space
<xentrac>I mean compilers routinely do that kind of thing
<true-grue>Sure, basically we have only two really powerful technologies here: DSLs and program synthesis.
<xentrac>...constraint propagation, A* search, mathematical optimization, superoptimizers, recursive functions, functional programming, answer-set programming, branch-and-bound, generative testing, SAT solvers with DPLL and other algorithms,...
<xentrac>...theorem provers, type checking, decidable sound type checking in particular, compile-time metaprogramming, reflection, ...
<true-grue>Things from your former are program synthesis, just different ways to approach it.
<xentrac>well, you can use them for that (except for, I guess, superoptimizers)
<true-grue>Why not superoptimizers? I like them a lot :)
<xentrac>Superoptimizers are awesome! I just mean that you can use mathematical optimization or functioal programming or A* search when you're not doing program synthesis, but if you're using a superoptimizer, you're pretty much by definition doing program synthesis
<true-grue>There are some super optimizers that use a lot of different techniques.
<true-grue>For example: https://mangpo.net/papers/lens-asplos16.pdf
<true-grue>Basically you can use any methods to reduce search space in superoptimizer. And A*, branch-and-bound etc could help here too.
<true-grue>I made a superoptimizer for stack machine code (Forth, Python or JVM). It is based on Z3 (which is SMT solver) and CEGIS.
<xentrac>that's fantastic! I don't know about CEGIS
<true-grue>"Counterexample Guided Inductive Synthesis". What is cool about CEGIS is that with the help of Z3 you can generate programs with arbitrary constants inside.
<xentrac>how does that work?
<true-grue>xentrac, Here is a good paper about it https://pp.ipd.kit.edu/uploads/publikationen/buchwald18cgo.pdf
<true-grue>This one is even simpler to understand: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/pldi11-loopfree-synthesis.pdf
<xentrac>ooh, thanks!