IRC channel logs
2023-06-18.log
back to list of logs
<kerravon>oriansj - not sure if you saw my message, but i asked what you required for m2libc dos support <stikonas>kerravon: it's mostly implementing syscalls <stikonas>after all I managed to port M2libc to UEFI <oriansj>kerravon: not much honestly, just to work a handful of details such as setting up argc/argv; doing a proper exit and the assembly for the syscalls (or most likely bios calls) <stikonas>M2-Mesoplanet support might be slightly more annoying <stikonas>our M2-Planet/M2-Mesoplanet preprocessors are somwhat limitted and picky <stikonas>so order of files to compile/#includes might matter <fossy>i did know that, but completely forgot about it :P <stikonas>I remember looking at that briefly when reviewing rickmasters work <stikonas>too many things are happening in bootstrapping... <stikonas>fossy: so I think that leaves us only with the case of bootstrapping from the "bootstrap" linux kernel <stikonas>fossy: do we plan to keep this long term? <stikonas>or shall we completely switch to builder-hex0 <kerravon>oriansj - I have dosstart.asm and dossupa.asm - is that sufficient? <stikonas>I guess dosstart launches anoter program? <kerravon>dosstart is the entry point of an executable <stikonas>well these need to be ported to M2libc... <kerravon>it does do a bit more work before calling main() with argc and argv though. That code is in C though <stikonas>yeah, you can do more before main in C too <stikonas>there is quite a bit of C code before we call main <kerravon>i'm not sure the assembler code requires "porting" <stikonas>kerravon: you need to arrange it in correct functions, etc... <stikonas>make sure that compiler calling conventions match your compiler <stikonas>kerravon: it is in functions, but I would say M2libc puts them more nicely <kerravon>it is designed to be cdecl calling convention <kerravon>you either need to make your compiler produce that with a switch, or you can override it <stikonas>we only have Linux on a few arches and UEFI (on amd64) <kerravon>then you don't have preexisting calling convention for DOS <stikonas>I don't think we want to change the compiler <kerravon>how can you not change the compiler to generate 8086 code? <stikonas>it's better to adapt libc to match compiler convention that we have <stikonas>kerravon: we do change compiler a bit, but not in a calling convention way <stikonas>it's just if else statement to see what is outputed <kerravon>does your compiler currently generate 8086 code? <kerravon>DOS has tiny, small, medium, compact, large and huge memory models <kerravon>those memory models are a result of segmentation <stikonas>all calling convention is hidden in a few m2libc functions <kerravon>i am after a public domain C90 compiler that targets DOS and other targets, yes. but i didn't think we were discussing that <stikonas>compiler (M2-Planet) has no idea about UEFI calling convention (which is basically Windows calling convention where some arguments are passed as registers, some pushed to stack...) <fossy>stikonas: long term, i would like to migrate completely to builder-hex0, yeah <kerravon><oriansj> kerravon: I'll even give you a public domain DOS port of cc_x86 if you are willing to help me add DOS support to M2libc <kerravon>i am discussing the latter portion of that <fossy>but other ISAs will likely require the reintroduction of the same thing when we add them, as you said <kerravon>after i have helped you achieve the latter part of that, i'll ask about the former <stikonas>possibly, that you can talk with oriansj <stikonas>fossy: so perhaps we want to keep that option working <stikonas>and also fix kernel arguments for sysb transfer from linux to linux <stikonas>fossy: though we should make sure that we don't break qemu <stikonas>fossy: right now we are getting quite a few more arches in mes 0.25, though mes->tinycc step is still problematic <stikonas>fossy: but at least M2-Planet -> mescc will be working much better in the next release <stikonas>and once we have tcc, I guess further steps should be not too hard <stikonas>I guess we'll first have pre-gen file bootstrap working there (e.g. on guix...) <stikonas>and non-pregen bootstrap will need further porting/patching <stikonas>merge or do you want to ask for changes to fix go_sysa function <fossy>i think i'd prefer go_sysb to have the change, at least for now <mihi>kerravon: you probably should know what you get with cc_x86 when you help porting its libc to DOS :) cc_x86 is a subset-of-C compiler (even a subset of M2-Planet) compiling to M1 macro assembly. M1 is a purely token based assembler, i.e. it has no idea about architectues or how instructions are encodded, it just knows that mov_eax,[esp+DWORD] is 8B8424. So in assembler parts of the libc, instead of "mov eax, <mihi>[esp+8]" there has to be written "mov_eax,[esp+DWORD] %8" (the % signalling that you want an absolute 4-byte value). It is hard coded to its own calling convention (one I have not seen before, but I mostly know x86 only), where the caller pushes arguments (either integer or pointers all same width) to the stack, and sets {E,R,}BP to the point before the first argument has been pushed. SP is stack pointer, AX is <mihi>for returning results, DI is callee saved and reserved for outer base pointer in nested function calls, BX is callee saved and reserved as accumulator, all other registers/flags are temporary and therefore caller-saved if caller needs them. Memory model assumes flat pointers, i.e. all pointers are from one linear address space, malloc allocates contiguous regions, and also function pointers are from the same <mihi>address space, i.e. no Harvard Architecture. I understand oriansj 's offer that they will port cc_x86 to DOS and put it to public domain if you help add DOS support to M2libc (and therefore M2-Planet). <mihi>I forgot that arguments are pushed left-to-right and caller has to clean stack afterwards. Due to the frame pointer set by the caller, variable arguments are possible like cdecl without requiring to reverse the arguments on stack. <mihi>(compiler does not support ... as varargs, so in C you have to declare "enough" arguments that everybody uses less than that, but callers can omit any if they don't want to pass so many. Since all function signatures are essentially the same, linking means only checking whether all function names called are also declared). <mihi>muurkha, what tools did you try to use to mirror the Miraheze wiki? The official Export tool will (as you noticed) miss binaries (there are 4 images plus maybe historic versions), so best choice might be to use <https://www.mediawiki.org/wiki/Manual:Grabbers> <mihi>or check the dumps provided on Archive.org if they are sufficiently recent. <stikonas>interesting desctription of cc_x86/M1. Though M1 does have a little bit of knowledge about some aspects of architectures, i.e. we have to tell that architecture is big endian <stikonas>and also it knows quite a bit more about RISC-V <stikonas>still, it really is surprisingly platform independent <kerravon>mihi - thanks for the info. if it's a subset of C90 then i don't have a particular use for it. I already have SubC <kerravon>you mean DOS with a DOS extender so that you can use 32-bit flat? <kerravon>because otherwise DOS is normally 16-bit with various memory models <kerravon>so the compiler can't generate all those 32-bit instructions <kerravon>well, unless you want to assume DOS running on an 80386 instead of 8086