Thank you guys, This is what I wanted to talk about. I can imagine that readability in code library is good for developers but...
>From the user perspective, the code size is the most important thing ever. Then it comes performance. Of course, it also matter the language features and how rich is the library (the winner is the package which offers also USB and SD card). They only need to learn how to use the libraries along with learning the language. I advertise everywhere for JAL and Jallib speaking about their performance, easy of use and rich libraries... And we have things which work better than on other packages - even Xiaofan (http://mcuee.blogspot.com/) was amazed by Serial USB - how easy it was to get it up and running with JAL and Jallib (and this is stated on Microchip forum if I remember right - @Watty can confirm this). Let's have also small code size, as much as possible. Best regards, Vasi P.S. f found on a Philippines forum Petit FatFS translated for Hi- Tech PICC18 9.64 and used on an 18F2550 - A bitmap slider and a WAV player. Can anyone translate it to JAL? I will also try ut you know I'm not the right person for this. http://www.electronicslab.ph/forum/index.php?topic=17055.0 P.P.S: Last version of PMP is great, it comes with a lot of language features not seen yet in JAL. P.P.P.S. Hi Joep, I modified your library only because I was able to understand it and, for 12F675 I needed only one slot and was logic to cripple it to fit my logger application in it. Your library is good as it is now and very useful - I even translated it for PMP as general library which works with all pics. So, no offense about your code. https://sites.google.com/site/funlw65/tutorials/picmicropascal-projects/blinking-d14-and-boot-leds-using-non-blocking-delays Many times I don't know how to speak.... On Jan 7, 3:30 pm, Oliver Seitz <[email protected]> wrote: > --- Sebastien Lelong : > 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. > > I thought about completely rewriting print.jal, but having tried a little > example like > > var byte dummy > var dword counter > > for 4_294_967_295 using counter loop > > print_dword_dec(dummy,counter) > > end loop > > I found out to my big surprise that current print.jal *does* generate small > code. (Compiler=2.4n) On a 16f722 it is Code 302 Data 44 Stack 2. The "looped > subtracion" variant takes Code 374 Data 27 Stack 3. It could use Stack 2 with > about Code 400. > > Another point could be execution time. print.jal does up to 20 divisions of > 32bit numbers for printing dwords. And, the advantage in code size is gone > when only printing words. A similar program (word instead of dword) compiles > to this: > > current Code 283 Data 40 Stack 2 > new Code 186 Data 14 Stack 2 > > 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. > > 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. > > But in general it would be of course a great thing to have some information > not only about the benefits of a lib, but also about the cost in memory and > such. > > 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]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
