On Monday 10 April 2006 19:48, you wrote: > Can it at least add (small) immediates to registers?
Nope, sry. The only instructions that take other arguments than registers are the aforementioned LDL/LDH (load low/high), branch instructions (they take a memory address) and four bit operations which can mask, invert, set or delete a bit in a register. > IIRC, the PDP-11 is famous for accepting complex addresses, i.e. quite the > opposite of your target machine, which is so simple I would suggest you > write it from scratch. Does it need to be more than > Yes, you're right. When I started writing this backend I didn't have much experience with it. I took the smallest backend I could find and tried to adjust it to me needs. The number of macros in the internals docs was a bit overwhelming at first and GCC kept segfaulting on me - something I'm definately not used to from GCC. So, I was happy when I had something working to start with. But now I think it would have been cleaner to start from scratch. > #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \ > if (REG_P (X)) \ > goto LABEL; I tried that out today. I wasn't sure about the exact contexts in which this macro is used. It seems to work fine, though. > Try to add -fdump-rtl-greg or -fdump-rtl-greg-details when compiling > __muldi3(). This will generate a libgcc2.c.*.greg file which will say > exactly which reloads insn 260 has and which one is failing. I will try that ASAP. But I'm now having problems with GCC (gcc-cross, for the target machine) segfaulting again: $ gcc function1.c [...] function1.c: In function 'main': function1.c:10: internal compiler error: Segmentation fault (gdb) bt #0 0x0829028f in htab_find_slot (htab=0x5b52202c, element=0xbf805284, insert=INSERT) at ../../gcc-4.0.2/libiberty/hashtab.c:707 #1 0x08215dc4 in cgraph_node (decl=0xb7d1b2f4) at ../../gcc-4.0.2/gcc/cgraph.c:181 #2 0x082163b8 in cgraph_rtl_info (decl=0xb7d1b2f4) at ../../gcc-4.0.2/gcc/cgraph.c:526 #3 0x0820e937 in rest_of_clean_state () at ../../gcc-4.0.2/gcc/passes.c:1477 #4 0x0809fbed in execute_pass_list (pass=0x82ede20) at ../../gcc-4.0.2/gcc/tree-optimize.c:526 #5 0x0809fe53 in tree_rest_of_compilation (fndecl=0xb7d1b2f4) at ../../gcc-4.0.2/gcc/tree-optimize.c:661 #6 0x0805a816 in c_expand_body (fndecl=0xb7d1b2f4) at ../../gcc-4.0.2/gcc/c-decl.c:6611 #7 0x08217c65 in cgraph_expand_function (node=0xb7d1b57c) at ../../gcc-4.0.2/gcc/cgraphunit.c:835 #8 0x08217d55 in cgraph_assemble_pending_functions () at ../../gcc-4.0.2/gcc/cgraphunit.c:307 #9 0x082183f5 in cgraph_finalize_function (decl=0xb7d1b2f4, nested=0 '\0') at ../../gcc-4.0.2/gcc/cgraphunit.c:399 #10 0x0805abde in finish_function () at ../../gcc-4.0.2/gcc/c-decl.c:6580 #11 0x0804eb8e in yyparse () at c-parse.y:401 #12 0x0804f87b in c_parse_file () at c-parse.y:2936 #13 0x08081b0a in c_common_parse_file (set_yydebug=0) at ../../gcc-4.0.2/gcc/c-opts.c:1102 #14 0x081f62c0 in toplev_main (argc=3212857988, argv=0xbf805e34) at ../../gcc-4.0.2/gcc/toplev.c:1010 #15 0xb7dbaed0 in __libc_start_main () from /lib/tls/libc.so.6 #16 0x08049b71 in _start () at ../sysdeps/i386/elf/start.S:119 This is function1.c: ------------------------------- 1: int foo (short i) { 2: i = 100; 3: return i+50; 4: } 5: 6: int main() { 7: int j = foo(10); 8: j += 25; 9: return j; 10: } ------------------------------- > > 1) Does BP really have to be fixed? You are sufficiently desparate for > registers than you'll not fix BP unless the hardware itself mandates this. I thought it needs to be fixed if I want to set it aside as the frame pointer. I removed it from the fixed registers and recompiled, but I haven't had a closer look at the generated code yet. Can I do the same thing with SP? > > 2) GCC generally doesn't handle multi-word registers well. Even if you ask > for a subreg, it will either load it all into registers or nothing at all. > Richard Henderson posted a "multi-word subreg lowering" patch a while ago, > which might help. See > <URL:http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html>. The patch > needs to be updated to work on current mainline, though. > > 3) Reload sometimes fritters away registers. DJ Delorie recently submitted > a patch to allow chaining of reloads, which reduces the number of registers > needed in some cases. This will only help you if you upgrade your code base > to mainline, though. > > If you can, develop against mainline rather than an old version of GCC. I will move to mainline and see if it helps. Thank you for your time and suggestions! Cheers, Frank