IRC channel logs

2020-02-16.log

back to list of logs

<OriansJ>back
<OriansJ>bauen1: well having the root filesystem as a tar file is an interesting idea
<OriansJ>I am guessing that is how you are solving the creating a filesystem without having a filesystem problem
<OriansJ>bauen1: we also have the issue of the licensing; it needs to be under an FSF approved license to be used.
<dddddd>M1.scm now handles the other KNIGHT special case, to ensure that "hexified" strings don't break the 32 bits alignment.
<OriansJ>dddddd: very nice
<dddddd>I'm wondering if a poorly placed string can break AArch64. I need to recheck if instructions are required to be "evenly" spaced.
<dddddd>s/spaced/placed/
<OriansJ>well ARMv7l I know has some serious alignment requirements that are quite annoying
<OriansJ>(words must be word aligned, half words must be half word aligned and double words need to be double aligned)
<OriansJ>It is an annoyingly common bad design requirement of old RISC processors; so that they could save transistors to add parity bits to the L1 cache
<OriansJ>if AArch64 has similiar restrictions, they literally must have been drinking bleach to think that was a good idea.
<dddddd>"A misaligned PC is defined to be one where bits [1:0] of the PC are not 00."
<OriansJ>well, shit
<dddddd>The checks can be disabled it seems but I guess it's uncommon to do so.
<OriansJ>Billions of transistors to work with and they still do the absolute wrong thing again
<OriansJ>What kind of Mickey Mouse grade bullshit Computer Science degrees do their "experts" have?
<fossy>OriansJ: why does it have to be under a FSF license? Sure if we are distributing with gnu stuffs but otherwise why?
<OriansJ>fossy: FSF approved licenses include ISC, MIT, BSDs, Apache, etc
<fossy>OriansJ: yeah I know
<fossy>but why would the kernel have to be under a fsf approved license?
<OriansJ>The reason being: I refuse to contribute to non-free (as in freedom) software
<dddddd>Well, 'this' and "that" are scape valves in M1. Asking a bit of care to whom uses them is not crazy, I guess.
<OriansJ>fossy: it is the foundational rule. Without the four freedoms; the best software in the world that does everything isn't worth shit.
<fossy>Oh of course
<fossy>hence my name "foss"y
<OriansJ>I'd rather start from scratch than non-fsf license
<OriansJ>I can make the time if I must
<dddddd>In some cases, I'd say that if copyleft also not involved, with some exceptions maybe.
<OriansJ>There will be no negotiation when it comes to the four essential software freedoms in our bootstrapping work.
<OriansJ>I will not have it.
<OriansJ>I can accept permissive push over licenses
<fossy>I dont recall which, but there was a license that the fsf didnt like but imo 4 essential freedoms were held up and other places also agreed... cant remember which though. But yes fsf approved licenses are always the best way to go
<fossy>For certain, anything bootstrappable officially endorses must hold up the four core freedoms
<fossy>our whole model revolves around it
<fossy>Dont get me wrong the four freedoms are important
<fossy>But I mean things like OSI vs FSF approved
<Hagfish>i think one controversial example of the FSF rejecting a license was the old BSD license which required software to print a disclaimer. their argument was that eventually the disclaimer printing code could become bigger than the code that provides the functionality, if you combined lots of libraries, say
<fossy>^^^ that was the one I was thinking of
<OriansJ>Hagfish: thank you for looking that up for us
<fossy>another one, the WTFPL is fsf approved but not OSI approved
<Hagfish>that's just from memory, so it might not be fully accurate :)
<Hagfish>one license that Debian and the FSF disagree on is the GFDL, as the GFDL allows invariant sections, which the FSF say is necessary to stop people changing words in a political manifesto
<OriansJ>Why don't we stick to the core that we know avoid issues
<fossy>yes, we should
<Hagfish>yeah, in practice, the controversial licenses are so rare that no one would choose to use them for a significant new project
<fossy>^
<fossy>excluding the wtfpl
<fossy>That is somewhat common
<OriansJ>It reduces debate; if someone is a permissive hardliner: ISC (as OpenBSD clearly has pointed out is the optimal choice for that) and for Copyleft hardliner: GPLv3 (possibly with the Affero option)
<OriansJ>Everything I do is GPLv3+
<fossy>Same
<fossy>small things like my dotfiles are MIT
<fossy>Oh, reminds me
<OriansJ>ISC is better if you want minimal license restrictions
<fossy>with the GPL when forking a project, wrt copyright headers, do you have to leave the name intact?
<fossy>eg mescc tools seed has Mes in its headers but its gcc seed now
<fossy>so can I change Mes to gcc-seed, while leaving oriansj and janneke's lines intact?
<OriansJ>fossy: I also thought you planned on merging your gcc seed branch back into mescc-tools-seed
<dddddd>The quick answer is yes, you can not remove the copyright of the other authors.
<Hagfish>(authors can always agree to relicense their works under a different license though)
<fossy>OriansJ: Im reconsidering that. If you would still like it that would be fine, but its beginning to significantly differ from mescc tools seed
<OriansJ>fossy: I saw the restructuring you did
<fossy>Especially in terms of structure
<fossy>yes
<OriansJ>That is largely fine
<fossy>if you are willing to include that in mescc tools seed I do not have a problem with that
<OriansJ>fossy: I am willing to include the structure change
<fossy>That was more of an example rather than a commitment to make it a fork
<fossy>I would love to have it upstreamed
<fossy>But of course, we need to wait for mes m2
<OriansJ>fossy: not entirely
<fossy>ATM I am working on the use of gash and gash core utils
<fossy>Rather than sh
<fossy>And coreutils
<fossy>OriansJ: how not, since there should be no guile binary seed?
<OriansJ>we flag it in a big and obvious way
<fossy>Hm
<OriansJ>We put a great big warning and prompt the user for input (say hit enter)
<OriansJ>Then we use the system guile for the steps that mes-m2 should be doing
<OriansJ>leverage kaem's ability to lookup guile from the path; throw an error if it isn't found
<fossy>Another idea would be the use of a flag, eg -g that runs the rest of the bootstrap -g denoting use of guile
<OriansJ>too subtle if you ask me
<fossy>Well, along with the message
<fossy>Or, adding a flag for the opposite, run the bootstrap with guile seed by default, and -n for only going up to mes m2
<OriansJ>or if you feel more comfortable about waiting until mes-m2 is done for the merge, we can break it into 2 pieces
<OriansJ>We merge the structure changes but put the work currently being done in guile on a separate branch
<fossy>That is another alternative
<fossy>I like that
<fossy>The thing I feel the most uncomfortable about it having the guile seed in savannah
<OriansJ>fossy: not an issue
<fossy>as you've said experimental changes are much more workable in github
<OriansJ>mescc-tools-seed isn't even on savannah yet
<fossy>Ill make another branch and cherry pick the structure changes
<OriansJ>and when I get mescc-tools-seed into savannah; I will only upload the master branch and not push any of the development branches
<fossy>the release branch?
<OriansJ>release/master branch if it makes it easier
<fossy>ah right
<OriansJ>You of course can name your WIP branch anything you like (save master, release, production, etc)
<OriansJ>and when dddddd is done with slow-utils; your guile steps will not even depend upon any earlier stages (save for mes-m2)
<fossy>Oh nice
<OriansJ>hence scheme only bootstrap for guix
<fossy>i see
<OriansJ>The idea behind the guix work is if you have guile, the rest can be bootstrapped. Hence the requirement of making mes-m2 a drop in replacement good enough to solve guile's psyntax bootstrap problem.
<fossy>ewewew why did I write variable_substitute that way
*fossy refractor
<fossy>thats so messy
<fossy>(Kaem)
<OriansJ>fossy: sometimes one needs time away from code we write to see the problems in it
<fossy>lol yes
<fossy>i agree 100%
<theruran>well, I managed to write a Guile script that imports gash and does (echo "hello, world") ✅
<bauen1>OriansJ: the root as a tar idea is mostly stolen from how the linux initrd concept
<bauen1>it allows me to test the virtual filesystem layer quickly
<bauen1>without having everything burn in multiple places at the same time (ext2 driver, ata driver, vfs layer)
<bauen1>regarding the license i'll probably use something like gpl 3.0 but i haven't spend time to have a close look at the various possible licenses
<theruran>janneke: I've also imported your gash-core-utils into my Hello, World script so now I can try out those commands
<theruran>ei, so what do I do with these config.scm.in files?
<janneke>theruran: ah, are you using gash for programmatic guile shell scripting?
<janneke>that's one area that hasn't had any love the past year, but is very interesting!
<theruran>janneke: yeah, want to!
<janneke>theruran: great!
<theruran>instead of porting scsh, huh
<theruran>looks like you have already implemented most of what I need
<janneke>what i'm saying is: therey may be rough edges, becaes we took a sharp turn into bootstrapping last year
<janneke>theruran: that's great, yes the basic stuff should be there
<theruran>alright! I will be poking at it slowly
<janneke>gash core utils now lives as `gash utils' here: https://git.savannah.nongnu.org/git/gash/gash-utils.git/
<theruran>ahh thank you!
<janneke>changes are probably minimal, but still
<theruran>how do I build config.scm.in into config.scm?
<janneke>theruran: we usually do that by running ./bootstrap; ./configure
<theruran>janneke: oh yeah, but when I run that on gash-utils it complains that gash is not installed. I guess I should use ./configure --prefix=/usr on gash, huh?
<janneke>possibly, did you install gash?
<janneke>i never install except as guix packages
<theruran>janneke: yes, using sudo make install. and it put in /usr/local
<janneke>for development, you can always `./pre-inst-env bash' in the gash directory
<janneke>ah
<janneke>that's supposed to work...of course you are one of the first users
<janneke>so you may find a problem here and there
<janneke>the install check is real straightforward, guile should be able to find the modules in the load-compiled-path, i think
<theruran>yeah, I guess guile doesn't know to look in /usr/local since it is installed in /usr
<janneke>hmm, that could be, but it isn't that what the "site" directories are for?
<janneke>anyway, you can always add /usr/local/... to GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH
<janneke>theruran: what os are you running?
<theruran>janneke: Gentoo. lemme try those environment variables
<theruran>yes, that did it. passed configure and now running make ✅
<janneke>\o/
<theruran>hey that works! I can run (ls ".") now from my script
*janneke quickly looks at ls code
<bauen1>are there any (arm or x86 based) single board computers that don't involve binary blobs in the boot process or is that already impossible to achieve ?
<bauen1>i've found some allwinner based boards that come quite close but there is still a 32kb binary that runs before the actuall boot code is loaded
<janneke>bauen1: i would like to know, i have no idea
<janneke>it seems to me that the ARM world, if there is such a thing, is generally happy when "it runs"
<janneke>hopefully, devices like the librem 5 and pinebook pro can help raise some awareness and clarity here
<janneke>i am hearing good things about power9 and risc-v but have no idea how to verify
<janneke>i am determined to investigate this all harder some time, but i'm focussing on software to get our non-binary (bootstrap) act together
<bauen1>probably a good decision
<bauen1>i was looking at https://libre.computer/products/boards/all-h3-cc/ the only problem i see is that there is a 32kb "boot0" that loads the actuall boot code
<bauen1>it's the closest i've found to "just a single rom you can flash"
<bauen1>x86 is probably much worse in this regard (intel pch, me, ...)
<OriansJ>bauen1: yes we will be more than happy with gplv3 and any other alternative as long as it is FSF approved.
<OriansJ>As for the question of bootstrap binaries in x86/ARM; sadly they all have blobs all over the place
<OriansJ>bauen1: but that is why stage0 includes a hardware goal and we have tried to recruit FPGA developers to help with that problem
<OriansJ>In the more long term there is a reason why the libresilicon project is so important
<deesix>bauen1, I'm pretty sure this Allwinner A20 based board boots with mainline u-boot. I don't think there's any binary blob involved. IIRC I got u-boot-sunxi-with-spl.bin from compilation without any external input, just the u-boot repo. For 64 bits there's the ATF, but I think that's all source too.
<deesix>Olinuxino Lime2 (Rev.G2 if that matters)
<deesix>Am I missing something? Glad to be corrected.
<deesix>This was a couple of years ago; I think it's time to upgrade and review my notes of the process (it was quite straigforward if memory serves). If you're interested I can raise the priority a bit.
<bauen1>deesix: yeah the ATF is open source
<bauen1>i'm not sure but according to what i looked up there is a 32kb binary blob (boot0) that isn't open sourced
<bauen1>it sets up ram and finally loads the bootloader from the eeprom
<bauen1>supports some stuff like flashing the eeprom over usb
<bauen1>but it sits on a real rom so no removing that ...
<deesix>It seems there's source for that also, but yeah... ROM
<deesix> https://linux-sunxi.org/BROM#Source_code_for_boot0_and_boot1
<OriansJ>deesix: let us just say, we can try to make the best of the bad situation until we get free hardware designs.
<OriansJ>in the mean time, portability across architectures will remain a goal in the bootstrap pieces that I write; so that we don't depend upon any hardware in particular.
<deesix>hmm, but boot0 comes from NAND or MMC. So that't not what's in ROM (which is onchip even). I think after the ROM you jump to u-boot code (in SD Card in my case).
<bauen1>it's not open source for the more recent chips but yeah
<deesix>I'm positive that I bought this 32 bits card because it was the most free option I found. For 64 bits I got the A64 based TERES-I.
<deesix>As OSHW as you can get (module the SoC of course, which is another battle).
<deesix>*modulo
<OriansJ>deesix: you are also forgetting the horizontal microcode also inside the CPUs themselves; which applies to all modern processors
<deesix>People at #linux-sunxi is very friendly and did/does an amazing job. #olimex is mostly idle but it's also a good place. I think some other people from here are there. vagrantc for example.
<OriansJ>deesix: well the community does have alot of cross-polination of ideas and various attempts from numerous directions to address the problems that we collectively see.
<deesix>OriansJ, sure... who knows what's inside those SoC.
<OriansJ>Some try to mine out freedom from chips we can buy today, others work to enable to us to make chips tomorrow (libresilicon, opencores, etc)
<OriansJ>all are needed and the diversity of approach is perhaps one of the community's greatest strenghts. No single failure matters
<OriansJ>Projects are born, grow and either die or bloom.
<dddddd>OriansJ, M1 negative numbers are somehow funny 0b-1010, 0x-ABCD... but I see how that's simpler (:
<dddddd>Today I'm going for the '<' elements.
<OriansJ>very nice
<dddddd>The NEWLINE stuff is a bit "complex", as in several parts involved in tricky invariants (for example EOF triggering a NEWLINE, and the not quite obvious interactions with print_hex... where I was in doubt about i->next->type not getting NULL for next).
<dddddd>The padding for Knight also would benefit from some comments, to clarify the intent.
<dddddd>As easy understanding is a explicit goal, those details are important. One can get to the by study, but a couple of sentences can avoid many [aggregated] hours.
<dddddd>*get to them
<dddddd>Hmm, so '<' just pads an amount, not helping with alignment calculation. I see.
<OriansJ>dddddd: it only helps alignment in hex2
<dddddd>Also, it doesn't take into account the format requested for the output. It seems that hex is implicit (size = size * 2) AFAIU.
<OriansJ>dddddd: true, the only architecture that needed alignment to work was ARMv7l and it expected word alignment
<dddddd>I'm not talking arch, but output format (--binary --octal)
<OriansJ>and <#### support was added to allow explicit null padding on those architectures where such padding would be needed
<OriansJ>well alignment is just about the byte addresses, not the number of characters used
<dddddd>But if you want some bytes of padding and the output is, say, binary... you're not getting those bytes but some bits.
<OriansJ>ummm dddddd hex2 only outputs individual bytes
<dddddd>M1
<OriansJ>M1 doesn't do alignment, only padding
<OriansJ>but you are correct, for binary and octal it needs more than just 2 0s
<OriansJ>I should probably add some conditional logic to do the correct behavior for octal and binary
<dddddd>OK, I'll fix that on M1.scm also. I guess it's not common to ask for binary/octal but at least it won't surprise the user.
<dddddd>The other option is to remove binary/octal if we don't want to support it, because unused(?)
<OriansJ>Well some architectures much better map to binary and octal
<OriansJ>and supporting them is minimal effort
<dddddd>OK
<dddddd>Do you feel it might be more features of M1 that lacks proper support for --binary or --octal?
<OriansJ>well M1 has very few features
<dddddd>And we just found one hole in them, I'm wondering it happens with some more.
<OriansJ>well it certainly is possible
<OriansJ>I am quite human
<OriansJ>The only other place where it could appear is hexify_string
<dddddd>Sure, don't get me wrong. But if those corner cases are forgotten for quite some time... maybe you can recall more additions that were added with that blind spot.
<OriansJ>the only features M1 has are: line comments, the ability to pass labels and pointers, DEFINEs (which you can do arbitrary things with), <### padding, 'hex literals which does not do any processing' and "RAW strings"
<OriansJ>(oh and the passing of < alignment characters to hex2)
<dddddd>input numbers in several formats and sizes, endianness (bit endianness non-exposed I think)
<OriansJ>very true
<OriansJ>mostly because we haven't found any little bit endian hardware that was manufactored post 1962
<dddddd>Is mescc-tools/M1-macro.c the canonical one?
<OriansJ>yes
<dddddd>OK, I guess I leave out the bit endiannes for now, or just put at the bottom of the list.
<OriansJ>It is possible but also the sort of thing which is a nightmare to support
<OriansJ>because virtually all tools assume big endian bits
<OriansJ>Even ARM with their little Endian, write the whole instruction as a single operation instruction set; still opted for big endian bits
<OriansJ>So instead of [4bit cond] [8bit op] [4bit reg] [4bit reg] [8bit shift] [4bit reg]
<OriansJ>it is [4bit shift] [4bits reg] [4bits shift] [4bits reg] [4bits reg] [4bits op] [4bits cond] [4bits op]
<OriansJ>sorry [4bit shift] [4bits reg] [4bits reg] [4bits shift] [4bits op] [4bits reg] [4bits cond] [4bits op]
<OriansJ>an instruction set that should be ideal for Hex encoding; a big mess because they thought word endianess mapped to bit endianness?
<OriansJ>If ARM actually did little bit endian, it would have been a perfect mirror to what their documentation said
<dddddd>Yes, hexify_string can't be correct.
<OriansJ>but is easy to make correct
<OriansJ>and I was thinking about http://www.megaprocessor.com/ as a potential hardware source of bootstrap
<dddddd>I keep thinking about old micro computers, but I think one can't get that far without more RAM. Maybe some of the first steps.
<OriansJ>well 64KB is enough to run cc_x86
<OriansJ>just not enough to run the binaries generated from it
<OriansJ>one needs about 1-2MB to run M2-Planet self-hosted
<OriansJ>If we broke M2-Planet into smaller pieces and added more optimizations; we could significantly reduce that
<OriansJ>But mes-m2 needs 2-4GB to run NYACC and thus leverage MesCC to build TCC.
<OriansJ>Which is why I want a POSIX buildable via M2-Planet; as that can be ported down onto any machine with 64KB of RAM
<OriansJ>mes-m2 is also very posix heavy and couldn't run on bare metal, which is a serious limitation for bootstrapping (You need a POSIX before you could use it)
<dddddd>I'd like to tackle the M2-Planet POSIX kernel task, you know. But first things first.
<OriansJ>exactly
<OriansJ>one problem at a time.
<OriansJ>but if bauen1 is open to cooperation; the POSIX becomes a priority. We focus first on x86, AMD64, ARMv7l and then AArch64
<bauen1>there's also https://monster6502.com/ (but that is 6502 which for C is a bit of a problem) and it doesn't seem to have any ram
<OriansJ>bauen1: yep it is one of the reasons I was thinking of adding a SWEET16 port to M2-Planet
<bauen1>i think a 6502 would be interesting for early stages to have something more capable to create e.g. a floppy or flash eeprom chips while also enjoying the luxury of a keyboard and display
<OriansJ>It is one of the reasons I am excited by: https://github.com/hsoft/collapseos
<dddddd>There's no shortage of things like http://www.homebrewcpu.com/ -- http://www.homebrewcpu.com/links.htm
<dddddd>Or modern kits on breadboards (Ben Eaters or something like that comes to mind).
<OriansJ>I am planning on porting cc_* to the 6502, z80 and 6809 targets to enable more potential roots of trust
<OriansJ>Hence why I feel no rush to go to hardware with stage0
<OriansJ>The Pieces are designed to be ported and specialized
<OriansJ>and M2-Planet is a very comfortable subset of C (structs, unions, inline assembly, gotos, etc)
*dddddd is a bit tired of "everything is on github" </minirant>
<OriansJ>It is why early on there was a plan for M2-Planet v2.x to be 4 seperate programs (Macro preprocessor, generic C state-machine compiler, High level optimizer and architecture specific specializer)
<OriansJ>dddddd: completely fair
<OriansJ>I probably should get a few pieces moved over to savannah
<bauen1>or gitlab or straight to self-hosted ;)
<OriansJ>bauen1: I don't want anything to solely depend upon me to keep it working
<bauen1>fair point
<bauen1>*good point
<OriansJ>That is why I believe in taking the time to fix anything that is not entirely clear and to always explain in as much detail as anyone desires every single detail about any and all pieces
<bauen1>i should probably reflect a bit on my coding / commenting style ...
<OriansJ>bauen1: well trust is easiest when people are not confused by what things are doing.
<OriansJ>What is being done should be easy to understand and check
<OriansJ>I'd rather a slow program that everyone can easily know is correct than a fast program that no one knows how it works.
<OriansJ>It also makes it easier to onboard new developers if the cognative load required is reduced.
<dddddd>To be honest, many pieces are failing on that front.
<OriansJ>very true dddddd and improvements are definitely required
<dddddd>We'll get there (:
<OriansJ>in time
<dddddd>Note that sometimes it's better to document while coding, instead of later on. Fresher details.
<dddddd>Good naming helps a lot! I just learned to not trust most of our naming, go figure.
<OriansJ>Very True and I am bad at documentation, comments and commit messages by default and I need to work more on getting better at it.
<OriansJ>fortunately fixing of names in C is rather simple
<dddddd>For example Tokenize_Line... not true at all. Even worst on the scheme version (which handles serveral files, instead on just one --no one line, never). Not to mention that SometimesLikeThis, other_like_this, and every possible combination in the same file. O_o
<OriansJ>dddddd: I guess I am bad at naming conventions too
<OriansJ>but nothing that a sed command couldn't fix
<dddddd>The arguments to the programs are a bit of a mess and harder to fix (only add more coherent aliases and keep the old ones for compatibility).
<dddddd>Commits are not sed fixeable (if one minds that, pet peeve of mine you know).
<OriansJ>lots of potential cleanup indeed
<dddddd>Sometimes the priorities are other, and I understand how we got here.
<dddddd>Just my 0.02
<OriansJ>dddddd: it is easier to fix externally facing details early on.
<OriansJ>So if the argument names are wrong, it is best that we fix those immediately before M2-Planet+mescc-tools becomes too successful
<OriansJ>The internal naming details we can always address later (without having to worry about breaking anyone else's bootstrap)
<dddddd>--LittleEndian --BigEndian are the worst offenders that come to mind. That camel case does not match at all.
<OriansJ>we already went through one painful transistion with argument names in mescc-tools (--Architecture # with --architecture $name)
<dddddd>--BaseAddress
<OriansJ>you want them all lowercase?
<dddddd>--exec_enable
<OriansJ>dddddd: I was thinking of doing something alternate with that
<dddddd>I think so, and dash as word separator is more common I guess.
<OriansJ>say --non-executable and have the default without the option executable
<OriansJ>that way the current --exec_enable just becomes a nop
<OriansJ>dddddd: so --big-endian instead of --BigEndian?
<dddddd>yeah
<OriansJ>and --base-address
<dddddd>makes sense
<bauen1>nice along with a copy of lib6502 i found my own attempt at bootstrapping a 6502 from almost nothing, got all the way to hex and comments ...
<OriansJ>bauen1: nice
<OriansJ>hex2 has been renamed and the documentation has been updated
<dddddd>great, thanks OriansJ. In the manpage [--output FILE --non-executable] shouldn't be [--output FILE [--non-executable]]?
<dddddd>And, padding with null-bytes is supported by M1.scm, for every possible output format, with the count of bytes expressed in any base.
<OriansJ>dddddd: I'll fix that shortly
<dddddd><16 <0x10 <020 <0b10000
<OriansJ>nice
<janneke>dddddd, OriansJ: love it, ty!
<OriansJ>I am currently also fixing hexify_string in M1 to support octal and binary outputs
<dddddd>janneke, my pleasure. Note that my changes are not public yet. I'll ping you then.
<janneke>dddddd: np, you're doing great work
<janneke>i have been distracted since early december, working on the scheme-only bootstrap and arm things, now pinebook pro -- also fun
<OriansJ>janneke: honestly it is entirely understandable
<dddddd>janneke, can you connect via serial?
<OriansJ>also hexified strings will be broken into bytes for easier checking
<janneke>dddddd: yes, the 2nd serial cable that i oredered "just worked"
<janneke>dddddd: and i succeeded in installing Guix System: https://joyofsource.com/guix-system-on-the-pinebook-pro.html
<OriansJ>and patches are up
<janneke>with some hacks
<dddddd>Good idea, OriansJ. Do you think we should do the same (separate bytes) for the null padding?
<dddddd>janneke, nice!
<theruran>janneke: yes, well done! good work.
<OriansJ>well dddddd put this into a test file: https://paste.debian.net/1130857/ and checkout the new M1 output
<janneke>ty!
<OriansJ>I've set the NULL padding for knight to only occur when working in Hex (mostly because the padding isnt an architecture requirement but rather to make disassembly simpler)
<dddddd>I can imagine, OriansJ. A bit noisy for strings. I was wondering if breaking the run of zeroes (not as noisy) into bytes is worth.
<dddddd>OriansJ, oh... I guessed it was a requirement of Knight.
<OriansJ>Nope; entirely to make a hand written disassembler's job easier
<OriansJ>because I had to write my own disassembler for knight
<OriansJ>and I did something similiar in M0's output, which made it a little more complicated but enabled easier to debug binaries
<OriansJ>because debugging bootstrapped binaries is hard enough, without also having to debug your disassembler at the same time
<dddddd>See, that's the kind of insight that a well placed comment can convey. Never guessed that.
<dddddd>And can separate that reason from the architectural ones that we might add for other archs.
<OriansJ>Honestly, I am still debating if I should just go back and remove that bit of extra complexity
<dddddd>Me too... now that's clear that we are not helping arch requirements, maybe don't do it at all. The rationale for align, say AArch64, was grounded on not doing only for some archs (but we're not doing it for any of them, so...)
<OriansJ>well we can certainly strip out features of M1 and hex2 that are not absolutely needed
<dddddd>If the user places a "string" between code or some other data, they need to know what they're doing.
<dddddd>The disassembler simplification is not a bad reason, all said.
<OriansJ>well, I would prefer to hide as much of that as possible from them when they use M2-Planet but at M1 and below, that is unavoidable
<OriansJ> https://github.com/oriansj/stage0/blob/master/High_level_prototypes/disasm.c
<dddddd>syncing the instructions if you can't count of alignment is a guess of heuristics at best, I suppose.
<OriansJ>yeah, it was a very cheap and dirty hack to get a mostly right disassembler
<OriansJ>I was also tempted to do something like <4 :string_label "foo" to provide a hint to the disassembler that what was to follow would be a string and not instructions
<OriansJ>but simply adding support for autogenerating labels and tagging the bits after labels pointed to by loads it as data probably would have been a better plan
<fossy>I would appreciate thoughts on my plan to refractor kaem to use linked lists
<fossy>a doubly linked list
<fossy>(For tokens that is)
<fossy>I feel like it would make the code at least slightly clearner
<fossy>and it would allow more atttributes on the token to be stored much more easily
<fossy>rather than a char**
<OriansJ>it is fine; but you will need to convert the list to an array before calling execve (when it comes to passed args and environment)
<fossy>yes, that is what I was thinking about
<OriansJ>It should be rather simple to do as a function
<OriansJ>eg char** nenvp = list_to_array(list);