Omar <gcc.omar@xxxxxxxxx> writes: > 1- How long will it take to port GCC to the new CPU. I know this is > question depend on many aspects, but just want to get a rough > estimate. Lets assume the CPU is a 16-bit RISC with a limited > instruction set, and that the person doing the port have experience > doing so. How will this estimate change with if the person doing the > port do not have any experience? I'm sure you can understand that this question is impossible to answer precisely. If the CPU has no unusual features--in my reasonably lengthy experience with doing gcc ports I have yet to see such a case--then I could do the CPU port in a few weeks. Generally an assembler and linker port is required as well, which adds another week or two. At Cygnus Solutions we used to estimate three months for a complete port: gcc, gas, ld, gdb. That was usually reasonably accurate in practice, but that was experienced and expert programmers working in an organization with many experts they could ask about any question. If you don't have any experience with gcc then it's really going to boil down to how good a programmer you are, how fast you are at absorbing all the gcc documentation, and how well you are able to distinguish between the ugliness that is gcc and the ugliness that is your port. Fortunately there are lots of existing ports to serve as examples. I should add that there are several organizations which you can hire to do the port. This will cost more money and take less time. For example, Specifix and CodeSourcery. > 2- Are there any specific instructions that will make the port easier, > and/or help with the code density? We are quite early in the > development cycle, so we can add support to instructions that will > make it easier to GCC achieve our goals. It's hard to give general answers, because there are tradeoffs. You can get higher code density with more powerful instructions, but then you need a higher gate count. Similarly variable length instruction encoding can give higher density, but that too requires more hardware. Some simple things to remember are: 1) make sure you have instructions to branch to an address in a register and call an address in a register; 2) think about the stack frame layout and make sure you can access stack variables efficiently; 3) think about register save and restore and how to make that efficient; 4) in general, the more orthogonal the instruction set, the better code you will get from gcc--resist the urge to have special purpose registers, or instructions which only work with specific registers; 5) the more registers you have, the better your code will be, but of course that affects your instruction density; 6) you can often save silicon by not having a divide instruction, though of course some programs will run slower; other than that, you will want an instruction for each basic C operator; 7) if you have floating point support at all, it's OK to make the floating point registers and the general registers disjoint sets; 8) make the register size be the same as the pointer size, or you are in for world of pain; 9) delayed branches are always tempting but will make the generated code less dense; 10) if speed matters at all, you always need a bigger instruction cache--make it as big as possible. > 3- Any other issues that you think we should consider? > 3.1- For example, I am estimating that after the initial port, we > will need to allocate 1 moth worth of effort each year to maintain > this port (mainly to up-rev to newer GCC versions). Is this a sensible > number? Yes, assuming you track the gcc mailing lists so that you are aware of the issues which are coming up. In general you've got a tradeoff of money and time. Hiring experts will cost more and take less time. Finally, sorry to be a downer, but almost all new processor companies fail. Why not just use an ARM core? Ian
