IRC channel logs
2022-11-04.log
back to list of logs
<stikonas>hmm, even freelist implementation of malloc is not completely trivial in M2-Planet... Need to think of some tricks <stikonas>implementations seem to put some struct data into global structs before we have malloc but I don't think M2-Planet supports that <stikonas>or maybe they do, maybe only local structs are not supported.. <stikonas>hmm, no... M2-Planet just allocates NULL on (so register sized are for it) which is not enough for struct... <muurkha>it implements zeroing global structs, no? <muurkha>you can check to see if the global structs are zeroed when you are going to use them <muurkha>or design the freelist so that, for example, a null pointer means an empty freelist <muurkha>or call an initialization function at the top of main(), similar to how many crt0 entry points do initialization before calling main() <stikonas>muurkha: well, it just stores some data in global struct (linked list) <muurkha>on AVR8 for example crt0 needs to copy all the initialized global variables from Flash (where the binary is written) to RAM (which is zeroed on startup IIRC) <stikonas>and I've already tried to use initialization function on top of main() <stikonas>but we simply can't put any structs as global variables <stikonas>and structs themselves right now are all in calloc'ed memory <muurkha>oh, well, a global pointer to a struct sounds workable <stikonas>I think I'll first fix M2-Planet to allocate correct amount of space in global variable list <stikonas>ritght now it emits one NULL macro (which is 64 or 32-bits of zeroes) <stikonas>I think if we emit sizeof(struct) number of zeroes, global structs might just work <stikonas>hmm, got it partially to work though it overallocates amount of space for indirect global structs, i.e. struct a** b; might allocate too much space rather than just 1 register. <stikonas>(i = 1 should go away but that doesn't affect anything) <stikonas>(and comment might need further tweaking) <stikonas>hmm, I also need to implement . operator for global structs... <stikonas>just having enough zeroed space is not sufficient <oriansj>stikonas: the logic could just be i = (type_size->size / register_size) + 1; (as a little extra padding space will be fine) <oriansj>but yeah that will work and adding . operator support in general can just be cribbed off -> operator minus a single indirection. <oriansj>(just can only use . operator outside of the core program as cc_* doesn't support it) <oriansj>(no need to special case pointers at all) <oriansj>just be sure to add a require which will bomb out if in BOOTSTRAP_MODE and using . (that way test1000 will properly warn about cc_* bootstrapping problems) <clemens3>that's quite laudable and unusual attitude.. go-lang is similar with their 1.4 support, rustc has the worst attitude <drakonis>it also doubles as a linker and c/c++ compiler <oriansj>drakonis: as long as guix maintains a proper bootstrap chain for zig we should be good <drakonis>as long as llvm builds, the chain for building the self hosted compiler should remain achievable <drakonis>at least until the pure C bootstrap that has no llvm dependencies comes around <oriansj>well llvm is just an available standardized IR langugage; which if you think about it if just got a few more meta-programming constructs would have enabled a high level interoperability between all languages that leverages that shared IR backend <oriansj>much like how you can blend (via the C api) all languages that have a C api (and all JVM languages can blend together if you are careful) <drakonis>by the way, guix seems to be missing llvm 15, which is required to build zig 0.10.0 <lagash>Wait, really? That's unfortunate! It's am even bigger chore now.. <drakonis>its required to build the llvm backend though