Porting to a custom ISA

Porting to a custom ISA

[MegaIng]

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

[Richard Biener]

On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc <gcc@gcc.gnu.org> 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
>

Re: Porting to a custom ISA

[Paul Koning]

> On Aug 15, 2023, at 8:06 AM, Richard Biener via Gcc <gcc@gcc.gnu.org> wrote:
> 
> On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc <gcc@gcc.gnu.org> 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

[MegaIng]

On 2023-08-15 15:30, Paul Koning wrote:
>
>> On Aug 15, 2023, at 8:56 AM, MegaIng <trampchamp@hotmail.de> wrote:
>>
>>
>> Am 2023-08-15 um 14:48 schrieb Paul Koning:
>>>> On Aug 15, 2023, at 8:06 AM, Richard Biener via Gcc <gcc@gcc.gnu.org> wrote:
>>>>
>>>> On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc <gcc@gcc.gnu.org> 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

[Georg-Johann Lay]

Am 15.08.23 um 14:06 schrieb Richard Biener via Gcc:
> On Tue, Aug 15, 2023 at 1:38 PM MegaIng via Gcc <gcc@gcc.gnu.org> 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

[Paul Koning]

> On Aug 15, 2023, at 7:37 AM, MegaIng via Gcc <gcc@gcc.gnu.org> 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

[MegaIng]

On Aug 15, 2023, at 7:37 AM, Paul Koning wrote:

>
>> On Aug 15, 2023, at 7:37 AM, MegaIng via Gcc <gcc@gcc.gnu.org> 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

[Paul Koning]

> On Aug 15, 2023, at 8:49 AM, MegaIng <trampchamp@hotmail.de> wrote:
> 
> 
> On Aug 15, 2023, at 7:37 AM, Paul Koning wrote:
> 
>> 
>>> On Aug 15, 2023, at 7:37 AM, MegaIng via Gcc <gcc@gcc.gnu.org> 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

[Jeff Law]

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