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
<oriansj>what is interesting: https://en.wikipedia.org/wiki/Transistor_count is that an 8051 uses more transistors than a ARMv1
<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 :)
<xentrac>the CPU :)
<oriansj>xentrac: no, early risc processors had hard-wired instruction decode
<xentrac>that's exactly what i mean
<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>hmm, that's an excellent opint
<xentrac>point
<xentrac>and I guess the ARM CPUs that are graduating into the OoO age are AArch64
<oriansj>yep
<xentrac>an interesting thing is that the GPU cores that contribute most of the computrons in modern PCs aren't OoO either
<xentrac>they're more like the Tera MTA
<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
<xentrac>have you tried it?
<oriansj>xentrac: you really don't want to try to write VLIW in assembly, you'll do it wrong (in fact everyone does)
<xentrac>maybe a better assembler would help
<oriansj>nope
<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
<oriansj> https://paste.debian.net/1118588/
<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+
<xentrac>but he was writing C++
<oriansj>and patches are up for mes-m2 (slow_lisp branch)
<xentrac>hooray!
<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
<xentrac>+1 :)
<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.
<stikonas>theruran: in principle yes
<stikonas>but that's work TBD
<stikonas>theruran: do you use gentoo?
<theruran>stikonas: right. :D and yes, I do
<stikonas>well, this is my current java work:https://git.stikonas.eu/andrius/openjdk-overlay
<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)
<theruran>stikonas: keep up the good work!
<xentrac>awesome!
<xentrac>that's fantastic
<stikonas>at the moment, when icedtae:6 ebuild fails, build tree is about 2GB, so I guess I'm getting close
<oriansj>stikonas: good
<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>stikonas: no, I don't think so
<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)
<oriansj>up next is modules, right janneke?
<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))
<oriansj>wrapper.c?
<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