Anyway, I wanted to refer to the ability to address complex projects using structures and pointers... and the most accessible language for JAL users is Pascal. JAL have a very good optimization and is the best for small microcontrollers - still unparalleled here.
On May 9, 6:52 pm, vasile surducan <[email protected]> wrote: > On Mon, May 9, 2011 at 5:41 AM, funlw65(Vasi) <[email protected]> wrote: > > Sorry, I meant Pic Micro Pascal. > > Do you have a comparative project in which you've compiled similar (as > functionality) source files, in jalV2 and PMP? > Maybe it worth to see what is about this Micro Pascal... > > thx, > Vasile > > > > > > > > > > > On May 9, 3:23 pm, Sebastien Lelong <[email protected]> > > wrote: > > > What do you mean, PMP ? > > > > Seb > > > > 2011/5/9 funlw65(Vasi) <[email protected]> > > > > > Can you give to PMP a try? The next version will be awesome! > > > > > Vasi > > > > > On May 9, 12:55 pm, Sebastien Lelong <[email protected]> > > > > wrote: > > > > > Hi guys, > > > > > > Minix is a big lib, minix can't compile without -no-variable-reuse. > > Since > > > > > compiler can't handle this amount of code (it takes hours to compile, > > > > maybe > > > > > days, actually I didn't wait for complete compilation, it's just too > > > > > long...), I tried to reuse variable myself, within the code. > > Following is > > > > a > > > > > blinded example with fat32.jal library, another big one. > > > > > > First, results before optimization: > > > > > > jallib compile -no-variable-reuse sample/18f4550_fat32_sd_card.jal > > > > > jal 2.4o (compiled May 8 2011) > > > > > generating p-code > > > > > 6309 tokens, 357042 chars; 8703 lines; 16 files > > > > > generating PIC code pass 1 > > > > > generating PIC code pass 2 > > > > > writing result > > > > > Code area: 19364 of 32768 used (bytes) > > > > > Data area: 1542 of 1952 used > > > > > Software stack available: 410 bytes > > > > > Hardware stack depth 10 of 31 > > > > > 0 errors, 0 warnings > > > > > > Now, let's dig one procedure, "randomly" picked: > > fat32_file_entry_data. > > > > It > > > > > declares, within its body, the following variables (I just read it, > > > > > extracting "var ..."). > > > > > > var byte sector_after_entry_location > > > > > var word sector_entry_number > > > > > var byte char_pos = 0 > > > > > var byte number_of_entries > > > > > var byte step3 > > > > > var word sector_entry_number2 = sector_entry_number * 32 > > > > > var byte long_name_step = FAT32_FILE_NAME_SIZE - 13 > > > > > var byte sector_step = 0 > > > > > var byte first_char > > > > > var byte step3 > > > > > var byte step > > > > > var byte _cluster_address[4] at fat32_file_cluster_address > > > > > var byte _file_size[4] at fat32_file_size > > > > > var byte _cluster_address[4] at fat32_file_cluster_address > > > > > > These variables are declared either at body's root, or within "for", > > "if" > > > > > block. Some can't be reuse, but, *maybe*, some can actually be > > reused, > > > > > because their content is only used within a limited, predefined > > timeline. > > > > > Let's first move all these declaration at the top of body. Compiling > > > > reveals > > > > > the following duplicates: step3, _cluster_address, and _file_size. > > > > Removing > > > > > duplicates gives the following output: > > > > > > Code area: 19424 of 32768 used (bytes) > > > > > Data area: 1540 of 1952 used > > > > > > Why program memory grew that way ?? I can't explain... Let's > > continue. > > > > step > > > > > and step3 are using within for loops, not at the same time. We can > > remove > > > > > step3 and use step instead: > > > > > > Code area: 19530 of 32768 used (bytes) > > > > > Data area: 1539 of 1952 used > > > > > > 19530 bytes !!! Why ? One byte RAM saved... > > > > > (is that about banking ?) > > > > > > Oh well... I rewrote that mail 10 times as I actually discovered the > > > > results > > > > > :) I'm stopping here, and starting to understand why my Minix lib is > > so > > > > big. > > > > > I indeed used a lot of "alias" in order to try to reuse variables > > > > > "manually", and save RAM, and it does but the amazingly growing > > number of > > > > > program bytes is quite scary... > > > > > > 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. > > > > -- > > > Sébastien Lelonghttp://www.sirloon.nethttp://sirbot.org > > > -- > > 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. -- 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.
