<xentrac>argh, fucking Microsoft blocking wget <xentrac>I wonder if their synthesis algorithm is applicable to APLish things <true-grue>xentrac, Well, It works for stack and register machines. Should work for short combinator-based programs too. <OriansJ>xentrac: add user_agent = Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0 to your ~/.wgetrc <OriansJ>that'll solve the wget filtering problem <OriansJ>xentrac: sorry about misinterpreting your previous post <OriansJ>true-grue: I've been considering if porting M2-Planet+mescc-tools to it would be worth the trouble. As it would provide another possible root for our bootstrap but it also requires me to figure out how to squeeze 16KB of memory usage out of cc_x86 (unless I can get the z80 code dense enough) <xentrac>OriansJ: heh, probably. I just used links in this case! <xentrac>if you want to bootstrap from a microcontroller for trustworthiness purposes, it might be best to use a software emulator, like the AVR-CP/M emulator which I think did a Z80 <xentrac>but with a larger memory space, maybe <xentrac>since we can accept something like three orders of magnitude slowdown in that context <OriansJ>xentrac: I misinterpreted the "surprisingly non-transcendent" comment. <OriansJ>As for bootstrap, I was thinking of doing a custom architecture in TTL as my root of trust <OriansJ>and simply adding the Z80 and other common cheap microcontrollers as potential additional sources of trust that other people could easily leverage for their own root of trust <xentrac>it's not *bad* code, just doesn't have the inevitable-theorem quality of, say, qmail or something <xentrac>it does have some clever tricks in it; the loop over the built-in commands leaves SI pointing past the end of the command name in the command string, for example <xentrac>9-bit bytes and 18-bit address words might be a reasonable tradeoff for custom architecture. also, a bit-serial ALU will save you a lot of gates, but maybe using bitslice ALU chips is a better idea <xentrac>18-bit addresses would allow you to fit everything into 256KiB instead of 64KiB, which makes the problem a lot easier <xentrac>Wirth's RISC is probably a good design to look at for inspiration; it's almost as simple as Chifir or TECS Hack, but designed to be practical rather than uncompromisingly minimal <xentrac>I'm about halfway through bootOS now and I'm running into a lot of clever tricks now <xentrac>when I'm programming in 8088 assembly there are occasionally times when there's something I have to do that is possible but takes a great deal more ceremony than it seems like it should <xentrac>that isn't happening here, and I suspect that this is a question of thoughtful software design that flows with the machine's strengths instead of fighting it ***ChanServ sets mode: +o rekado
***xwvvvvwx- is now known as xwvvvvwx
***janneke_ is now known as janneke`
***coldtom8 is now known as coldtom
***janneke` is now known as janneke
***roptat_ is now known as roptat
***ng0_ is now known as ng0
<dgpv>looking at stage0/stage0_monitor.hex0 -- it seems it can be made at least 4 bytes shorter by replacing two instances of `LOADUI R1 0` with `FALSE R0` <dgpv>Although maybe `LOADUI R1 0` was used intentionally because it may be more clear to someone than `FALSE R0`.. but it is used in other place to zero out a register <dgpv>correction: replacing two instances of `LOADUI R1 0` with `FALSE R1` (made mistype R0/R1 here in the chat) <OriansJ`>dgpv: you are absolutely correct; I really haven't put any effort into making the original stage0_monitor any smaller and I am certain there are lots of easy gains to be made <dgpv>as I understand it needs to be somehow entered manually on the real hardware, so less bytes to enter should be better :-) <OriansJ`>dgpv: you are indeed correct, I am reviewing the commits for correctness now <OriansJ`>altough you appear to have made a minor false assumption with "sed 's/^[^#]*# //; s/^:[^[:space:]][^[:space:]]*/\0 ;/' stage0/stage0_monitor.hex0 > test/stage0_test_scratch/stage0_monitor.hex0.s" <OriansJ`>as bin/hex can build stage0/stage0_monitor.hex0 directly and there is no need to run it through the asm in test_stage0_monitor_asm_match <dgpv>the goal to do this is to make sure that comments actually match the hex <dgpv>If you edited the hex values you may forget to fix the comments <dgpv>and this test can catch some of this <dgpv>(can't catch the :label <offset> case) <OriansJ`>well we kind of can with hex0 but with hex1 it is a minor issue <dgpv>:hex 9a <--- this offset updated manually, but checking that it is indeed correct via the script seems too complex <OriansJ`>we can change the label comments to te form # :label ; offset = 9a to make it easier <dgpv>well I just solved it with additional sed substitution <dgpv>but this makes assumption about the format for :label comments <dgpv>should I push the change with `# :label ; offset = 9a` and simplified sed substitiution ? <OriansJ`>thank you for taking the time to help ^_^ <dgpv>I would love to tinker with bootstrap via lisp, but too much other work unfortunately <OriansJ`>dgpv: well we do have some small lisp programs that need being written if you are interested <dgpv>got one free day to dedicate to this, so I looked around the code to understand how it all works, maybe if I can find some more time in the future <OriansJ`>and if you need any clarification or help let us know ^_^ <dgpv>as I understand after looking, the road to bootstrap to lisp would be to implement the scheme that mes implements <dgpv>and then just use the mescc <dgpv>but this is indeed quite a lot of work <dgpv>and mes source code is not very easy read, especially around eval loop <dgpv>the lisp.s as currently implemented does not have macro facility, right ? <dgpv>yes I've seen m2, too. It is a bit easier <OriansJ`>So no macros nor tail-recursive but easily buildable via M2-Planet <OriansJ`>In the end mes-m2 will end up sharing a great deal with slow_lisp in terms of implementation details; while including all of the additional functionality that janneke needs for MesCC. with possibly extensions needed to support Guix <dgpv>so now you actually can bootstrap from scratch, but only for x86, right ? <dgpv>because you have c compiler in asm that targets x86 <dgpv>and if theres a bootstrap path via lisp it will be architecture independent <OriansJ`>I currently have 3 bootstraps from scratch to M2-Planet (which is cross-platform by default) and once it can build mes-m2; we instantly have the ability to run MesCC on all platforms supported by M2-Planet <OriansJ`>MesCC doesn't support as many architectures as M2-Planet yet but that can be fixed later and with much less work than me doing another port from scratch <OriansJ`>dddddd: is currently getting aarch64 ported to M2-Planet (and we support making armv7l binaries [that also work on armv6 too]) <OriansJ`>So once mes-m2 is done, I am going to do a from scratch for armv7l and aarch64; so that we will have 5 seperate architectures that are all able to reproduce all binaries used by all other architectures; thus forcing any hardware based attacks to have to be identical on all hardware architectures under test <dgpv>ok so that forth/lisp path on stage2 is not of practical importance now <dgpv>only relevant as a demonstration that it can be done <OriansJ`>dgpv: essentially they were false paths based on people's largely unfounded beliefs on the easiest way to bootstrap complex software <xentrac>I still think forth+lisp is probably the easiest way to bootstrap complex software but I admit this is not founded on actual success doing it :) <OriansJ`>writing a lisp in assembly is harder than writing a C compiler in assembly and if you don't build it with macros and tail recursion by default it is good as useless.