IRC channel logs

2020-02-18.log

back to list of logs

<dddddd>So this M1.scm is not required?
<stikonas>there is M1 written in M2 subset of C
<OriansJ>It is already being built in mescc-tools-seed
<dddddd>why am I doing it?
<stikonas>ooops. Shouldn't have asked about it :D
<OriansJ>for a scheme only bootstrap for guix
<OriansJ>that way the the transition from guix to use mes-m2 is an atomic action
<OriansJ>aka replace the statically built guile binary with mes-m2 binary and no further work would be required
<OriansJ>It also gives MesCC complete freedom to evolve slow-utils into a future competitor to bin-utils as MesCC grows into a GCC competitor
<OriansJ>That way mescc-tools could avoid picking up features and instead slim down to enable easier porting and more clarity
<OriansJ>dddddd: honestly, I am grateful to you for helping me finish it
<dddddd>It's my pleasure, as always, OriansJ. Just a bit scared for a moment, confused about the real need (to prioritize another task).
<OriansJ>dddddd: I feel it is a priority (just a step below mes-m2)
<OriansJ>as is having janneke pull out all binaries, except for guile from the guix bootstrap
<fossy>OriansJ: yes that map is accurate as per commencement.scm
<OriansJ>civodul can deal with having the last NixOS C++ binaries pulled out of guix (if he hasn't had that done already)
<OriansJ>fossy: thank you for helping me clarify as I was confused by the going through the GCC 2 series bit
<dddddd>I tried the "pyramid" test (well, a similar one I already had) and looks good except in some cases: the Knight padding breaks the concept in weird ways.
<dddddd>^ wrt the changes to hexify_string(), to be clear.
<dddddd>Implementation-wise, that "+ 12" and some change in the knight part are quite opaque.
<OriansJ>dddddd: completely fair, hence why I would not have a problem if slow-util's M1 doesn't do it
<fossy>OriansJ: all g
<xentrac> http://nandgame.com/ is pretty cool
<dddddd>OriansJ, I'd prefer to output the same, only if to help testing (easy comparing, looking for bugs in the reimplementation), but this C needs a bit of love, I think.
<OriansJ>dddddd: completely fair
<OriansJ>xentrac: here I was thinking you were posting this: https://www.nand2tetris.org/
<xentrac>I think it's a repackaging of that
<xentrac>in particular the rather goofy ALU design is the same
<OriansJ>xentrac: I think you are right
<xentrac>it skips a few of the steps and doesn't use a textual netlist HDL
<xentrac>I think it might be dropping the barrier to entry by a lot though
<xentrac>interestingly, the final CPU is supposedly only 2084 NAND gates