Hi, >> I then looked in sdcc/devices/lib/_ulong2fs.c, which also uses the >> bottom version. Why do different devices have copies of (almost) the >> same code in various places? >> Shouldn't they all use the same to avoid situations like this? > > don't know for this case. In general, we have one version of each > libary function implemented in C, that should work for all ports. Then > some ports have specific versions , typically in asm to be able to use > some special instruction. there also are a few cases of different > versions due to differences in speed. Though I really wonder why anyone > should care much for speed on the PIC ports, fixing them seems a much > more important thing to do to me (but I don't know much about PICs, and > only very rarely work on that port).
We all agree on the fact that a single-source would probably be beneficial. In support of that, the libraries for the PICs are nearly completely C, no asm used for optimization. The problem (well, one of the problems, really :-[) with the PIC libraries is that they intentionally diverged from SDCCs standard library (before "my" time already, though I did nothing to revert that). When the library started to diverge, source files were copied from devices/lib to the pic specific directories in order not to pollute the common libraries (I assume). In doing so, the build system would then have to be set-up in a way to gather source files from various (i.e., two) places, including some ../ location, which (to me, and seemingly to the original author) looked bad: not self-contained, hard to split from the rest of the library (as if that was ever going to happen), and generally possibly tricky when considering out-of-source builds as well. I am not saying that I like the way things are right now, volunteers to clean it up would be welcome though I would not have much time to review and/or apply their efforts. But as things are, this is probably not going to change any time soon. Regarding regression tests: All other ports participate in regular regression tests, and they are highly unlikely to produce bad code for such fundamental operations. Both PIC ports, however, still need more love to be able to compile (not yet talking about passing) them. Philipp has done some investigations and postulated that there seems to be not that much missing in (I think) the PIC16 (18fxxx devices) backend to get there, but again: Nobody is actively working on getting the PIC ports up to speed. I'll be happy to apply your fix if and when I can verify the bug and solution using a simulator such as gpsim (*winkwink* no need for a real device here, but you may need to change the target device to one supported by gpsim). Thanks to the OP for the report and tracking the problem down to its source. Raphael ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
