<dgpv>macros yes, tail recursion no <xentrac>really? "a Lisp" can be a pretty wide range of languages, while "a C compiler" is very specific and requires a lot of coercion rules <dgpv>well if you make a compiler that is specific to particular codebase <xentrac>last time I wrote a self-compiling Lisp it took me three weeks --- *with* tail recursion and "macros" <xentrac>I don't think I could do a C compiler in less than three months, based on people trying <OriansJ`>xentrac: I wrote a self-hosting C compiler in a day in assembly <xentrac>...self-hosting, in assembly? Wouldn't that make it an assembler, not a C compiler? <OriansJ`>xentrac: as in it can build it's C code version that is self-hosting <xentrac>I see! yeah, presumably you could do that with Lisp if the Lisp was semantically clsoe to C <xentrac>you wrote 5000 lines of code in a day? <OriansJ`>rather easy when most of it is very similiar <dgpv>OriansJ` dgpv: well we do have some small lisp programs that need being written if you are interested <xentrac>I don't think I could even type that fast <dgpv>> 5000 lines of code in a day? <dgpv>including the debugging ? :) <OriansJ`>dgpv: yeah, notice the debug_list at the bottom? It was one of the first things written <OriansJ`>Then all I did write the tokenizer by piece; then I could add support for 1 C primitive at a time <OriansJ`>lines like :open_curly_brace "{" don't take much time to write <OriansJ`>The final important test was to build M2-Planet and it passed with flying colors <dgpv>mes-m2 simplified to be compilable by this compiler, or it is rewritten/refactored just for clarity ? <dddddd>I'm getting there, indeed. I simplified some bits since last time we talked, OriansJ`. I hope I can allocate more time to work on it soon. <OriansJ`>dgpv: first for clarity and then I am going to make it buildable via M2-Planet <OriansJ`>dddddd: take your time, we have plenty of time before the world demands another supported architecture <dgpv>so currently not buildable yet ? <OriansJ`>dgpv: it builds just fine with gcc (I've even eliminated all of the warnings as of this afternoon; just haven't pushed that patch yet) <OriansJ`>but there are a couple changes needed before I feel it is clear enough such that anyone wishing to audit the code could understand it in a single sitting. <OriansJ`>then getting it buildable will be an incremental process (potentially finding bugs in M2-Planet) without much in terms of code changes <OriansJ`>dgpv: I have not added support for it yet in M2-Planet nor has anyone taken the time to implement and send a pull request <OriansJ`>not that I have anything against switch statements; I just didn't feel like writing support for them in assembly and thus M2-Planet doesn't use any but it could easily be made to support them. <dgpv>trivial switch statements can be trivially rewritten, and non-trivial you probably want to refactor, anyway :-) <OriansJ`>dgpv: and it is much easier to do that work in a subset of C than to do it in assembly multiple times <OriansJ`>fortunately the delta between cc_x86.S and cc_amd64.S was quite small <dgpv>so this two files implement the same functionality, but with slight differences ? <OriansJ`>dgpv: one generates AMD64 binaries and the other x86 binaries as pointers are different sizes for the 2 architectures and different instruction encoding is required in multiple places <dgpv>ah, the target is different <OriansJ`>essentially I am eliminating every single possible issue that could possibly impact the trust of the bootstrap (include bios/firmware/Operating system/hardware/etc) <dgpv>it could be possible to break these files into parts and reuse the parts that are not target-dependent <dgpv>why not? simplicity of audit ? <dgpv>well, you would need translation from M1 to nasm of course <dgpv>probably too much to bother, but that is what I would probably do, I hate duplicated code :-) <OriansJ`>and there is no way to mix nasm with M1-macro <dgpv>M1-macro seems simple enough to parse and translate <OriansJ`>also I've left lots of small improvements in the code base for anyone who wants to hop on the project and contribute <dgpv>yep, I know, words are cheap ;-) <OriansJ`>one can even use an alternate M1-macro definition file to convert M1-macro into nasm should one desire <OriansJ`>as one could duplicate the steps in https://github.com/oriansj/mescc-tools-seed for any arbitrary hardware architecture of their choice; port M2-Planet and mescc-tools to that target and one can trivially final all hardware/bios/firmware attack vectors or code modifications. <dgpv>ok, its time to go to sleep <OriansJ`>and patches are up (mes-m2 now builds without warnings) <Hagfish>a clean mes-m2 build sounds fantastic <dgpv>ISA_HEX_Map.org lists `** Bit optimization group` commands that are of 4 bytes length <dgpv>but High_level_prototypes/asm.c is only able to encode long, 6-byte forms `setExpression(p, "ORI", "E100B1", 6);` <dgpv>Is it just an inconsistency in ISA_HEX_Map.org file, and ORI, ANDI etc should have been specified with `E1 00` prefix ? <dgpv>these short instructions are not implemented in vm, and long forms are not documented in ISA_HEX_Map.org <dgpv>what is inconsistent here, the doc or implementation ? <dgpv>probably the doc should list ORI/ANDI/... under 2OPI group ***ng0 is now known as Guest59160
***ng0_ is now known as ng0
***ChanServ sets mode: +o rekado_