Hi guys, Here are some very rough thoughts... First, for now, it's just about parsing compiler output and easing compiler/repository/sample selection... Still, there are interesting things to dig. My goal is to try to replace these "feelings" with something measurable, tracable, thus improvable (thus CHANGELOG'able :))
I tried to track metrics for ADC libraries. First issue: it's hard to find a
sample available since the beginning...
I proceeded like this:
- download all jallib-pack, starting from 0.2.0 (0.1.0 has no compiler
inside)
- select a sample, and generate command lines for it, amongst different
packs.
$ # for the record...
$ s=16f88_adc_lowres.jal
$ for i in `ls -d jallib-pack-*/`; do echo
$i/compiler/jalv2,$i/lib:$i/sample/$s; done > /tmp/zebla_$s
$ jallib monitor `cat /tmp/zebla_$s`
(only 0.2.0, 0.5.0 and 0.6.0 are considered, as there's no significant
differences for others)
jallib-pack-0.2.0///sample/16f88_adc_lowres.jal
jallib-pack-0.5.0///sample/16f88_adc_lowres.jal
jallib-pack-0.6.0///sample/16f88_adc_lowres.jal
compiler_path jallib-pack-0.2.0///compiler/jalv2
jallib-pack-0.5.0///compiler/jalv2 jallib-pack-0.6.0///compiler/jalv2
compiler_version jal 2.4i (compiled Dec 1 2008) jal 2.4m
(compiled Dec 26 2009) jal 2.4n (compiled Jun 2 2010)
tokens 1084
940 1051
chars 73053
189416 212906
lines 1929
5121 5729
files 7
11 11
code_area_used 193
798 789
code_area_avail 4096
4096 4096
data_area_used 13
51 53
data_area_avail 352
352 352
soft_stack_avail 8
8 8
soft_stack_used 3
4 3
soft_stack_avail 8
8 8
So, indeed, code is roughly x 4 and data is x 2. Now the real issue: what
did you gain with this x 4? I'd say proper configuration, for independent
pins. The most important cost is due to the generation of two procedure,
set_analog_pin() and set_digital_pin(), taking a channel number to
configure, dynamically. Maybe this could be simplefied using some sort of
preprocessor, keeping these procedures for "pure" dynamic
configuration. Notice at least stack is lowered to initial value, 3 in
release 0.6.0 :)
Edit: current jallib trunk is saving ~100 bytes with this sample ! Also
notice 2.4o-beta eats 10 bytes...
jallib-pack-0.6.0/sample/16f88_adc_lowres.jal
jallib/sample/16f88_adc_lowres.jal jallib/sample/16f88_adc_lowres.jal
compiler_path jallib-pack-0.6.0/compiler/jalv2
jallib/compiler/jalv24o-beta jallib/compiler/jalv24n
compiler_version jal 2.4n (compiled Jun 2 2010) jal 2.4o
(compiled Mar 6 2011) jal 2.4n (compiled Jun 2 2010)
tokens 1051
1073 1073
chars 212906
235203 235203
lines 5729
6257 6257
files 11
12 12
code_area_used 789
694 684
code_area_avail 4096
4096 4096
data_area_used 53
51 50
data_area_avail 352
352 352
soft_stack_avail 8
8 8
soft_stack_used 3
3 3
soft_stack_avail 8
8 8
Considering a ADC dependent pins sample, using 16f877 and adc_hardware for
2.4i/0.2.0 (attached), and existing samples when version is greater,
differences are less important:
16f877_adc_hardware.jal
jallib-pack-0.5.0///sample/16f877_adc.jal
jallib-pack-0.6.0///sample/16f877_adc.jal
compiler_path jallib-pack-0.2.0///compiler/jalv2
jallib-pack-0.5.0///compiler/jalv2 jallib-pack-0.6.0///compiler/jalv2
compiler_version jal 2.4i (compiled Dec 1 2008) jal 2.4m
(compiled Dec 26 2009) jal 2.4n (compiled Jun 2 2010)
tokens 1135
922 1033
chars 87099
197315 221356
lines 2410
5402 6036
files 8
11 11
code_area_used 638
772 791
code_area_avail 8192
8192 8192
data_area_used 52
52 53
data_area_avail 352
352 352
soft_stack_avail 8
8 8
soft_stack_used 3
4 3
soft_stack_avail 8
8 8
Other interesting samples are those using serial, print, delay, quite
representative (s=16f648a_serial_print.jal).
jallib-pack-0.2.0///sample/16f648a_serial_print.jal
jallib-pack-0.3.0///sample/16f648a_serial_print.jal
jallib-pack-0.6.0///sample/16f648a_serial_print.jal
compiler_path jallib-pack-0.2.0///compiler/jalv2
jallib-pack-0.3.0///compiler/jalv2 jallib-pack-0.6.0///compiler/jalv2
compiler_version jal 2.4i (compiled Dec 1 2008) jal 2.4k
(compiled May 8 2009) jal 2.4n (compiled Jun 2 2010)
tokens 1249
1570 1812
chars 75897
79184 94270
lines 2190
2321 2662
files 7
8 8
code_area_used 1758
1866 1868
code_area_avail 4096
4096 4096
data_area_used 90
90 90
data_area_avail 240
240 240
soft_stack_avail 8
8 8
soft_stack_used 3
3 3
soft_stack_avail 8
8 8
100 bytes were "eaten" since release 0.3.0. "diff" shows there's no
differences between 0.2.0 and 0.3.0 regarding the sample code itself.
Diff'ing print.jal shows very few differences, but still, in particular,
some logic related to printing prefix or not. Switching this logic to const
gives ~100 bytes again:
var bit print_prefix = false
to:
const bit print_prefix = false
jallib-pack-0.2.0///sample/16f648a_serial_print.jal
jallib-pack-0.3.0///sample/16f648a_serial_print.jal
compiler_path jallib-pack-0.2.0///compiler/jalv2
jallib-pack-0.3.0///compiler/jalv2
compiler_version jal 2.4i (compiled Dec 1 2008) jal 2.4k
(compiled May 8 2009)
tokens 1249
1570
chars 75897
79186
lines 2190
2321
files 7
8
code_area_used 1758
1768
code_area_avail 4096
4096
data_area_used 90
90
data_area_avail 240
240
soft_stack_avail 8
8
soft_stack_used 3
3
soft_stack_avail 8
8
Notice this feature isn't used in considered sample, nor it is in any sample
AFAIK (and it's not optimized). Obviously it must be used somewhere, still,
switching to an "if defined" selection could help saving few bucks (errr...
bytes):
if !defined(PRINT_PREFIX) then
const bit PRINT_PREFIX = false -- defaulting
end if
If, in user code, you do want prefix, ever:
const PRINT_PREFIX = true
include print
and, it you want it dynamic
var bit print_prefix = true
include print
Differences between the two latter (being able to switch during runtime) are
14 bytes.
If you think you do have a highly representative sample, let me know !
FWIW (IW, isn't it ?)
Cheers,
Seb
2011/3/13 mattschinkel <[email protected]>
> > So thank you, Seb! It is good to have data that indicate if - and how
> > much - resource use is increased. It does not say everything, but is
> > definitely relevant.
>
> Of course, I do agree with all of this. Thanks Seb!
>
> Matt.
>
>
--
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.
16f877_adc_hardware.jal
Description: Binary data
