IRC channel logs
2023-11-02.log
back to list of logs
<stikonas>ekaitz: oh, the big thing in M2 compared to cc <stikonas>is that M2-Planet has some support for C preprocessor <ekaitz>that's the kind of information i was looking for <oriansj>M2-Planet compared to cc_* is like a car compared to the first bicycles; much more stable, robust, survives bad code better, much faster and carries a boatload more features <oriansj>(such as a basic C preprocessor (cc_* doesn't support any preprocessing)) <oriansj>the closest it has is // CONSTANT name number <oriansj>struct foo {int a[50];}; is another example feature <oriansj>M2-Planet is 140KB in size but cc_* is only 14KB <stikonas>depends on your electricity supply, if you run on solar or wind than no <oriansj>M2-Planet needs about 2MB to self-host <stikonas>well, self-host if you use full-features M2libc <oriansj>but cc_* can compile M2-Planet in only 256KB <stikonas>basically we first build simplified M2 with only really tiny libc <vagrantc>maybe someday we can have a proper bicycle based bootstrap chain. :) <stikonas>and then we use it to build C versions of earlier hex tools <stikonas>and then rebuild M2-planet using just C toolchain <oriansj>which reads and writes exactly 1 byte at a time vs M2-Planet which reads and writes are fully buffered and way faster <stikonas>and then we go to mes which again reads 1 byte at a time <oriansj>huge performance difference between cc_* built M2-Planet and self-hosted M2-Planet <oriansj>stikonas: really? I thought janneke used a C library which buffered reads and writes? <stikonas>oriansj: hmm, I don't think there is buffering <stikonas>still, it's not the slowest thing in mes <stikonas>like we discussed, especially after porting away from switch <oriansj>correction the cc_* built version of M2-Planet is 256KB, the self-hosted M2-Planet is 316KB (much more library code to speed things up) <oriansj>part of me wonders if a scheme compiler written in the C subset M2-Planet supports would speed up the mescc bootstrap section <oriansj>true and all of the scheme compilers I have seen are written in scheme <muurkha>yeah, it makes sense that you'd bootstrap scheme by running your scheme compiler under a scheme interpreter written in some other language <muurkha>I mean, for a much wider set of values of "you" <stikonas>M2-Planet -> mes-m2 -> scheme_compiler -> mescc binary <muurkha>like "any random Scheme implementor in history" <muurkha>unless that other language is something better suited for writing compilers than Scheme, such as OCaml <oriansj>well given enough skill a compiler can be written in any language but I am uncertain that OCaml is used as the bootstrapping language of choice for compilers for new languages. <stikonas>I should probably write to a mailing list too <muurkha>oriansj: OCaml is a pretty reasonable language for one person to write a compiler in, better than Scheme, which in turn is better than C <muurkha>I forget where the original Caml bootstrap chain came from, but I doubt it's C <oriansj>stikonas: savannah has append only git history bit set; so I did a 1.5.1 tag for mescc-tools which points to the current head <oriansj>muurkha: well OCaml came from ML and that has some history with Modula but I can't say I know the ugly details. <oriansj>but more to the point, compilers probably are best written in languages where pattern matching and state machines are most easily written. <oriansj>but I do know Coq was used in OCaml's creation <muurkha>Modula and ML are pretty unrelated, and I think it's reasonable to say that OCaml was sort of written in order to write Coq in <muurkha>so Coq was important to OCaml's creation <muurkha>Scheme and C and Modula don't have pattern matching; Prolog and Haskell and OCaml and other dialects of ML do <muurkha>I do feel like pattern matching is pretty useful for that <muurkha>also though I find OCaml's type checking useful <oriansj>well, type checking is generally helpful for writing correct code but that isn't specific to writing compilers. <oriansj>but I am a firm believer in static *extremely* strongly typed languages. To the point where I find virtually all languages lacking <oriansj>like give me an int with carry bit and borrow bit <oriansj>give me a type where I can specify big or little endian for the data <oriansj>and then do the right thing on all architectures <muurkha>writing correct code is I think significantly harder for compilers than for, say, GUI toolkits <muurkha>and when it screws up it's significantly harder to debug <muurkha>it'd be interesting to see your type system fleshed out <oriansj>on a notebook for my ideal programming language <theruran>and it probably is the only one that can <theruran>for the other thing, you can define a record with the carry bit and borrow bit and then force it into a size <muurkha>these are definitely not features of Ada I learned about in the past <theruran>I'm pretty sure you could define that type in detail and make it portable with Ada's features, unlike other language's approximations <oriansj>and the bit ordering appears to be a keyword modifying a single thing. kinda like unsigned long <theruran>Bit_Ordering comes up when a system sends some data in different endianness, so you can specify which one you are expecting and the compiler will deal with it accordingly <oriansj>well in C, you would just have #IFDEF bigendian block and an #ELSE block around things where different bit orders mattered. <oriansj>but yes transparently not having to do more than specify it is something that needs to be explicitly included. <oriansj>things like unsigned long are just better being u_int64_be so you know it is both unsigned, an int of exactly 64bits and all in big endian format <oriansj>and one needs to be able to specific more than just byte endian but also bit endian separately <oriansj>or s_int23_le to specify a 23bit signed integer in little endian format <oriansj>although I think my ideas are a bit too wordy <muurkha>maybe what you want is VHDL actually <muurkha>which is not Ada but is based on Ada <muurkha>VHDL even has different types of bits <oriansj>but not generally compiled to running binaries <muurkha>compiling it to running binaries is usually how most of the testing is done <oriansj>I thought it was generally compiled to FPGA bits for running <muurkha>because interpretation runs too slow and reprogramming FPGAs involves slow synthesis and place-and-route steps <muurkha>so usually designers do most of their testing by compiling to the machine code for a CPU <oriansj>perhaps my calling is hardware design <muurkha>a lot of hardware designers use Verilog instead <cedb>the "higher level" the language the better they map to hardware design ironically <muurkha>I wouldn't describe Verilog or VHDL as high-level languages <muurkha>which languages are you thinking of? <cedb>i know of hs-clash but theres a bunch of stuff in the logic/dataflow waters towards that <cedb>muurkha: theres this conor elliot paper on compilling to circuits if you havent read it its pretty neat <muurkha>Conal's papers are always worth reading <oriansj>muurkha: reading the VHDL standard, it looks like the bit ordering appears to be a user specified detail not as something that exists as a standard type <cedb>man that guy really has a rep amongst the crazies of us eh <cedb>its weird how i dont hear him mentionned outside random people geeking out on plt <muurkha>I don't think things like Haskell and ML map very easily to hardware <cedb>they map better to hardware design not hardware instructions huge difference <muurkha>a hardware design is fixed in size (once you tape it out, anyway) and has everything happening at once <cedb>digital logic usually doesnt have much state and if so its instant propagation of change its a very different way to think about stuff <muurkha>also hardware fundamentally operates through changing state over time <oriansj>plus there are some exotic integer types beyound 1 and 2's complement <cedb>depends what; a filter is a filter <oriansj>like symmetric complement where divide by zero is just NaN <cedb>i dont see how that applies to this <muurkha>a Haskell program can handle problems of any size and doesn't have any way to talk about what's happening at once, and if you have state at all, it's usually the IO monad, which imposes a strict total ordering of all state changes <muurkha>which is kind of the opposite extreme from a hardware design in every way <muurkha>oriansj: interesting, I hadn't heard of symmetric complement <cedb>i mean lower vs higher is not well defined we just have somewhat arbitrary historical reasons that force us to deal with turing machines which are much much harder to reason about in rigorous logic terms <muurkha>also FWIW in hardware design, data doesn't propagate instantly; it depends on things like fanout and number of propagation delays <muurkha>in standard synchronous design you slow the clock down until it has reliably propagated before the next clock cycle <cedb>a program described as a sequence of immutable mappings maps to hardware, even if you have state its not gonna look like what you do in C <cedb>yesyes theres bs to manage of course of course <muurkha>so in a sense it looks like "instant propagation of change" <oriansj>4 bit symmetric complement would have 0000 =>0; 0001 => 1; 1110 => -1 and 1111 => NaN <cedb>i just mean people want to synthesize a given mapping that is immediately reproducible <muurkha>but managing that "bs" is kind of central to the activity of hardware design <muurkha>like, generally you care actually a lot whether your clock is 4 MHz, 40 MHz, or 400 MHz <muurkha>and you want to be able to find out which signal propagation path is limiting you to 4 MHz so you can fix the problem <cedb>of course i just meant you deal with those things that way because fundamentally youre pushing the abstract concept towards something <muurkha>oriansj: hmm, so it's ones-complement but without the double zero? <cedb>like 01 is never 01 obv but you want it to be <muurkha>oriansj: it sounds like addition would be difficult <muurkha>because you need 1's-complement end-around carry, but with a special case to avoid negative zero <cedb>sounds like some flag that has semantics changing depending <muurkha>(I'm not a hardware designer, btw, I've never built a circuit more complicated than a 4-bit ALU or something) <muurkha>cedb: yeah, it's important to be able to specify what you're trying to make your hardware do <cedb>ive just done bullshit in EE way back <muurkha>but there's an interplay between what is easy and what is desired <cedb>but the FP mapping to vlsi that i member from grad school <cedb>because thats essentially what deep learning boom was about <cedb>muurkha: tf and torch give you some kind of functional dsl and compile it to highly parallel hardware. and the same people that did this keep working towards compiling across the architecture down to the gate <cedb>or at least make those this contact point less harsh <muurkha>it's true that tensorflow and torch are kind of functional and that they map well to hardware <cedb>another way to put it would be that its really really hard to synthesize hardware and the less state the easier period <muurkha>I think they're kind of less functional than their predecessor APL <cedb>theyre both numerical but not same goal <oriansj>cedb: I think the complexity in hardware is usually understated for example, one could write a huge book on just the history and techniques in PCB creation. <cedb>not understated just abstracted away like most things <oriansj>and those abstracted details can end up extremely important <cedb>depends where you live i guess too me im in canada, not much going on in terms of /making/ things heh <cedb>i mean were on #bootstrappable obv this is a thing <muurkha>oriansj: I am pretty sure there is more than one huge book on that <oriansj>muurkha: probably, same goes for even the wires themselves <cedb>ugh im a little mad i never made a decent little thing involving sending gerber files to a plant (or halfhass print it myuself if i stillhave zero things in my life at that point) <oriansj>like even a little things turn out to be these 4-d puzzles to ensure certain properties are exactly right <cedb>oh the amount of bs you have to deal with for real hardware is just ridiculous <oriansj>and the stories from Oxide's bring up lab really show just a glimpse of the crazy in hardware <cedb>oh so the mozilla cool kids that got laid off? <oriansj>basically a bunch of old Sun engineers got together to bring hyperscaling to anyone who wants it <cedb>so like sifive is doen right <oriansj>not exactly as they are buying parts from other companies but they are integrating them and publishing the source code in a free license but priced it to make money off the hardware sold. <oriansj>turn key, your data center everything configured in software which you have the full source code to. With the unique property of you have the source code for your firmware too <cedb>but they moving to india and its fabless like you said and they were mostly recruiting top peeps from the codegen field who now are at mojo iirc <oriansj>well, their corporate bit, I am not sure of. But their stories from their bring up lab do really paint a picture about how exacting computing hardware must be in its creation and that a single line of code can be the difference between completely non-booting machines and everything works flawlessly. <cedb>i mean yeah its hw you touch athing and everythings fucked tahts why i yeeted back to theory <oriansj>perhaps I am hopeful that one day I'll find someone who teaches Lee Felsenstein's hardware design techiques as the sol-20 was just so robust. <oriansj>and I figure, I better make anything I do in hardware robust as hell to match my software style. (which is multiple month long fuzzing runs to find defects) <jcowan>muurkha: Scheme has portable pattern-matching libraries <muurkha>Scheme has regexp libraries but also pattern-matching macros in the ML sense, which you can't do in C. jcowan, which do you recommend? <oriansj>but one could argue any feature not in the default core language will have multiple incompatible implementations (like async in Rust) <muurkha>oriansj: probably Lee would be delighted to teach you about hardware design <jcowan>I don't consider regex matching to be pattern matching in the ML sense, because it does not bind submatches to variables. <muurkha>oriansj: I haven't talked to him in a few years, it's possible he's not as mentally alert as he was. but if he is, he's assuredly still eager to share everything he knows with you or anyone else who is interested <muurkha>it's like a defining feature of his personality <muurkha>jcowan: which pattern-matching (in the ML sense!) library do you recommend for Scheme? <stikonas>but do you really need that complicated pattern matching in a compiler? <jcowan>Any will do. WCS is the most popular <stikonas>e.g. M2-Planet simply does strng comparison (something like strcmp) and it's working just fine <muurkha>stikonas: you can write compilers without pattern-matching, but it's much easier to write compilers with pattern matching. note that WE ARE NOT TALKING ABOUT PATTERN MATCHING STRINGS <muurkha>we are talking about the ML feature which allows you to write things like Add (Constant x) y => Addi(x, y) <muurkha>that's definitely a prominent thing you can use it for <muurkha>there are sometimes other kinds of trees in compilers that are not syntax trees <muurkha>jcowan: SRFI 204 appears to be withdrawn? <jcowan>Only for trivial reasons. mnieper kept pushing for extensibility, which hopefully is now satisfied (insofar as he is ever satisfied) by dpk's extensible-match pre-SRFI. I keep meaning to reawaken the SRFI with a few deletions. <oriansj>muurkha: you are absolutely right, he called after I emailed him. 