> Also are you doing pic code or non-pic code? Is your chip a mips clone? Both pic and non-pic codes are supported. The chip has some features from arm, such as conditional execution, scaled immediate, pc-relative branch. I choose mips-elf as start just because we are familiar with mips and that seems easy to do.
I modified the bfd relocation type and used the pc-relative branch to implement function call. It worked with non-pic codes, but failed with pic code. The error is just about 'relocation truncated to fit' as I said. So with your suggestion, I think I need a register to hold the function address anyway. Whatever we do with gcc backend or as/ld. I see. Thanks Eric 2006/2/14, Mike Stump <[EMAIL PROTECTED]>: > On Feb 13, 2006, at 8:31 PM, Eric Fisher wrote: > > Thanks. I'm working to port gcc to our chip. I use mips-elf as the > > start. > > Most chips have this same issue, you can copy from ppc for example, > or arm, if your chip is more like it (hope not). > > > we don't have pc-region branch instructions such as 'j target'. So I'm > > confused how to solve the function call translation. > > I am sorry you didn't understand my answer to your question. I'd be > happy to try and help you, but I am limited in what help I can > provide if you cannot answer my questions. > > There are a multitude of possible questions you could be asking and > I'd need help in narrowing down which answer you seek. > > Also are you doing pic code or non-pic code? Is your chip a mips clone? > > Anyway, to try and answer part of your question, no, you don't have > to generate: > > la reg, func > b reg > > there are other possibilities, for example, you can train as/ld to > extend them by inserting code to jump to the right place, and then > jump to that code, but, this is harder than just generating the above > and can require that your abi reserve a register so that the code > that as/ld generates can use that reserved register. > > On ppc darwin, we have code to generate branch islands and then we > have an instruction that will do a short jump, if it is in range > otherwise it will jump to the other label which will be in range and > the code there (generated by the compiler) will do the above type > sequence. Statistically, this works out well, as 98% of the time, > you get the nice code with a short branch and in rare cases you get a > jump to an indirect jump. It looks like this: > > b func, func_stub > > func_stub: > la reg, func > b reg > > when then can dead code strip out the func_stubs is there are no > surviving references to them. The only problem, we have to burn a > register anyway. The _solution_ to this problem would be a link time > optimizer, it's an open project for gcc at this time. The branch > island code is a port feature. >
