Am 02.08.2013 07:18, schrieb Mark McDougall: > Hi, > > I've had a bit of a look through the archives but the interface makes it > very difficult to peruse posts over any large length of time... > > I'm looking to assist in a project to develop a C-compiler for a custom > soft-core RISC processor. The processor itself has a very small > instruction set, but is designed to run at high clock speeds and is > scalable in terms of data width. > > I'm currently in the process of determining the most suitable compiler > stack for the task, and from what I have learned in the last few hours it > seems to come down to SDCC vs. CLANG/LLVM. > > I've used the 8051 (Cypress EZUSB) and Z80 ports of SDCC in the past, but > of course have never developed a back-end for it. IIUC there's absolutely > no documentation to assist in the process, and it's simply a case of "Use > The Source, Luke"! That's not necessarily a show-stopper for me, but in > this respect does make LLVM look more attractive. > > Anyway, I notice that an STM8 port was added to the trunk recently. May I > inquire as to how much effort (weeks?) that port required? I understand > it's not a trivial task to add a back-end, and it involves developing > assemblers and simulators as well, but I don't really have a feel for how > much overall effort it requires. Obviously it depends to a degree on the > target CPU, but if I knew how long the STM8 port took, I might be able to > extrapolate some ball-park figure for this custom RISC processor!?! > > So any statistics on the STM8 port would be greatly appreciated! > > Regards, >
To decide if sdcc would be a good option more information is necessary. Is there any public information on the architecture of this custom processor? In general, developing a backend isn't hard: Most of it is the code generation, which lives in gen.c. There is some general glue code, and a little bit of custzomization of the register allocator, but that's it on the sdcc side. Of course you also need an assembler and linker, but you would with any compiler. Also, this is isn't just a matter of putting so-and-so much time into a port and then it is there. Sure there is a point at which most of the regression tests pass, and the port can be merged into trunk. But there are always bugy to fix, and there is potential for optimization. I consider the stm8 port an ongoing effort (as any other port). Have a look at this: http://sdcc.sourceforge.net/mediawiki/index.php/Stm8_code_size Revision #8537 already was quite useable for small projects. But there still were some bugs, and as you see, the code size was much worse, compared to a leading competing compiler. And the code size has been brought down a lot since. I started thinking about an stm8 port last year, after looking at the architecture and liking it. I started working on it at the beginning of this year. No one really worked on the port full-time. Valentin mostly worked on the assembler and linker on weekends. You might want to have a look at the number of lines in src/stm8/gen.c and estimate the effort from there (the other big files in src/stm8 are mostly just copied from other ports with a few small modifications). Philipp ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
