IRC channel logs

2020-03-04.log

back to list of logs

<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?
<OriansJ>PowerPC
<OriansJ> https://www.crowdsupply.com/libre-risc-v/m-class/updates/openpower-eula-released-fosdem-and-more
<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)
<dddddd>RISC-V is harder to buy AFAIK
<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.
<OriansJ>fossy: sounds good
<fossy>dddddd, deesix: are you the same people?
<dddddd>yep
<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>extensions.
<OriansJ> http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-October/003035.html
<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
<OriansJ>and 5GB of Swap
<OriansJ>(300GB of Swap if one wanted)
<OriansJ>(using an SSD)
<xentrac>2GB sounds like a lot
<fossy>^^
<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>interesting.
<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)
<fossy>nice.
<OriansJ>Heck one can buy a Power Mac G5 with 16GB of RAM
<fossy>once /can/
<fossy>but it is expensive
<fossy>hm
<fossy>maybe not so much anymore?
<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>especially PowerPC
<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
<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>fossy: ego usually
<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 :)
<dddddd>fossy, are you on windows?
<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
<OriansJ> https://en.wikipedia.org/wiki/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>yeah :)
<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
<xentrac>but not vice versa
<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.
<xentrac>that's wonderful
<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>windows sucks
<fossy>dddddd, OriansJ: oops my bad
<fossy>It is not used day to day
<fossy>it is just sitting there
<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>I've got a good sense of how I'll write string recognition
<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>or enough to write (echo) a 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