<oriansj>stikonas: no I did not do further testing on the qemu performance issue yet to replicate your results on other architectures but it does look promising enough to explore and implement accordingly. <oriansj>also the upstream blynn-compiler seems to be doing some impressive changes (which would require a rebase and work to restore the M2-Planet bootstrap path) which with hope might solve our Haskell bootstrap problem. <stikonas>well, I basically can reproduce that slow issue with all early binaries <stikonas>possibly due to them having section headers <fossy>theruran: What is vau expressions <fossy>anyway we dont want to he locked to any specific kernel <stikonas>and I think some issues are already fixed <stikonas>I guess somewhat confusingly named programming language <fossy>stikonas: thanks for the review. Yes some of them are already fixed in newer commits :) <theruran>fossy: mm.. vau expressions let you decide exactly when/where to evaluate an expression. Kernel does not have macros in the Scheme sense. vau expressions are a simpler construct that macros and would let you write lazy/eager code easily <xentrac>I think which is simpler depends on which sense of "simpler" you mean <janneke>theruran: about __raise; that's weird i'd need more info to look into that. there are some __raise related patches on wip-m2 that you could try, have you tried the wip-m2 branch (soon to be merged)? <janneke>on master, __raise is defined in */syscall-internal.c <theruran>janneke: no, but I will try that later for you and let you know the results <theruran>xentrac: Shutt made some strong arguments about it. You can read his doctoral dissertation ;) <xentrac>so I think it's clear that vau is more analytically tractable than term rewriting. but I think we can make a strong argument that term rewriting is simpler to define and simpler to implement than vau expressions — though not as much as you'd think <theruran>he cites Mitchell Wand, “The Theory of Fexprs is Trivial” <xentrac>and hygienic macros are not at all simple to define or implement <xentrac>hmm, did that bogus color come through? <theruran>as the syntax-case implementation would indicate <xentrac>an interesting thing about vau is that it seems to provide an easy way to capture a lexical environment: ($vau () e e) <xentrac>that is, it makes environments first-class in the same way Scheme's call/cc makes continuations first-class <theruran>my impression is that writing a bootstrappable implementation of syntax-case requires some serious mental gymnastics of remembering when an expression is evaluated or not, and that vau expressions may make those gymnastics easier to manage. but I'm not experienced enough to know so <xentrac>which means that you can use them as dictionaries <xentrac>well. at least to read and update, maybe not to insert <xentrac>I think Wouter van Oortmerssen wrote an experimental programming language based on nothing but that <xentrac>hmm, I think you can use them as dictionaries to insert as well <xentrac>but only if you can eval an S-expression, which is functionality I think of as sort of separable from things like vau and call/cc <theruran>I think you call wrap on an operative to turn it into an applicative (like a Scheme procedure) <theruran>($define! get-current-environment (wrap ($vau () e e))) <xentrac>do you have a link to the short paper? <xentrac>I'm curious what you lose if you define $if in terms of an exec-in procedure instead of eval <xentrac>($vau (x y z) env ($cond ((exec-in x env) (exec-in y env)) (#t (exec-in z env)))) <xentrac>the difference being that x, y, and z are not lists, but code objects you can't necessarily construct at run time <theruran>but I guess Shutt argued in his dissertation that it's not so trivial <theruran>"Not only did that paper demonstrate the trivialization of theory that, in the vocabulary of this dissertation, <theruran>can result from the introduction of fexprs into an implicit-evaluation calculus, but it also presented a compellingly plausible intuitive argument that this trivialization of theory is an inherent consequence of the introduction of fexprs into λ-calculus." <theruran>"The “fexprs” investigated by [Wa98] are a dramatically different facility than the “fexprs” investigated by this dissertation; and, partly entangled with that difference of terminology, [Wa98] assumes an isomorphism between source expressions and computational states, while this dissertation does not. This chapter explores the depth and consequences of these discrepancies." <xentrac>and it doesn't even state its thesis <xentrac>Chapter 1 is entitled "the thesis" but I haven't found a thesis in it yet <xentrac>maybe this is the thesis: "Such a solution does in fact exist: a combination of semantic assumptions that supports fexprs in a well-behaved and simple way." <xentrac>oh, maybe this is it (hi attila_lendvai!) <xentrac>"...the severe difficulties attendant on fexprs in the past are not essential, and can be overcome by judicious coordination with other elements of language design. In particular, fexprs can form the basis for a simple, well-behaved Scheme-like language, subsuming traditional abstractions without a multi-phase model of evaluation." <xentrac>was discussing it with theruran and thinking you might be interested in this <xentrac>I feel like that thesis statement could be made a lot more rigorous, because whether a given language is "simple", "well-behaved", or "Scheme-like" is pretty debatable <theruran>the formal semantics of the language were never defined. the section in the Revised Report is a stub <theruran>section 6.4 of the dissertation covers hygienic macros ***wowaname is now known as opal
<stikonas>shaved off lots of bytes from hex0_riscv64 bootstrap seed, it now only has 392B, almost a hundred bytes smaller than first original version (which was 485B) and is now smaller than AMD64 binary (405B). And it's also much faster under qemu <stikonas>and together with kaem-micro it's only 753B <xentrac>congratulations, stikonas! that's wonderful! <Hagfish>apparently base2048 can encode 385 bytes per tweet <Hagfish>i don't expect you to try shaving off another 7 bytes to fit that arbitrary limit, though <stikonas>I guess I'll have to start working on cc_riscv64 next... <stikonas>but at least it can be written in M1 assembly and not hex <xentrac>writing RISC-V code in hex sounds like a real headache <stikonas>writing any hex code (not just risc-v) is tedious <stikonas>well, hex2 code is somewhat better but you still need to encode immediate values manually <xentrac>stikonas: I guess RS1_SP RS2_A0 SB doesn't need a magic sigil for the immediate because there's no immediate? <stikonas>in non-risc-v M1 I think you would need 0 <stikonas>but in risc-v we construct words using that . symbol to combined all these constants <stikonas>we were kind of forced into this because in risc-v all these things are not byte alinged <stikonas>so it was easier to encode things this way <xentrac>jessica clarke points out that if you want to build an auditable CPU in hardware, maybe it would be better to make a version of RISC-V with "un-jumbled fields" <xentrac>that is, put the extra muxes into the hardware that the RISC-V instruction format avoids, so that you can put them wherever you want. you still have non-byte-aligned fields but at least you can read the hex more easily <stikonas>well, once you have hex1, most of these problems are gone <stikonas>there are still immediate constants but at least jumps and branches are dealt with <stikonas>(and immediate constants are often the same in various parts of the program, so can be copy-pasted) <stikonas>i.e. you always have the same 8, 16, 24... for preparing stack <xentrac>well, the other thing we need to write in hex (or at least audit) is the kernel <stikonas>xentrac: I don't think that's the easiest way <stikonas>probably it is easier to adjust hex0 to run baremetal <stikonas>although it won't be fully portable then <stikonas>basically you need to load all the sources into some addresses in the memory <stikonas>build hex1 into some other memory location <stikonas>hex0 only uses sys_read and sys_write (and sys_exit) syscalls <stikonas>then the problem becomes how to load everything into memory (or some other chip that CPU can address and you can manually bit-bang) <stikonas>then hex1 can again read from some other memory location where hex2 source is and build hex2 binary and jump into it <stikonas>it's not too convenient but definitely easier than writing kernel in hex0 <stikonas>then you can at least postpone kernel until you have assembly or C <xentrac>a fair bit of its code is already system calls <stikonas>some more care might be needed if you jump-link programs without kernel but it's managable (e.g. might need to zero registers) <stikonas>well, the whole thing might need some modifications to run on baremetal and get rid of syscalls but it's not that big of a change... <stikonas>(assuming you can somehow input sources into your memory) <stikonas>(I guess that's what hex0-monitor kind of used on knight) <stikonas>to avoid loading everything in one go... <stikonas>so you load once small program and type the rest <xentrac>I just said on #riscv: > stikonas points out that it's probably simpler to run cut-down versions of hex0, hex1, and hex2 as subroutines that read and write RAM than it is to implement a kernel in hex that is sufficient to run them <xentrac>> and if you do that you can write the kernel in assembly instead of hex, which would be a big improvement <xentrac>inputting sources into memory isn't any harder than inputting binaries into memory <xentrac>I think jessica may have lost interest :) <stikonas>but stage0 is a good "tutorial" if you want to learn some assembly programming <xentrac>the usual approach for booting a computer with no ROM is to toggle a small binary bootstrap program into RAM which is sufficient to load the rest of your code <xentrac>the initial bootstrap program is typically just a loop that initiates an input operation and then busy-waits on the device in PIO mode <xentrac>depending on the I/O device your second-stage bootstrap might be 80 bytes, or 512, or unlimited