Re: Porting to a custom ISA
Am 15.08.23 um 14:06 schrieb Richard Biener via Gcc: On Tue, Aug 15, 2023 at 1:38 PM 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? You could look into the AVR port for example. I think libgcc should work reasonably well here. [...] The trouble with avr-gcc was that it suffered from "spill fail" internal compiler errors from the register allocator when building Newlib. The bug was never fixed (like many problems for ternary targets like AVR). Outcome was that RTEMS (which uses Newlib) dropped support for AVR. Apart from that, I cannot recommend reading the AVR backend. It is cluttered up with hacks and FIXMEs that work around problems in the middle-end, so it is no good read. Johann Richard. Many thanks in advance, MegaIng
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
Re: Porting to a custom ISA
On 8/15/23 05:37, MegaIng via Gcc wrote: 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? We've certainly got targets which change POINTER_SIZE based on flags. It just needs to be a C expession. So you might see something like #define POINTER_SIZE (TARGET_SOMEFLAG ? 16 : 32) 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? GCC has supported 16 bit targets for eons, there are still some in the tree. libgcc and newlib also support 16 bit targets. It can be difficult to support something like double precision floating point on a 16 bit target. So some 16 bit ports only support single precision floating point. 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 ports define trivial returns. But it's much more common to need a prologue and epilogue. Those are typically define_expands which generate all the code to set up a stack frame and tear a stack frame down+return. Jeff
Re: Porting to a custom ISA
> On Aug 15, 2023, at 8:49 AM, MegaIng wrote: > > > 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? It simply seems wrong. In pdp11.h UNITS_PER_WORD is 2, which is what the machine requires. And that works fine. Perhaps the issue is that the libgcc routines implement operations not handled by the target hardware, or by expansion in the machine description. So for 16 bit machines you're going to need a bunch of 32 bit support routines, but probably not 16 bit support routines. There are some examples, though. Not all pdp11s have divide instructions so there is a udivhi3 function in libgcc, and the pdp11 config files call for that to be included. paul
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 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. paul
Re: Porting to a custom ISA
> 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. 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. paul
Re: Porting to a custom ISA
On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc wrote: > > 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? POINTER_SIZE needs to be only a C expression, not a constant > 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? You could look into the AVR port for example. I think libgcc should work reasonably well here. > 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. Richard. > Many thanks in advance, > > MegaIng > > > [1]: https://github.com/ETC-A/etca-spec >
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
