IRC channel logs
2019-11-30.log
back to list of logs
<xentrac>sadly David A. Wheeler's "SLOCCount" doesn't recognize Verilog as a programming language <xentrac>I think light8080 is closer to 1300 lines of Verilog but I also think its microcode is not included in that <oriansj>z80s had alot more microcode than 8080s <xentrac>you could probably build an 8080 clone with any arbitrary amount of microcode including zero <xentrac>light8080 is very microcode-heavy in order to fit into fewer LUTs, at the cost of speed <xentrac>and, more important for us I think, at the cost of intellectual complexity <xentrac>yeah, in RISC processors the machine code is the microcode <xentrac>so its transistors get charged to your RAM and not the CU :) <oriansj>xentrac: no, early risc processors had hard-wired instruction decode <xentrac>just like contemporary non-risc processors had hard-wired decoding of microcode <xentrac>this is not an observation original to me; the Symbolics guys made that remark about porting Genera to the Alpha <oriansj>well RISC II did support compressed instructions <oriansj>which did produce a 30% improvement in code density <xentrac>ARM Thumb-2 has amazing code density, better even than i386 <xentrac>but AARch64 has apparently abandoned the Thumb-* approach entirely <xentrac>I guess they figure that if you want to compress your instructions in RAM then your OS can page to Snappy-compressed RAM <theruran>stikonas: is anyone else working on reduced binary seed bootstrap of Gentoo? when I asked in #gentoo-prefix they didn't understand the problem or need <oriansj>ARM Thumb-2 also has insanely complex encoding/decode rules that eat transistors like crazy <xentrac>yet implementations of it still take way less silicon area than amd64 frontends ;) <oriansj>xentrac: well we can't know that for certain because no one has implemented AMD64 without OoO and that is a bigger eater of transistors than anything <xentrac>and I guess the ARM CPUs that are graduating into the OoO age are AArch64 <xentrac>an interesting thing is that the GPU cores that contribute most of the computrons in modern PCs aren't OoO either <oriansj>nope VLIW like most OoO cores these days <xentrac>well, semi-VLIW, especially the intel ones <xentrac>if RISC was "why don't you just compile your program to vertical microcode" then VLIW is "why don't you just compile your program to horizontal microcode" <xentrac>an approach which has produced some EPIC fails <oriansj>xentrac: and some amazing results (R700 series) <oriansj>it is almost like no single design ideal is universally a good idea <xentrac>i'm starting to think you're right about that :) <xentrac>i still haven't written anything in the assembly code of any GPU, i've barely written GLSL <oriansj>xentrac: you really don't want to try to write VLIW in assembly, you'll do it wrong (in fact everyone does) <oriansj>you need to track the latency of all bundles and their sub-instructions <xentrac>that sounds like the kind of thing a better assembler would be good at <xentrac>to figure out which bundle to schedule each sub-instruction into <oriansj>xentrac: in the end most compute in every VLIW is wasted <xentrac>unfortunately I only have Intel and NVIDIA GPUs handy here <oriansj>it costs an insane amount of development time and money to extract major chunks of that performance <xentrac>yeah, but you and I both know that things that sound infeasibly difficult to most people sometimes aren't ;) <oriansj>xentrac: true, but billions of dollars and decades of funded research were needed to get VLIW Optimizers competitive for non-embaressingly parallel work loads <xentrac>right, but now we have the results of that research to build off of <xentrac>plus lots of other advancements in search and optimization <xentrac>and maybe the expectations for the input of those optimizers were unrealistically demanding <oriansj>xentrac: well Intel needed to make a VLIW outperform an OoO and we now know that is entirely impossible for single threaded applications <xentrac>yeah. but for applications written in some future cleaned-up version of J or K or GLSL, maybe... <oriansj>xentrac: skip future; K applications fly on GPUs today <xentrac>okay but I really don't want to program in K :D <xentrac>GLSL is a little more bearable in some ways but it's way too limited, unless that's just the limitations of my knowledge <xentrac>I mean I'd much rather program in assembly than in K <oriansj>fair, but you can't beat it on wallstreet <xentrac>I've heard people say that, but all the HFT quants I've talked to were using C++ and Java and Python, not K <xentrac>it's been a few years since I wrote any trading code though so maybe K has gotten more popular <xentrac>one guy was working at Morgan Stanley and mentioned that they had not only some K code but even some A+ <oriansj>and patches are up for mes-m2 (slow_lisp branch) <oriansj>now just to figure out record-constructor to finish off support for records <oriansj>could probably do it entirely in scheme since all the other record primitives are implemented <oriansj>hint: (core:make-record a #(#f #f #f #f)) <oriansj>^a^(make-record-type "foo" '(a b c d)))^ <oriansj>xentrac: well k and A+ are generally considered write only languages for most programmers <oriansj>or more commonly anything is just a one-liner in k if you hate yourself enough <stikonas>theruran: no, I don't think anybody is working... <stikonas>theruran: in fact java people were not really helpful here, although they pointed out that path that I used earlier had blobs <stikonas>(I tried to use gcj, but that used precompiled ecj)\ <xentrac>yeah, the write-only aspect is what I most want to avoid <theruran>stikonas: I see, and #gentoo-toolchain confirms. Could bootstrap Gentoo from a bootstrapped Guix system and toolchain though. <theruran>though not having fun with this dependency hell that portage is having rn <stikonas>at the moment I am able to bootstrap jamvm/classpath-devel/ecj, which should be enough to compile icedtea:6 (need some patches though, this is now WIP) <stikonas>at the moment, when icedtae:6 ebuild fails, build tree is about 2GB, so I guess I'm getting close <stikonas>after icedtea:6 compiles, it should be very easy to just build icedtea:7 <stikonas>maybe it would be possible to also make some overlay for rust... <stikonas>theruran: feel free to test my java bootstrap stuff :D <oriansj>stikonas: entirely possible, just depends on the time you are willing to burn on it <theruran>stikonas: ah well, I think I have a hardened-musl Gentoo VM available :) <stikonas>theruran: do you have openjdk already installed there? <stikonas>musl might be especially interesting, I only tried on libc <theruran>only just now getting around to installing a Guix SD VM <stikonas>theruran: well, no java is easier, otherwise you probably need to uninstall it to be sure that it doesn't accidentally build what is supposed to be bootstrapped <oriansj>and core:record-constructor is implemented and record-constructor is implemented via a trivial define in test/test019/core.scm <oriansj>and test019 passes; mes-m2 slow_lisp now supports all the record primitives requried by guile <oriansj>((record-constructor a '(d b c a)) 1 2 3 4) does the right thing, as does ((record-constructor a '(d b a)) 1 2 3 4) and ((record-constructor a '(d c a)) 1 2 3) <theruran>oriansj: eh what happens when MAX_STRING is much larger so mes-m2 doesn't segfault on larger programs? <theruran>should it produce an error when too large of a program is inputted? <oriansj>theruran: well I can easily make MAX_STRING 10MB, but it is just the max size for a single S-expression <oriansj>and since the slow_lisp branch is just a grand total of 83,694 characters (including white space), I find it hard to justify a single S-expression bigger than 1/8 the size of the lisp interpreter running it <oriansj>as for running out of cells when evaluating, one can set MES_ARENA to any value they desire, the default is 1,000,000 cells (consuming 32MB of memory) <theruran>oriansj: got it. well, last night I did manage to statically compile Jitawa LISP with CompCert and musl. What I was trying to do before was host the Milawa proof assistant on top of mes-m2, but it seems that the (define) semantics are different (Milawa used to run on Common Lisp) <theruran>not that that makes much of a difference. I just had my doubts about wrapper.c :) <oriansj>well mes-m2 supports (define a (thing)) and (define (a b c) (thing)) <theruran>Milawa is written like (define 'lookup-safe '(a x) '(+ a x)) <theruran>wrapper.c is used to provide an entry-point to Jitawa's verified x86_64 assembly *shrugs* <theruran>it also allocates all the memory necessary to run the JIT compiler <oriansj>so, 19 assembly instructions? (setup stack, brk and jump to entry point) <theruran>oriansj: that's what I was thinking :D and it also does some basic I/O <theruran>the assembly would be easier to get correct than the C, and smaller TCB <oriansj>theruran: On Posix systems there is no way to do I/O directly; one requires syscalls for read and write, which involves a rather large TCB