Hi, As for print.jal, if code usage is far lesser than current one, I think it's worth updating the library despiste some loss of readability. Comments are here to help. I've observed using print.jal is quite a consuming lib.
Now back on the main topic: lib usability vs. performance. I think what we currently lack is some kind of metrics. It's hard to tell whether using a lib adds value or not. This new adc vs. old adc libs is a good example: old lib only supports very few chips while new lib handles many more chips, including a new way to select ADC pins independently (when possible) and also a way to do this dynamically so a program can adjust ADC setup as needed during runtime. What did we loose and what did we gain ? Is it worth it ? And, most importantly, how does evolve code usage while lib is being updated ? We sometime have the "surprise" to discover some samples don't compile anymore. And compiler is also involved in some cases (last jalv24o for instance). Maybe we could start to log, systematically, code usage, memory, stack, for each sample, and see how they increase or decrease. The problem is sometime, due to compiler update *and* usage of a new feature (eg. record), things wouldn't be comparable anymore. I had thought, long time ago, about adding special @tags in unittests to check these figures. Another way to have metrics would be to track word usage for a given function call. PICShell might be helpful, since it can step over code. Or, maybe we should just track some compiler functionalities (kind of primitives used to build more complex code like our libs): division, mutliplication, special optimisation cases, pragma inline, passing vars, etc... For instance, last compiler compile PDFUSB bootloader but size goes beyond allowed 2048 bytes. Why ? Where does this come from ? Some random thoughts... Please fill in the gaps :) Cheers, Seb 2011/1/6 Oliver Seitz <[email protected]> > > > if the dwords procedure isn't called, it's not > > compiled. > > > > That's true. But the print library core is a procedure > > capable of > > handling dwords. If you use two different decimal routines > > (e.g. byte > > and sword), this is efficient. If you use only one, the > > design is > > inefficient. > > Ok, it's been a while since I had a look at the print.jal code. I found it > very readable, the only thing I remember that did not fully meet my taste > were lots of divisions. > > > As to my previous statement: the bottom line is jallib > > (like many > > libraries) aim to be universal and that comes at a price, > > which in > > most cases is code size. There is no point in just > > criticize code > > size. You one thinks code size (or stack usage) could be > > reduced > > without reducing functionality, please, please, show how. > > Well, sometimes it is possible. You could replace the print.jal-procedures > with procedures of the "looped subtraction"-type I sketched in this thread. > You would win in code size and execution time, probably even in RAM usage. > But the cost would be to change a beautifully readable code into an awful > mud of strange loops. Adding the "remove leading zeroes" function would make > things worse. The "limit to (n) digits" would turn it into an unreadable > mess. > > Let's leave such efficient but ugly constructs to the user who really needs > it. > > Greets, > Kiste > > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<jallib%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/jallib?hl=en. > > -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
