<checkup>amazon.com/Raspberry-CrowPi2-Laptop-Programming-Professional/dp/B08YRGZ2JD/ref=sr_1_4?crid=2MG5FS04CINI0&keywords=elecrow%2B2%2Blaptop&qid=1656540264&s=electronics&sprefix=elecrow%2B2%2Blaptop%2Celectronics%2C104&sr=1-4&th=1 <oriansj>checkup: knight architecture is just a mini-computer architecture that failed in the market without much success <checkup>its really nice. what liscence does it use? <oriansj>saw its instruction listing in a ad in a magazine and decided to write an emulator <checkup>thats insane, how long did it take you ? <checkup>you have alot of experience with assembly or emulators ? that seems unbeleivable <oriansj>wait until you look at the git history and discover I wrote cc_x86 from scratch in less than 24 hours <checkup>seems like you could easily impliment in fpga as well... <checkup>well i guess thats encouraging to someone looking to get a bootstrap going <checkup>still gonna want the same software capabilities of <checkup>seems like a lot to think about , but i appreciate your invitation to do so. <checkup>how long do you think it would take you or someone else to go from knight vm to gcc ? <checkup>maybe ill just try to write my own vm bootstrap / cx86 compiler if you say its so easy. <oriansj>checkup: well depends on what exactly you mean by that <oriansj>checkup: messing up our flow is how we make major progress <checkup>you said you wrote the vm and cx86 so fast. i just wonder why you havne't done fpga or pushed vm to gcc <oriansj>checkup: because other problems took priority <checkup>well if you have any tips on bootstrapping in general i guess ill take em i really dont know where to restart with all this new information <checkup>anyways its very inspiring and cool that you do this oriansj i dont wanna try to weigh in im pretty ignorant of this stuff but maybe when i become more savvy i would have more to add <oriansj>checkup: well the key is to fail alot <oriansj>I wasted a bunch of time trying to do a FORTH and a garbaged collected lisp in assembly <checkup>i mean thats really hard to say when doing computer science <oriansj>checkup: while trying to create the first bootstrapping path from hex0 to Mes.c <checkup>i still wonder how much experience you had with assembly and compilers prior to doing bootstrap/vm <oriansj>I did a bunch of things that failed or ultimately not fit for purpose but we learned from them <checkup>yea i feel the same way cept i come from coding stuff in swift and angular so i really feel burnt off that <checkup>but i literally didn't know anything about coding before then so i cant be too hard on myself <oriansj>less than you would think as I am a computer security and reliability engineer <checkup>just wish i had more guidance. yea im studying security now <oriansj>checkup: well what sort of guidance are you looking for? <checkup>would be nice to build that iron man suit in ur avatar <checkup>^ gotta start with a trusted system imo tho <checkup>id love to beable to code a vm / cx86 compiler this after noon lol <checkup>then i would feel way more comfortable trying 2 port it 2 fpga / build into clang etc <checkup>so if u had any tips it would be really helpful <checkup>but i guess just the fact that u said that may get me going for now <oriansj>well if you wished to become familiar with cc_x86; the easiest path would be choose a language you like to work in <checkup>i think verilog would be best ultimately but im probably gonna want an eemulator in c <checkup>and try to work backwards into a portable compiler from a bootstrap <oriansj>checkup: well Operating systems work by removing compatibility <oriansj>imagine you have two identical computers (in terms of hardware) <checkup>not really many options for 'os's i really like freebsd it has a nice liscence and linux is too bloated for me <oriansj>one has Linux installed and the other has Windows installed. <checkup>i cant use windows. it literally crashed and uninstalled itself from my microsoft laptop after i tried 2 make a virtual bridged network for qemu <checkup>so i just wanna get bsd on there and put a gui on it that isn't "x11" <checkup>ill probably code the gui from my hand / github scraps <oriansj>So in terms of hardware functionality, there is no reason why a set of assembly instructions shouldn't work the exact same on both but the Operating systems introduce that incompatibility by requiring custom syscalls to do anything interesting <checkup>the only abstraction im interested in <checkup>is the abstraction that would make the assembly or abstract code portable 2 arm risc64 <checkup>i think all the other stuff is more 2 lock u into their product <oriansj>and one which has some of the most arbitrary rules (like stack has to be multiples of 16bytes in depth) <oriansj>checkup: sounds like you would love something like code-morphing <checkup>this is what im really interested in <checkup>if were talking about "root of trust" <checkup>An implementation of an FPGA slice entirely in 7400 series discrete logic, and a compiler for a custom HDL dialect for same. <checkup>that can easily be implimented on hardware or a logic emulator or verilog <checkup>i just want to know my stuff is gonna run on a cheap laptop or phone or something <checkup>before i go deving a bunch of stuff on top of it <checkup>anyways now im just talking in circles <checkup>so i guess i will just bounce try to sort out some code thanks for your words of wisdom <oriansj>checkup: the best advice we have is do what seems like the most "fun" for you. <oriansj>bootstrapping tends to be a long and slow process to get to impressive points but a great many still remain to be done by those willing to do the work. ***attila_lendvai_ is now known as attila_lendvai
***genr8eofl__ is now known as genr8eofl
<tinybronca[m]>Hi all, can you currently go directly from GCC 4.7.x written in only C directly to GCC 12.1? <stikonas>tinybronca[m]: by the way, why do you build GCC 4.7.x with just C? <stikonas>but anyway, if you have C only GCC 4.7.x, build GCC 4.7.4 (C++ version). Then build something much newer but not newer than GCC 10 <stikonas>GCC 11 probably needs something like GCC 6 <mihi>tinybronca[m], stikonas, according to LFS you need at least GCC 4.8 to build GCC 11. Guix goes 4.6.4, 4.9.4, 11 (probably since build times on gcc4.9.4 are lower than on later versions and you usually build your final compiler twice anyway so that it benefits from its own optimizations) <stikonas>yeah, maybe GCC 4.8 is good enough for GCC 11... <mihi>btw stikonas I would love to know where you work, where you work with fpgas but not code for them :) (feel free to reply off-chatas it is off-topic here). Re FPGA, I've programmed one in a semester project at univesity about 20 years ago, and you don't really code "for FPGA" just like you don't code "for qemu-system-riscv"; you write hardware definitions in VHDL/verilog/etc. and synthesize them to <mihi>FPGA. But I don't have the equipment any longer, and also the synthesis times (about 45 minutes for a register file with 16 registers 32-bit each that supports two reads and one write per clock cycle) made me avoid investing in hardware for making this my hobby. <stikonas>I guess 4.7.4 has some C++11 support but probably not everything <mihi>On the other hand, I guess live-bootstrap cycles take longer, so don't be deterred by that. <stikonas>mihi: Xilinx or I guess these days it's AMD <mihi>ah ok, your company makes those things :) <stikonas>kind of but not my team, I was originally from Solarflare that produced low latency NICs then we got bought by Xilinx and then AMD <mihi>yeah, I assume low-latency NICs probably need their own ASICs, and when you build them you need FPGAs for prototyping :) <mihi>and 45-minutes synthesis are nothing compare to weeks for building an ASIC :D <oriansj>mihi: modern processes can easily take 9months of wafer processing steps <stikonas>well, I don't know much about ASICs either... <mihi>checkup: when catching up with logs... If you are interested in bootstrapping on UEFI, the first step would probably be to make M2libc and M2planet target the UEFI shell environment. Which requires three main changes: 1) UEFI does not use syscalls, but your entry point gets a pointer to the UEFI SYSTEM TABLE which is a giant list of function pointers. Instead of using syscall numbers, you call these pointers. 2) <mihi>The file format is PE/COFF and not ELF, so you need new hex templates for this. 3) There is AFAIK no such thing as a source-level debugger or debug symbols, so blood-elf gets removed from the process, but you also have it harder to debug. <stikonas>yeah, UEFI might actually be somewhat easier than BIOS/MBR <mihi>Next step would be to port hex0 et al to that environment. When you are one of the lucky guys who own a UEFI computer that boots to the shell if no bootable media are detected, you can then use built-in hexedit to write hex0 to some media that contains sources and start bootstrapping from there and then build oriansj's M2-Planet buildable kernel (once it exists) to continue bootstrapping. <mihi>when you can live with the fact that there is no multitasking and only one core is active, it is quite a usable OS. You have support for disks, filesystems, keyboard, mouse, wired network. And if you are lucky, your firmware includes the UEFI shell (if not you can boot it from USB) <stikonas>well, we don't need multitasking (unless it's for kaem) <stikonas>builder-hex0 has some hack to support that <mihi>M2libc would have to be changed to provide spawn() as alternative to vfork/exec. And you would need some ifdefs in kaem to use whatever is available. <stikonas>yeah, luckily simple ifdefs are allowed in kaem <mihi>Ok, M2-Mesoplanet would also be needed, but I assume that is just a recompile once M2-Planet and M2libc are there <stikonas>no, M2-Planet has some support for ifdefs <stikonas>well, ok, we do use Mesoplanet later in stage0-posix <stikonas>but it's the same forking code as in kaem <mihi>and back to FPGA/ASIC. Technically to write HDL you don't have to know how they work on the lower level. If you understand how gates (and or nor xor, etc.), flip-flops and latches are working, and how the latter ones interact with clock and reset signals, you've understood the hardest part. the rest is just syntax and from your contributions to stage0 I know you are good at pickup up such things quickly :D <mihi>about commercial OSes not having stable syscalls: Yes, seems so. Not only OSX but also Windows regularly shuffles their syscall numbers. That's why every sane Windows binary needs to (directly or indirectly) link against NTDLL.DLL which contains stubs that call the syscalls. <mihi>And probably it is the only way to enforce syscalls not being part of the documented ABI. If you don't shuffle them, users will call them and you will be doomed to support them forever to not break existing programs where no programmers/source exist any more.