***ChanServ sets mode: +o rekado
<vagrantc>janneke: i was able to drop all the patches and it fixed a few other lintian issues :) <vagrantc>should see if the amd64/i386 buildd's successfully build it in ~30 minutes <janneke>ah yes, a successful package build would be nice <vagrantc>i've done some local build tests, so *should* be fine <vagrantc>swear it passed on my last local build... <vagrantc>guess one of the readdir XFAIL patches was still needed? <vagrantc>so, on the machine i had where it consistently failed... it was an overlay fs consisting of a tmpfs upper dir and ext4 lower dir ... and the one that i just tested as working was overlay fs with ext4 upper and ext4 lower... <janneke>vagrantc: in a way, it could be a feature that it fails <janneke>it really bothered me that all tests passed on my qemu-vm and you needed XFAILs <vagrantc>i think we're honing in on the underlying issue ... <janneke>it's why we do all this marrakech stuff, right? <vagrantc>you don't want your test suite to be filesystem dependent :) <vagrantc>or at least, it knows how to handle itself <janneke>ah yeah, quite possibly this is just a silly goof-up by me :) <vagrantc>what confuses me is why it would be consistently fine on i386 and not amd64... but maybe 64-bit tmpfs behaves differently somehow <vagrantc>it's not expecting any particular order, is it? <oriansj>First in, first out (read/write respectively) <oriansj>So unless the filesystem doesn't support reading and writing one byte at a time, it shouldn't be an issue <oriansj>(and that would be an extremely broken filesystem) <vagrantc>so far it seems tmpfs and/or overlay fs consisting of tmpfs + ext4 seems to trigger the issue on amd64 but not i386 <vagrantc>simple enough to test on multiple filesystems with different properties... <oriansj>fosslinux: thank you for the patch for the mes-m2 slow_lisp build; I just saw it and I am merging it now <oriansj>god, I hate x86 assembly in regards to division ***ng0_ is now known as ng0
<oriansj>tell me if this seems insane: (all unspecifed registers = zero) RAX=-13, RDX=-1 and RCX=4; div rcx => works fine RAX=-13, RDX=-1 RBX=4; div rbx => SIGFPE, Arithmetic exception <janneke>i don't see how div rbx would do something different from div rcx... ugh <oriansj>all just to get M2-Planet's behavior to match gcc's for building mes-m2 *janneke goes afk for a bit <`Lion>oriansj: i get sigfpe in both cases <`Lion>48c7c0f3ffffffbb0400000033d248ffca48f7f3cc <`Lion>48c7c0f3ffffffb90400000033d248ffca48f7f1cc <oriansj>`Lion: then I might have stumbled into ERRATA again <oriansj>so new M2-Planet patch is up (it is a little ugly) <oriansj>and a new commit for mes-m2; which has the slow_lisp branch now passing all (currently active) tests <oriansj>now make clean bin && kaem --verbose --strict && make test does exactly what one hopes for (thank you fosslinux for getting kaem.run into fighting shape again) <oriansj>now back to the primary task (adding records) <oriansj>well atleast make-record-type, record-type-name, record-type-fields, record-type?, record? and record-type-descriptor are trivial to implement <oriansj>I also added a (make-record %record-type #(%values)) which seemed obvious to do <oriansj>and the patch is up for those curious <oriansj>now to just figureout the optimal way to do record-constructor, record-predicate, record-accessor and record-modifier <fosslinux><oriansj> fosslinux: thank you for the patch for the mes-m2 slow_lisp build; I just saw it and I am merging it now <Hagfish>hmm, would it make sense to have something like a bug/feature/work tracker for all these components? <Hagfish>having a unified dashboard showing all the current work, and what's blocked, (and maybe their dependencies), would be a nice way to visualise all the progress that's happening <oriansj>as the list of primitives required to support MesCC, guile's bootstrap and Guix are ultimately finite <oriansj>janneke: I am thinking of just doing (core:record-predicate record-type record) and the (define (record-predicate type) (lambda (record) (core:record-predicate type record))) <oriansj>similiar things can be done for record-accessor and record-modifier <oriansj>but that is just me not wanting to handwrite a S-expression sequence in C <xentrac>I've been talking to David Given about porting CP/Mish, or the parts of it that are in C, to BDS C. he thinks it would be impractically difficult, but I think it's probably more feasible than he imagines <oriansj>xentrac: speaking as one of the few people on this planet who has also written a C compiler in assembly. oh god why? <xentrac>because right now you need Linux and the Amsterdam Compiler Kit to compile CP/Mish <theruran>I was just reading again the 50% binary reduction announcement on Guix's blog, and reading the TCC mailing list responses. I think having a well-defined subset as they suggest is important. Ideally, each feature supported is defensible from the bootstrapping POV. I was wondering if Cminor or Clight from the CompCert project are feasible, though they don't support `goto' which I think is needed for MesCC, right? <xentrac>and bootstrapping an 8080 seems like it might have some practical advantages over bootstrapping Knight, such as existing software that can run on it <xentrac>and existing test suites and compilers <xentrac>64K is a problematically small address space though <oriansj>well collapseOS is always an option xentrac <oriansj>theruran: yep, was thinking of porting cc_* to it later <oriansj>theruran: M2-Planet as it is trivial to port <oriansj>theruran: I was thinking of porting cc_* to collapseOS <theruran>I thought that Dawn OS on the SUBLEQ computer is really neat. Can M2-Planet transpile to a single instruction set? <xentrac>something like Wirth's RISC is maybe a better option if you're trying to minimize the intellectual complexity of the CPU and software rather than its transistor count <xentrac>although admittedly SUBLEQ has lower intellectual complexity than Wirth's RISC :D <theruran>and then there is C-- which is just a platform-independent assembly-like intermediate language. I don't think anyone uses this though <oriansj>theruran: probably but it'll involve some insanely ugly M1 macros <xentrac>compiling anything to SUBLEQ is insanely ugly, but the ugliness is well contained <xentrac>by contrast, compiling anything to a 16-bit address space produces difficulties that pervade the entire system <xentrac>Wirth's RISC is kind of the opposite extreme from Turing tarpits <xentrac>it has 16 instructions. the 8080 instruction set is around 30 instructions depending on how you count, and existing implementations are only a few hundred lines of code <xentrac>amusing to have more lines of code in your CPU HDL design than you have LUTs <xentrac>Chuck Thacker's design for a CPU similar to Chifir was only about 60 lines of Verilog though, and I think Knight is maybe a bit more than that <oriansj>well I certainly would not argue that knight is a complex design relative to some alternatives <xentrac>where would you put it on the scale? <oriansj>depends if you mean the full instruction set per the spec or just the subset required actually to do the bootstrap? <oriansj>yes, if we stick to just the minimal bootstrap subset it is simpler than the 8086, but if we include everything it is less complex than the 286 <xentrac>oh, so way more complex than subleq, chifir, thacker's thing, wirth-risc, 8080, pdp-8, or even z80, no? <oriansj>I'd argue that the z80 is more complex than the 8086 <xentrac>(from my point of view 8086 seems about two or three times as complicated as the z80) <oriansj>the register grouping complexity and support for 32bit operations <xentrac>but those are 8086 instructions, not the z80 <xentrac>so it sounds like you're counting them on the wrong side of the complexity ledger <oriansj>the Exchange, block transfer, and search instructions on the other hand... <xentrac>or is there a Z80 version of those that i just don't know about ? <xentrac>I don't know the Z-80 instruction set that well! <xentrac>I can't download either of those without creating an opencores account <oriansj>I'd argue based on verilog implementations alone, that the 8086 is simpler than the z80 <xentrac>nextz80cpu is about 22 pages of poorly abstracted verilog with a lot of evident duplication *stikonas is getting quite close to bootstrapping OpenJDK on Gentoo (although it will only be an overlay, not mainline portage tree) <xentrac>I haven't used Gentoo so I don't know what an overlay is <oriansj>xentrac: a good few more pages (but most of them appear to be single instructions) <stikonas>xentrac: I actually found guix bootstrapping bug while doing this, it's not fixed in staging <xentrac>oriansj: so in what sense are you arguing that the 8086 is simpler than the z80? i'm sure it must be true in some sense but i'd like to understand what that sense is :) <xentrac>rtf8088 seems like it might be written at a somewhat more RTL-ish and less behavioral level than nextz80, which might be one reason it's more complex <oriansj>xentrac: in the sense that one appears simpler to implement in verilog <xentrac>but... in this case it looks like nextz80 was a lot easier to write than rtf8088, doesn't it? <oriansj>xentrac: there are certainly alot of z80 clones but very few 8086 clones <xentrac>cloc says rtf8088 is 4638 lines of Verilog and nextz80 is 1797 