<stikonas>we don't really have a list in either case <stikonas>it's probably easier to say what is supported... <stikonas>anyway, M2-Planet is missing . operator, post/pre increments/decrements <stikonas>somethng is still buggy if defines or maybe ifdefs <stikonas>then no support for multidimensional int arrays <stikonas>no support for type casting, i.e. (int) variable <stikonas>maybe related to . operator, but structs can only be defined globally and allocated with malloc, no support for storing structs on stack as local variables <stikonas>cc_* is missing even more, but that doesn't really matter since M2-Planet is written to be buidlable with cc_* <stikonas>also, some of the things I mentioned above are not really needed <stikonas>e.g. I think we can live without int[X][Y] <gbrlwck>i was documenting the bootstrapping path for my thesis and figured, it might illustrate the tools better to know which c construct /don't/ work with them :) <stikonas>gbrlwck: oh, another big thing is pointer arithmetic <stikonas>p+=1 means adding 1 to address rather than size of the type <stikonas>gbrlwck: there are some smaller issues too, e.g. boolean operators do not short circuit <stikonas>and in fact they might be bitwise operators rather than boolean <stikonas>I think I fixed it for !, so ! acts as boolean not rather than bitwise not because I needed that functionality. But && and || are probably still & and | <stikonas>until recently M2-Planet also didn't support compound assignment operators, e.g. += but that was added recently <stikonas>also arrays of pointers now work, e.g. char **argv (so argv[0][2] does work). Not to be confused with int a[2][3] which is not an array of pointers <gbrlwck>also, i might have stumbled upon an issue for the riscv port, but maybe you can help <gbrlwck>in hex2 we use & to prefix 32-bit addresses (the value is replaced when linking the files) <stikonas>I think that is true generally for all arches <gbrlwck>in riscv single-instruction jumps only take 12-bit immediates; for 32bit jumps we need to `lui' first <stikonas>e.g. to create array of pointers that point to some data later <stikonas>well, % is same thing but relative displacement <gbrlwck>i branch with an immediate value (which is a label); only problem i can imagine is if the label exceeds 12-bit <stikonas>so branching condition skips one instruction (which is jump somewhere far) <gbrlwck>but there's no way to check the length of the jump before linking stage, is there? <stikonas>since JAL still only accepts 20-bit intermediate <stikonas>and jumps are in multiple of bytes, I think instructions <stikonas>should be sufficient for M2-Planet and mescc <stikonas>we don't get to 1MiB sized binaries till much much later <gbrlwck>otherwise we would have to implement a smarter linker (replacing a single instruction with two others also alters all the labels) <stikonas>it might be that we can even reach binutils before we reach such big binaries <stikonas>anyway, riscv64 will need other problems solved before we can even reach binutils ***pritambaral is now known as prite
<gbrlwck>isn't 2^20 more like 1024^2 aka 1MiB? and in signed that'd be +- 512KiB (RISC-V addresses in Bytes, an instruction is 4 Bytes) so that'd give us 128 KiB of relative jumps)? <gbrlwck>sorry, i mean relative jumps of +- 128Ki instructions <stikonas>gbrlwck: risc-v instructions are 32-bit long, so that's 4 bytes <gbrlwck>i'm not sure. from the specs: "An instruction-address-misaligned exception is generated on a taken branch or unconditional jump if the target address is not four-byte aligned." <gbrlwck>i'd say jal 1 is 1 byte forward (and raises an instruction-address-misaligned exception) <gbrlwck>it's the same in both :) and in the link you posted hours ago you "RS1_A0 @8 BNEZ" :) <stikonas>if you look at that line, value must be even <gbrlwck>true! i now see that the LSB is omitted from the B and J instruction types <gbrlwck>so we virtually have 21 bits at disposal, so +- 20bit which is +- 1MiB, but since we do full 32bit instructions the lowest bit is discarded again -- hence +-512KiB <stikonas>no, that was true only for B-type instructions <stikonas>J-type (JAL) is just 20-bit, there is no unused bit <gbrlwck>there's also no LSB (bit 0) in J type instructions <stikonas>anyway, the linker deals with these issues <stikonas>and if we ever hit limits, then that can be fixed <gbrlwck>i will and i do :) thanks for the clarifications!