IRC channel logs

2020-02-22.log

back to list of logs

<OriansJ>markjenkinsznc: I have an idea you might like; I revise M0-macro.{s,hex2} to leverage only 16bit pointers and work withing 64KB and then simply create M0-macro-compact.s which will include architecture specific size detection and have memory reduction optimizations
<OriansJ>This little tweak will enable M0-minimal.s to self-host in 38KB https://paste.debian.net/1131508/
<OriansJ>markjenkinsznc: so what I am going to do is first prototype a more memory efficient version of M0 for knight and then use it as the map for writing it in M0 macro assembly
<OriansJ>Then I'll revise the steps to leverage the much more memory efficient version of M0
<OriansJ>(now just figuring out how to minimize data movements to cut down on CPU cycles)
<OriansJ>I can probably even add some basic error catching into M0-macro-compact.S
<OriansJ>markjenkinsznc: if we want cc_*'s outputs to run on a 16bit machine; we will probably need to figure out some good size optimizations for M2-Planet's output (which I can then backport)
<OriansJ>perhaps some seperate Compiler passes
<OriansJ>like a generic optimizer and then a specializer. It'll be compute inefficient but end up making M2-Planet simpler and ligher in terms of system requirements
<OriansJ>I probably even could add some basic range checking into M0 to catch obvious problems
<OriansJ>The high level prototype is up
<OriansJ>Ironic that this change now means one can put the defines after its use and it'll work. Which is effectively more flexible and might end up being backported to M1 (if such flexiblity is so desired)
<OriansJ>It also means the last version of a DEFINE is the first applied but M1 already should be throwing flags for duplicate definitions
<OriansJ>perhaps a code smell to be aware of in M0 programs (DEFINEs should be at the top and alphabetically sorted sort of thing)
<OriansJ>bauen1_: when you get a chance, test running a copy of mescc-tools-seed on your kernel. If all successful It'll be ready to start converting into M2-Planet form. (Then I can take a wack at getting it into M2-Planet buildable form)
<xentrac>sorry I fell offline and missed any messags directed to me
<OriansJ>xentrac: http://logs.guix.gnu.org/bootstrappable
<fossy>Woo, finished refactor of kaem
<fossy>I now feel like it would make sense to write a testsuite
<xentrac>it helps with refactoring
<fossy>since I am getting a ton of segfaults
<xentrac>it helps with debugging
<OriansJ>fossy: don't forget to create a monkey_lives flag
<fossy>huh?
<xentrac>OriansJ: oh, ALON? ALON might or might not increase longevity over the fused quartz used in, for example, the Arch Mission disc in orbit with Starman
<OriansJ>fossy: so that when you fuzz the program; it can't execute anything dangerous
<fossy>like rm -rf /? :p
<OriansJ> https://www.folklore.org/StoryView.py?story=Monkey_Lives.txt
<OriansJ>fossy: well that is one definite sort of thing you'll want to avoid happening by accident when fuzzing
<fossy>yes
<fossy>not completely sure how to implement this...
<xentrac>crystalline materials have some disadvantages for some forms of archival; they're anisotropic, which makes it harder to control engraving processes, and their low-energy state is when the crystal is perfect, which is why you can often reduce defects in gems by heat treatment
<fossy>maybe a hardcoded array of dangerous commands?
<xentrac>no, a hardcoded array of not-dangerous commands
<OriansJ>fossy: or simply create a variable called int monkey_lives and not execve anything if it is set to TRUE
<fossy>well, that'll miss out on some extremely edge cases but thats ok
<xentrac>anyway, so imperfections in crystals, which are sort of by definition what you need to record information, are unstable over long periods of time; imperfections in glasses are, I think, less so
<OriansJ>xentrac: thinking deeper on the idea; religious symbols on the outside and the contents of that religion's text internal with the information you want preserved as possible ways to increase the odds of some surviving
<xentrac>remember the Maya codices tho
<xentrac>and all the idols of Arabia before Muhammad
<OriansJ>xentrac: valid point;
<xentrac>I mean it does reduce the chance of it ending up in an incinerator after not selling at a garage sale
<xentrac>but it increases the risk of iconoclasm
<OriansJ>xentrac: true; which is why a variety of external cases reduces the odds that all will be destroyed
<xentrac>yes!
<OriansJ>xentrac: I was also thinking of using a different material internally for information storage than externally for protection/optical defense.