IRC channel logs

<stikonas[m]>But knight is just one of the arches we support. We support a few others that are 100% not made up

<stikonas[m]>rillian we have knight, x86, amd64, aarch64, riscv32 and riscv64

<stikonas>rickmasters: so that "memory corruption" issue was something completely stupid and easy to fix, today I spotted and fixed it in 5 minutes

<stikonas>I called calloc(n) rather than calloc(n, 1)

<rillian>muurkha: ok, thanks. I couldn't find any likely sounding sources online.

<rillian>stikonas[m]: sure. but the knight vm has a nybble-aligned instruction coding which I assume makes the M0 header much smaller that in the other archs?

<stikonas>rillian: by M0 header you mean list of DEFINES?

<rillian>yes

<stikonas>possibly, but size of M0 header is not that important...

<stikonas>but it does map nicer than x86/amd64 to hex

<stikonas>risc-v has word alight (32-bit) instructions too, which makes early hex stages trickier

<stikonas>but once we get to M0, it is actually fairly nice

<stikonas>I guess knight was the first "stage0" arch, so stage0 design was made to work nicely with knight

<stikonas>and other arches were added later, so we had to extend design as they were added

<rillian>makes sense

<stikonas>(though I can only speak for risc-v)

<rillian>I was just looking at the risc32.M1 source. quite different syntax from the other asm I've seen. Is there a write-up of how to read it somewhere?

<stikonas[m]>Mostly in hex2 and M1 source...

<stikonas>so in hex2 files . means "merge the hex into the next one"

<stikonas>i.e. ".00000001 20000000" is 20000001

<stikonas>that allows to map individual assembly words (like opcodes or registers) into hex

<rillian>merge like bitwise-or?

<rillian>stikonas[m]: oh, that's quite clever. do the registers then come first since not all opcodes have registers and you don't want to have to backtrack?

<oriansj>muurkha: well if we want to be exact, it is my implementation of what I saw in a magazine ad for a product from a failed computer company from long enough ago that the patents (if they had any) expired and the odds of anyone trying to claim copyright on it is quite minimal.

<rillian>they put the instruction set in a magazine ad? the 01970's were an amazing time, not not just because of octal!

<oriansj>So, I'm not sure of how you feel we should define that.

<rillian>define an advertisement? an isa? my terrible long-now-octal-calendar joke?

<oriansj>Because I don't feel like I deserve credit for it but I'm more than happy to take any blame for flaws and/or defects in my documentation and implementation of it

<rillian>ok. I was just curious, since I couldn't find any other information on the architecture.

<rillian>anyway, very cool project!

<oriansj>rillian: to be fair, neither could I

<oriansj>So it includes a good bit of my guesses

<pabs3>ACTION ponders the implications of "computers aren't single-processor single-ISA single-address-space now" on stage0/bootstrappable https://www.youtube.com/watch?v=36myc8wQhLo

<rillian>pabs3: makes cross-checking easier? :)

<muurkha>no, it makes it damn near impossible

<muurkha>because *all* of those processors have to be running trustworthy code *at* *once* for your check to be secure

<pabs3>and some of these processors are responsible for booting the system and run before the main processor runs

<pabs3>for eg on the RPi, the GPU boots the ARM processor

<pabs3>there is also the issue of RAM, does stage0 run using CPU cache only?

<pabs3>the talk is worth watching to the end btw, inc questions.

<pabs3>I expect most folks here have seen it tho

<AwesomeAdam54321>the GPU boots the ARM processor <- That sounds ridiculous

<pabs3>it is :)

<pabs3>these folks are working on replacing the proprietary GPU firmware that does the booting: https://github.com/librerpi/

<oriansj>pabs3: well stage0 could run in CPU cache (if it was large enough)

<oriansj>although one is left with the question of how that data even makes it into the cache in the first place

<muurkha>usually the early stages of firmware bringup run from ROM, don't they? until they've successfully enabled RAM

<oriansj>muurkha: or Flash or it is loaded from RAM itself because the variety of RAM used doesn't need training or configuration.

<oriansj>vs some DRAM which can take over a billion CPU cycles to train the RAM before you can use it

<muurkha>training, eh?

<oriansj>well that is what they call it

<oriansj>no one knows that that firmware does and it is usually a big fat binary blob

<oriansj>^that that^what that^

<achaninja>what would be the best place to follow along with the community developments as a whole?

<stikonas[m]>rillian: precisely, we don't want to backtrack, so we put opcode last as all instructions have it

<stikonas[m]>And the good thing about RISC V M1 defines, is that they are complete, we don't need to edit that list, unlike in amd64 where defines are like mov_rax,rbx (a single define)

<pabs3>achaninja: here and the mailing list too probably

<oriansj>pabs3: exactly and we encourage people to share their bootstrapping work on them to help everyone cooperate more effectively.

<oriansj>even the I'm new and want to learn messages; allow us to know who needs help and what new interests are joining our community.

<rillian>stikonas[m]: cool

<stikonas[m]>rillian: we thought it's nicer than ending each instruction with another define such as DOT

<stikonas>I wonder if this comment written by fossy in 2020 is still valid: https://github.com/oriansj/mescc-tools/blob/master/Kaem/kaem.c#L1278

<stikonas>M2-Planet had quite a few improvements since then

<stikonas>and after another hour of work I've managed to setup "char** envp" array in UEFI

<stikonas>now I can set UEFI variables in UEFI shell and they are accessible in e.g. kaem

<stikonas>though I still need to work on propagating them to spawned processes

<stikonas>which should be done by kaem (though in practice code will be in M2libc)

IRC channel logs

2022-12-20.log