Hi Kiste, Thanks for your investigations. Maybe it's too late, but could you provide your sample programs so we share the same testing code ?
2011/1/7 Oliver Seitz <[email protected]> > > > More things to think about: If you're printing dwords with current > print.jal, you'll get the word, byte and even all the signed types output > almost for free. The new version adds code for each additional type. If your > program already does use 32bit divisions, the advantage in code size is > negative with the new version. > > > Perhaps the solution would be a new lib, like print_simple, that is to be > used for small projects that run on little devices. It could e.g. only > output (s)byte and (s)word. When only outputting bytes, the difference is > impressive: > > > > current Code 272 Data 38 Stack 2 > > new Code 92 Data 11 Stack 2 > > > That is less than one third for both code and data usage. I'd call that an > improvement. > Maybe print_(s)word_dec() procedures could use current _print_universal_dec -- handles dword -- whereas other print_ procedures could use another engine. Conditional compilation would help select one or the other. Not sure if it makes sense though... > > > > 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. > > > > Very difficult... As mentioned, there is not only used memory, but also > execution time which can not be determined by the compiler. And, to stay > with the print.jal example, the code usage of the lib could be masked if a > user program already uses 32bit divisions. > Indeed, it would be hard to consider every possibilities. Still there should be something we could do, as a first step. As I previously said, we could try to monitor compiler performances by identifying some primitive features: if/then/else, case of, division, modulo, pragma inline and optimized proc calls. Then, on the lib side, we could monitor some basic functionalities: blink a led + maybe some very basic peripheral tests (serial echo, adc read,...). Monitored metrics could: program usage, ram usage, stack, these are given by compiler outputs. PICShell can simulate some PICs, I'm using it to perform some unit tests. Of course, some code can't be tested with this (serial echo code will contain some blocking "while !value loop end loop"). But maybe there's something to dig here too ? Cheers, Seb -- 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.
