Porting to a custom ISA
Hello everyone, I am currently in the process of porting gcc to an ISA I designed with a few others (spec [1]). Using the old ggx/moxie tutorial as a guideline and looking at the source of other backends, as well as the quite decent gccint document, I managed to get basic programs running (binutils, especially gas, was also not too hard to get running). I am now partially writing here because the gccint documents tells me to do this (I am unsure if our project will ever be mature enough to be added to gcc, but I don't think it hurts to strive for that), and partially because I do need a bit of help with some stuff that I can't find documentation for. One of the big challenges I am facing is that for our backend we sometimes support 16bit as the max size a CPU supports, including for pointers, and sometimes 32bit or 64bit. Am I seeing it correctly that POINTER_SIZE has to be a compile time constant and can therefore not easily be changed by the backend during compilation based on command line arguments? Also, on another backend I saw comments relating to libgcc (or newlib?) not working that well on systems where int is 16bit. Is that still true, and what is the best workaround? And a bit more concrete with something I am having a hard time debugging. I am getting errors `invalid_void`, seemingly triggered by an absent of `gen_return` when compiling with anything higher than -O0. How do I correctly provide an implementation for that? Or disable it's usage? Our epilogue is non-trivial, and it doesn't look like the other backends use something like `(define_insn "return" ...)`. Many thanks in advance, MegaIng [1]: https://github.com/ETC-A/etca-spec
Re: Porting to a custom ISA
On Aug 15, 2023, at 7:37 AM, Paul Koning wrote: On Aug 15, 2023, at 7:37 AM, MegaIng via Gcc wrote: ... Also, on another backend I saw comments relating to libgcc (or newlib?) not working that well on systems where int is 16bit. Is that still true, and what is the best workaround? I haven't seen that comment and it doesn't make sense to me. Libgcc certainly is fine for 16 bit targets -- after all, GCC supports pdp11 which is such a target. And while newlib doesn't have pdp11 support I have done some fragments of pdp11 support for it, to give me a way to run the execution part of the GCC test suite. One of these days I should do a better job. As far as I know it's entirely doable. The comment is in msp430.h and rl78.h, line 160. And it appears quite common to artifically set `UNITS_PER_WORD` to 4 instead of the correct 2 or 1 when compiling libgcc accross other backends as well, including avr, gcn. Is this out-of-date and no longer required for libgcc? pdp11, in GCC, can have either 16 or 32 bit int, it's a compiler option. Pointers are 16 bits, of course. And it does support larger types (even 64 bits), expanding into multiple instructions or libgcc calls. A lot of that is handled by common code; the pdp11.md machine description handles a few of them to optimize those cases beyond what the common code would produce. If you're doing a 16 bit target you might look at pdp11 for ideas. One limitation is that right now it does only C, mainly because the object format is a.out rather than ELF. That could be fixed. Thank you, I will take a closer look at pdp11. paul
Re: Porting to a custom ISA
On 2023-08-15 15:30, Paul Koning wrote: On Aug 15, 2023, at 8:56 AM, MegaIng wrote: Am 2023-08-15 um 14:48 schrieb Paul Koning: On Aug 15, 2023, at 8:06 AM, Richard Biener via Gcc wrote: On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc wrote: ... And a bit more concrete with something I am having a hard time debugging. I am getting errors `invalid_void`, seemingly triggered by an absent of `gen_return` when compiling with anything higher than -O0. How do I correctly provide an implementation for that? Or disable it's usage? Our epilogue is non-trivial, and it doesn't look like the other backends use something like `(define_insn "return" ...)`. Somebody else has to answer this. Again using pdp11 as an example -- it doesn't define any of the *return patterns either. Instead it has a define_expand "epilogue" which calls a function to generate all the necessary elements, the last of which is a machine-specific pattern that will produce the final return instruction. This is using the RTL flavor of prologue/epilogue. At one point in the past that target directly emitted the assembly code for those, which isn't the recommended approach. I tried the RTL flavor and found it to be a better answer, and it certainly works for all the optimization levels. Yeah, I am also using define_expand with prologue and epilogue, but for some reason gcc still calls gen_return from cfgrtl.cc line 1705 (might be out-of-sync with master) inside force_nonfallthru_and_redirect, and I don't really understand how to avoid that call. Do I need to define some extra target hooks or undefine some that I have? I can't think of anything, but I wrote that code a while ago. Does your epilog RTL end with an jump type RTL that will produce the actual function return instruction? See pdp11.cc line 446 -- that's the final instruction of the epilog. I made it an "emit_jump_insn" because that seemed the right thing to do, but it may be it's necessary for that to be a jump type RTL. Yes, I also tried switching to `emit_jump_insn(ret_rtx)` instead, which a few backends use, but this doesn't make a difference. It seems to be that the error is unrelated to the epilogue. It fails during the "branch reordiering" pass, using code the docs attributed to a different pass from what I can tell. during RTL pass: bbro ../test2.c: In function ‘display’: ../test2.c:18:1: internal compiler error: in invalid_void, at ./insn-target-def.h:189 18 | } | ^ 0x77bf12 invalid_void ./insn-target-def.h:189 0x9d4a64 force_nonfallthru_and_redirect(edge_def*, basic_block_def*, rtx_def*) ../../gcc/cfgrtl.cc:1705 0x9d618c fixup_reorder_chain ../../gcc/cfgrtl.cc:4080 0x9d618c cfg_layout_finalize() ../../gcc/cfgrtl.cc:4575 0x14d8d50 execute ../../gcc/bb-reorder.cc:2682 I will try if I can find any difference in the settings between our setup and what pdp11 does. MegaIng
