<mala>So dumb question -- but how hard would it be to use sectorlisp or similar as an alternative bootstrap into mes (on intel, obvs)? (Sorry if I've asked this before) <muurkha>hi mala! kragen here. it's an interesting question <stikonas>at least people here did not manage to write much in sectorlisp, but maybe we haven't tried <muurkha>I haven't tried programming in sectorlisp in part because I want to stay as far away from Justine Tunney as humanly possible <stikonas>so M0->cc_*->M2-Planet->mes is the only way to bootstrap mes right now <stikonas>mala: you can try if you enjoy lisp but otherwise main effort here is assembly->C pathway <muurkha>just yesterday she was crowing about how sooner or later the Library Genesis folks will be rotting in jail <muurkha>Qfitzah uses S-expressions but it isn't a Lisp; it's more like Mathematica or Q (not q, Q) <stikonas>well, we have rickmasters builder-hex0 (bootstrap stage) which also fits into 512 bytes <stikonas>and there is this new uefi stuff although it doesn't go all the way to mes yet <stikonas>but are getting more and more baremetal options <muurkha>the appeal of Qfitzah is that maybe you can avoid programming in hex0/hex1/etc. and leap instantly straight to high-level stuff <muurkha>Qfitzah also mentions that Strachey's GPM was 250 machine instructions, which I think was also about 1024 bytes <stikonas>yeah, hex0 stuff is somewhat annoying to write in <muurkha>my real concern is not how hard it is to write but how hard it is to find bugs in <stikonas>that often depends on the debugging tools that you can use <stikonas>if it runs in gdb, finding bugs is not too hard <muurkha>I don't know how much help gdb is in finding backdoors <muurkha>GPM is pretty pessimal from that point of view. not sure if term rewriting is better; it might be <stikonas>this hex2 warning is now slightly too strong "If you are not generating a ROM image this binary will likely not work" (if --base-address is omitted) <oriansj>muurkha: every instruction set that support PC relative addressing AND absolute addressing uses syntax to distinguish which the programmer in intends be it special instructions LOADR32 R0, LABEL or referencing the PC explicitly MOV RAX, [RIP+LABEL] <stikonas>or some other syntax, I think nasm had mov rax, [rel label] <oriansj>mala: to the question of using sectorlisp for bootstrapping. The answer is you have no ability to directly write any data to disk nor to memory nor jump to an address in memory. <stikonas>no need to thank me :), didn't realy do anything now <stikonas>anyway, today I cleaned up catm in stage0-uefi, now will have to go down to hex0 and kaem-minimal and cleanup rest of the stuff I've written <stikonas>possibly increasing size of binaries a bit <stikonas>but I think it's better to keep to the spec and close allocated resources <oriansj>so to make sectorlisp useful, you'll have to figure out a method for getting sectorlisp to segfault in a useful fashion which would result in either the execution of a program (like hex0 or more complex) after setting up that program in a very hard to control fashion in memory and do so within the very limited amount of memory they setup. Oh and for extra fun that data you can put in memory is in a different segment, so you'll have to <oriansj>change the segment register without writing any code into memory. <stikonas>which is probably not what we want in bootstrapping <oriansj>writing hex0 will look trivial and be an order of magnitude easier to audit. <oriansj>that being said mala sectorFORTH however is MUCH MUCH more promising as a root <oriansj>although that would require you to type about 1-4KB of input before it'll be really useful. <oriansj>and to be completely honest, there is no better bootstrap seed for x86 than Oscar Toledo G's bootOS https://github.com/nanochess/bootOS which not only has a filesystem, the ability to create files and to execute programs from that filesystem. <mala>oriansj, et all -- that is all really informative. Thank you! <oriansj>I really should port SET to bootOS and finish defining/implementing GFK filesystem <muurkha>oriansj: yeah, but lots of instruction sets don't support absolute addressing for lots of instructions <muurkha>RISC-V at its most basic level has separate LUI and AUIPC instructions for loading (the high 20 bits of) absolute and PC-relative base addresses into registers <muurkha>and most RISC-V assemblers support LI and LA pseudo-instructions which assemble to respectively LUI;ADDI and AUIPC;ADDI <muurkha>(but the register jump instruction also has a 12-bit offset field, so a jump to a 32-bit absolute address is just LUI;JR rather than LUI;ADDI;JR <muurkha>and similarly for relative addresses with AUIPC;JR) <muurkha>for 64-bit constants your best bet is loading constants from a constant pool using a PC-relative address. sadly, unlike ARM, RISC-V does not support directly indexing off the PC in a load instruction <oriansj>muurkha: well all instruction sets I have seen support absolute addressing <oriansj>The only way to not support absolute addressing is if the only way to address memory was PC relative <oriansj>because if I can load/store memory from a value in a register or from the stack, I can find a way to shove an absolute address in there. <muurkha>there's a lot of fuzziness there, but yes, being able to stick an absolute address in a register does allow you to load and store at absolute addresses in many instruction sets which don't directly support absolute addressing <muurkha>we were talking about assembly language syntax here, and there are lots of assembly languages that don't have a syntax for putting an absolute address into your instruction because the underlying instruction set doesn't have one <oriansj>and you are right that absolute addressing for jumps/calls is generally only done via loading that address into a register first. <muurkha>most RISC machines (not just RISC-V) fall in this category I think? <oriansj>muurkha: most RISC machines just use loading of immediates to populate an absolute addres into a register for use. <muurkha>there are also a lot of machines that use some sort of segmented addressing where the base address of a segment is implicitly added to all your memory addresses, like the PDP-11, and you may or may not have a way to load the base address register as an unprivileged user <oriansj>and some like RISC-V include pseudo instructions to make that easy. <muurkha>but segmentation wasn't really what we were talking about either <oriansj>well segmentation only really was popular for 8/16bit processors <oriansj>as once you have 24 or 32bits, you just didn't need such tricks to make real programs <muurkha>that's not the only thing segmentation was good for! <muurkha>on the PDP-11 it was primarily a memory protection mechanism <muurkha>a lot simpler in hardware than an MMU <muurkha>on the Burroughs B5000 line every array was in its own segment, and again the main purpose of this was memory protection <oriansj>having looked at memory overlays for the PDP-11; I can't agree with that view <muurkha>I don't know of any 8-bit processors that had segmentation <muurkha>in what sense did the 6502 have segments? <muurkha>because you could relocate the zero page and stack page on the 65816. but the 6502? <oriansj>The 6502 divides it’s 64KB of memory up into 256 byte pages which were swappable <oriansj>Bank_switching is what they called it <muurkha>oh, bank switching is something different <muurkha>and it's not part of the CPU, it's part of the memory subsystem <muurkha>lots of 8-bit micros used bank switching in order to be able to handle more than 64K. In fact the IBM PC ended up using bank switching a lot in the form of LIM EMS <muurkha>what do you mean about PDP-11 overlays? <oriansj>overlays were a way to manually page in and out code/data from/to memory/disk in a block way <muurkha>but you said that because of overlays you couldn't agree with that view. which view did you mean, and what did you disagree with about it? <oriansj>well when you are short on RAM, block overlays take less code <oriansj>as segments didn't provide protection as any process could violate all segment protections <muurkha>PDP-11 segments are not loadable by user processes, so they do provide protection. also true of 80286 and 80386 segments, though they weren't used much <muurkha>also true of B5000 segments, though in a different way; on the B5000 you can load all the segments you want at user level, but you can only load them with valid segment descriptors. you can't convert absolute addresses into segment descriptors that grant you access to that memory (unless, presumably, you're the MCP, but I haven't been able to find any documentation of that) <oriansj>The 11/20 lacks any kind of memory protection hardware unless retrofitted with a KS-11 memory mapping add-on. (Aka an actual MMU) <muurkha>"We knew the PDP-11/45, which did support memory mapping and protection for the kernel and other processes, was coming, but not instantly; in anticipation, we arranged with Digital Special Systems to buy a PDP-11/20 with KS-11 add-on. This was an extra system unit bolted to the processor that made it distinguish kernel from user mode, and provided a classical PDP-10 style "hi-seg" "low-seg" memory <muurkha>mapping unit. I seem to recall that maybe 6 of these had been made when we ordered it." <muurkha>I mean, not an MMU in the sense of paging. they did call it a memory mapping unit! <muurkha>it just had a high and low address for each segment (a base and limit) <oriansj>The Burroughs B5000 might not have had a traditional MMU but it did provide the two functions of an MMU - virtual memory addresses and memory protection (abeit in a different architectual way) <muurkha>yeah, the base/limit scheme on the PDP-11 also made memory addresses virtual and provided memory protection <oriansj>So again segments aren't protection unless there is effective MMU kernel/user separation which is enforced by hardware <oriansj>otherwise the running code can just change what the segment is pointing to at anytime for any reason <muurkha>well, the segmentation mechanism is effective MMU kernel/user separation which is enforced by hardware <muurkha>only the kernel can change what the segment is pointing to <muurkha>(the manual above calls the segments "pages" but it's clearly talking about what we call segments nowadays, not fixed-size pages) <oriansj>muurkha: my point is you can have segmentation mechanism without the separation like you see in x86 ***Guest8836 is now known as roptat
<muurkha>oriansj: oh, sure, the 8088 had "segmentation" without memory protection <theruran>oriansj: looking at Jitawa and I don't think it would be convenient or maybe even possible to use it for bootstrapping since it doesn't support mutation. that's interesting what you said about sectorLISP though ***Andrew is now known as WaxCPU