<oriansj>pder: that is a known issue if M2-Planet isn't on commit 64a3a1b6740ea027ca04b866270431d57ae89cb6 or later ***Server sets mode: +cnt
<xentrac>oriansj: I did indeed start with a version that doesn't buffer the output, but then concluded that to add further functionality like composing bytes out of bitfields, much less backpatching forward jumps for conditionals, you need some kind of buffering. in your work you delegate the backpatching part to a separate linker which has most of the complexity of an assembler <xentrac>although I wonder if you can eliminate backpatching entirely if you just use conditional returns, hmm <xentrac>oriansj: I think your code erroneously interprets input byte decimal 252 as EOF <xentrac>well. I guess whether it's erroneous is in the eye of the beholder <xentrac>it's probably justified to assume that read(2) won't touch the buffer on EOF, but that isn't part of its documented interface ***xwvvvvwx- is now known as xwvvvvwx
***apetresc_ is now known as apetresc
<oriansj>xentrac: no need to do backpatching if you are simply a 2 pass assembler, simply read the addresses of the labels on the first pass and on the second pass dump the output as you go. makes for a simpler implementation. <oriansj>the -4 for EOF is because it maps to ctrl-d in legacy TTYs, which is a reasonable compromise if one assumes only ASCII inputs (utf-8 has no place in bootstrapping, prior to a proper C compiler) <oriansj>as for why my linker has most of the complexity of an assembler; it is because M0/M1 is designed to be built upon hex2 and not including that functionality allowed me to make M0/M1 smaller and simpler to understand and implement. (remember M0 had to be written in hex2). now you are correct if one wanted to write a real assembler in a higher language than hex2; there are many things they would want to include (syntax checking for 1). <CORDIC>""Second Pass"" requires a Buffer, IMHO. <ng0>is gash-devel@nongnu.org a mailinglist? nothing in the release announcement clarifies this <ng0>i have a couple of patches to send for fixing a build, or at least i need to write them and i don't like vendoring patches <ng0>then the announcement had the wrong address <janneke>ng0: i'm testing @nongnu.org right now <ng0>all i run into is git being called during the build and i need to make the date invocation more portable. I'll have more once I can get back to it, my bulkbuild is running now, could be a couple of days <ng0>git call is not fatal, but date is <xentrac>oriansj: shouldn't ^D be +4, not -4? <janneke>ng0: thanks for reporting, upstream loves you for that <ng0>i mean, i will report it myself :) I'm probably the only one besides guix who packages it right now <ng0>had gash in pkgsrc-wip in spring i think and for a while now in pkgsrc as shells/guile-gash ***deesix_ is now known as deesix
<pder1>oriansj: thanks, I figured out what was going on. If I had commit 64a3a1b674 checked out in M2-Planet the mescc-tool-seed build would fail for both x86 and AMD64. The reason is due to mescc-tools-seed containing an out of date amd64_defs.M1 and x86_defs.M1 that didn't have the new instruction added in M2-Planet. <pder1>Copying the defs file from M2-Planet into mescc-tools-seed/x86 or amd64 fixed the build and the mes-m2 tests pass. ***ng0_ is now known as ng0
<janneke>ng0: what distro/xxx are you packaging gash for? <ng0>everything pkgsrc targets *janneke shows their ignorance <ng0>a cross-system package distribution <ng0>exists since the 90s <ng0>i mean, i only test on NetBSD, but there are bulk builds which test on all (/almost all?) platforms and OS'. <janneke>is that the `pkg' command on e.g. freebsd? i'm trying to browse the user manual, but all commands seem prefixed with pkg_ so it seems to be something else? <ng0>no, they are not similar. but share a common root *ng0 tries to remember history ***awilfox_ is now known as awilfox