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.

Reply via email to