<OriansJ>fossy: I never added variable support to kaem, that is entirely your achievement; one that I might have never done <OriansJ>dddddd: we may need to lower RISC-V's priority in regards to architecture bootstrapping <dddddd>What are you thinking to replace it with? <dddddd>I'll have to dig into the details, meanwhile... why do you think this might be more important? <dddddd>Does the ISA under that EULA have implementations on the wild? (that'd be a good reason) <xentrac>PowerPC as of 2000 is necessarily patent-free (although any particular implementation of it may not be) <fossy>OriansJ: I do eventually plan to add multiple variables in one token to kaem <fossy>but, that is a bit away, I don't see that as extremely important for the time being <dddddd>I'll add Power to my RISC-V readings and keep completing M1.scm of slow-utils. <OriansJ>dddddd: more existing hardware available to use to do development on and a better known set of parties involved. <fossy>dddddd, deesix: are you the same people? <OriansJ>xentrac: indeed and thousands of existing machines powerful enough to do the bootstrapping work on for cheap. vs $1K+ for RISC-V <OriansJ>dddddd: I look forward to seeing your slow-utils work <OriansJ>not to mention the phrase "We cannot even get access to documentation explaining how to propose new" <OriansJ>markjenkinsznc: when you feel the disassembler.py is ready, could you please tweak User_Interface.py to use it instead of dis and make a pull request for stage0. Then I'll be able to pull the extra null padding out of M1 and the rest of stage0 <xentrac>presumably if WD starts selling RISC-V drives, you'll be able to get a RISC-V microcontroller as part of a US$40 disk drive (I guess SSDs have eaten the low end of the disk drive market?) <OriansJ>xentrac: well a single PCB and 6 chips are cheaper than a single electric motor <OriansJ>the problem with the RISC-V microcontrollers is that the amount of RAM they can access is extremely (one would dare say artificially) limited <OriansJ>There is just no way to run MesCC in less than 2GB of RAM <OriansJ>M2-Planet I might be able to get below 256KB with enough work but it just isn't possible to have a C compiler in Scheme using Nyacc fit on a microcontroller <OriansJ>Atleast with PowerPC one can get a PowerBook G4 with 512MB of RAM <fossy>OriansJ: does MesCC really need 2GB of RAM? How about 1/2 a GB of RAM + like 6 GB of swap? <OriansJ>xentrac: 2GB is after alot of memory improments in mes.c <OriansJ>well the original mes.c nope; believe me I tried <fossy>I might have a bit of a play with that *fossy has a 17 year old beast of a laptop, was dad's, that has 1/2 a GB of RAM <OriansJ>hence why mes-m2 is a different design to allow a 64MB system with 4GB of swap to work (if slowly) <OriansJ>Heck one can buy a Power Mac G5 with 16GB of RAM <OriansJ>but RISC-V microcontrollers only have 16KB of RAM to work with <fossy>i agree, maybe powerpc > RISCV for the time being <fossy>I think ARM and PowerPC are the most reasonable targets <fossy>also, worse for open hardware but more ubiquitous, are pre Intel ME computers <fossy>ew, some parts of autohotkey are not bootstrappable <fossy>why do people insist on writing interpreters/compilers in the language even if they are bad languages to write a interpreter/compiler in <OriansJ>or a religious belief that their language of choice is perfect even when all possible evidence points differently <xentrac>well, the jargon file explains that if a language isn't even used to write its own compiler, then it doesn't even rise to the level of being a toy language <xentrac>so probably some people believe that <xentrac>I am surprised to learn that arts of autohotkey are written in autohotkey though! (?) <dddddd>What makes a lang "bad" for that particular tasks? <OriansJ>I'd argue that any language that can't build something much larger than itself is not a real language <xentrac>dddddd: compilers are mostly tree pattern matching, so they benefit a lot from garbage collection, pattern matching, and good support for trees and functional programming in general <xentrac>although probably OriansJ disagrees with me on this :) <OriansJ>xentrac: I disagree on the garbage collection but I agree on the rest <xentrac>Aaron Hsu recently published his dissertation on writing Co-dfns, a data-parallel compiler written in APL for compiling APL to efficient GPU code <xentrac>apparently a couple of operators were added to Dyalog APL in order to support this as he was writing it <OriansJ>well as it was his dad's laptop with only 512MB of RAM, I am guessing limited choices are involved. <OriansJ>xentrac: I've have come to understand APL as the sort of language group as R; not designed for general use in programming <OriansJ>dddddd: in theory fossy could be running on ReactOS <dddddd>I'm running debian with 512M most of the time. Anyway, didn't realized that old laptop was much involved in day-to-day tasks (I thought it was just a data point about available hard). <xentrac>OriansJ: that is the most popular point of view, but I don't think it's really correct <OriansJ>Which for people who depend upon Win32 binaries applications is entirely reasonable as a first step towards freedom <xentrac>but definitely APL is the kind of language that you would think is especially poorly suited to writing a compiler in <OriansJ>xentrac: I learned that quickly when I started talking to the APL community about what sort of compilers and interpreters they had <OriansJ>I was pondering bootstrapping APL from M2-Planet to bootstrap C; they shot that down hard and fast <OriansJ>since I had already done the build a FORTH and write a Lisp route in assembly <OriansJ>I mean honestly, how many people can say they wrote a Lisp that works in only 24KB of RAM? <OriansJ>although personally anything less than 2MB makes for some very very short scheme commands <xentrac>I think AutoLISP ran in 64K originally and XLISP was comparable <OriansJ>now I have resolved to never write another interpreter in assembler for the rest of my life. (kaem.S barely skirted that definition) <OriansJ>Even when you have perfectly working C code to reference, it is hard getting every little detail exactly right. <OriansJ>Compilers in assembly, stupidly easy to get working and mostly right <xentrac>well, you can use a compiler everywhere you'd use an interpreter, except on the iPhone <OriansJ>good thing iOS doesn't matter in regards to bootstrapping <xentrac>you might write something for iOS in the rest of your life <OriansJ>xentrac: I work for the State of Michigan as a Computer Security and Reliability Engineer. <OriansJ>I would bet money to the contrary and only choose to lose that bet if the offer to do that work included an obscene enough of a reason for me to do so. <OriansJ>I figure a Billion USD is enough for me to buy forgiveness for that magnitude of sin. <xentrac>I know, but you might not be working there for the rest of your life <OriansJ>xentrac: of course, I plan on eventually retiring before I die (probably from listing to some POS suit drone on and on about mission statements) <OriansJ>I refuse to take programming jobs where I can't refuse to do certain things. <OriansJ>as a moral choice, it is better to do nothing than do that -RMS <OriansJ>Hence why a Billion USD should be enough for me to fund other people to counter any harm I might do by such a job. <OriansJ>Less evils can be bought at cheaper prices. <OriansJ>xentrac: I just think of it as weighted morality; no good exists without evil. <fossy>dddddd: I am most def not on windows <fossy>dddddd, OriansJ: oops my bad <fossy>I am interested to use it as a datapoints for limited hardware testing <markjenkinsznc>OriansJ, I'll integrate my disassembler to User_Interface.py as asked once I reach feature parity with disasm.c <markjenkinsznc>My earlier celebration of minimal viable product was premature, once I added a full test suite there were some binaries which mis-assembled <markjenkinsznc>I had the bugs fixed and a working build after that, but since then many slow commits of refactoring as I worked to clean up the code smell that lead me to that set of bugs in the first place <markjenkinsznc>17 commits since I passed my test suite, each tested against my test suite as I made things better and more ready for upcoming features <markjenkinsznc>almost done that process, the fun part on string recognition is that I intend to allow the user to choose if they want strings in output under the expectation of re-assembled by old four byte padding assembler or new model, we'll flip the default at the right time <markjenkinsznc>as for discussion of powerisa/powerpc, I'm really excited by computers that include firmware that makes them self-programable (and thus self-bootstrappable) and the norm with 64 bit power for awhile now has been to use Linux and a small userspace (not sure if GNU) as part of the firmware stack (pettiboot) <markjenkinsznc>these pettiboot environs don't include a compiler, but I'm pretty sure they include either hexdump or echo with hex escapes <markjenkinsznc>so that should be enough to either audit (hexdump) an imported hex0 binary <markjenkinsznc>will be very happy the day i get to do that on my raptor compute systems blackbird (power9) which has an option to go into shell in pettiboot <markjenkinsznc>some day I want to include m2-planet, mescc-tools and/or mes/mes-m2 in my pettiboot firmware (fairly small binaries) and encourage raptor compute sys to do the same in devices they ship <fossy>OriansJ: I am unsure why you would like equal_found = TRUE by default in is_envar? <fossy>oh wait, I think you mean for the is_envar = 1. ***ChanServ sets mode: +o rekado
<OriansJ>markjenkinsznc: Well the new string format should be the default but yes that is one of the pieces about PowerPC that should get more people excited about M2-Planet/mescc-tools working on them. <OriansJ>fossy: well we did create the CONSTANTs TRUE, FALSE and EOF for a reason. <OriansJ>so we don't have to stop and go was TRUE 0 or 1 but rather know the DEFINE will always do the right thing (even if we change the meaning of TRUE and FALSE) <fossy>OriansJ: yes, I misinterpreted you. I thought you meant that you wanted it to be equal_found = TRUE by default