RAM Usage

[NigelMills]

Hi guys,

First time on the forum, working here on a joint project with Danny Scott who's been active on the forum with Jerry Messina regarding the USB stack etc.

Making significant progress, and LOVE the compiler. Thank you for making BASIC mainstream again

So my query... Is there any output from the compiler that gives some indication of RAM usage. Something that lists variable name against location / size, and ideally whether the memory is recyclable or not. Sure I can #if stuff in and out and see the difference, but what I really need to see is when I #if the optional stuff out, what is taking up the remaining RAM space ?

I've looked through every file that's left behind by the compilation, but nothing relates to RAM other than a total RAM usage figure. I'm happy to poke around in binaries etc if it's there's anywhere you could point me to.

Thanks for your time in advance....

[David Barker]

>...Is there any output from the compiler that gives some indication of
> RAM usage. Something that lists variable name against location / size

Ensure VIEW...COMPILE AND PROGRAM OPTIONS "Generate Debugger *.cof file" is enabled. When you build your program an *.idf text file will be generated showing all this information. More information on the *.idf file format can be found here

http://www.sfcompiler.co.uk/wiki/pmwiki ... User.SFIDF

>...and ideally whether the memory is recyclable or not.

Module level variables are not recycled. Parameters, private variables and function returns are recycled. Intermediate registers (for computing complex expressions) are recycled.

> I've looked through every file that's left behind by the compilation, but nothing
> relates to RAM other than a total RAM usage figure.

see above...

[NigelMills]

David,

Thank you very much, my questions are answered

Nigel

[RangerBob]

Oh man! I've been longing for this for ages (never got round to asking about it), and it's been there all along! *Kicks Self*

Just out of interest, does anyone already have anything that can parse the IDF file and chuck out an easily human readable ram usage report?

Thanks guys!

[David Barker]

> ...and it's been there all along

Yes, since the day the compiler added COFF (the *.cof file is generated from the *.idf file)

> ...chuck out an easily human readable ram usage report

I haven't got anything like that but would really like to see something like that myself!

[NigelMills]

It's not elegant, but I sucked all the ".var PUB" lines into excel, converted the hex address to decimal, sorted them by address, then added a new column `size`, which is the address on this line minus the address on the line above. Gives you the size of each element.

" Line" 21841: .var PUB $0190 400 0 0 0 *00005 flag 3
" Line" 21842: .var PUB $0193 403 0 0 0 *00006 Engineering 7
" Line" 21843: .var PUB $019A 410 0 0 0 U08 RadioError 1
" Line" 21844: .var PUB $019B 411 0 0 0 U08 RadioWarning 1
" Line" 21845: .var PUB $019C 412 0 0 0 U08 RadioStateHold 1
" Line" 21846: .var PUB $019D 413 0 16 0 *00008 Sensors 512
" Line" 21847: .var PUB $039D 925 0 4 0 *00014 Hub_Q_Out 172

[NigelMills]

It's not elegant, but I sucked all the ".var PUB" lines into excel, converted the hex address to decimal (HEX2DEC), sorted them by address, then added a new column `size`, which is the address on this line minus the address on the line above. Gives you the size of each element.

Code: Select all

                                                                                      Size
"	Line"	21841:	.var	PUB	$0190	400	0	0	0	*00005	flag           	3
"	Line"	21842:	.var	PUB	$0193	403	0	0	0	*00006	Engineering       7
"	Line"	21843:	.var	PUB	$019A	410	0	0	0	U08		RadioError        1
"	Line"	21844:	.var	PUB	$019B	411	0	0	0	U08		RadioWarning      1
"	Line"	21845:	.var	PUB	$019C	412	0	0	0	U08		RadioStateHold    1
"	Line"	21846:	.var	PUB	$019D	413	0	16	0	*00008	Sensors         512
"	Line"	21847:	.var	PUB	$039D	925	0	4	0	*00014	Hub_Q_Out        172

You can do a similar thing for ".Var PRI" which shows you the low range memory locations and what variables co-exist at the same addresses.

NEW QUESTION.

Is there any form of `Advanced Users Guide` for the compiler, as my colleague and myself are constantly surprised buy the techniques we see used in library functions that appear not to be documented elsewhere !

My particular `want` at the moment is some explanation of how the compiler / optimizer determines the lower range (access bank) RAM usage, and what tips and tricks we can use to make the most (re)use of the RAM. Particularly for example, does sub / function placement within different modules of the code affect whether the compiler can determine if two such subs will not execute simultaneously and hence reuse RAM from temporary variables between them ? I see from my ".var PRI" listing as described above that several variables occupy the same space (most called `i`). What can I do with segmenting my code to help the compiler do it's job effectively ?

[David Barker]

> Is there any form of `Advanced Users Guide`

No, but feel free to ask on the forum if you see anything you don't understand.

> how the compiler / optimizer determines the lower range (access bank) RAM usage

Unless variables are declared as access, the compile time stack starts immediately after any system variables (normally 25 bytes worth). This is then followed by module variables.

> and what tips and tricks we can use to make the most (re)use of the RAM.

The compiler determines RAM re-use. There is very little you could do to improve this mechanism.

> Particularly for example, does sub / function placement within different modules of the code affect
> whether the compiler can determine if two such subs will not execute simultaneously and hence reuse
> RAM from temporary variables between them ? I see from my ".var PRI" listing as described above that
> several variables occupy the same space (most called `i`). What can I do with segmenting my code to
> help the compiler do it's job effectively ?

Again, there is very little you can do in this respect. The compiler will decide what subs and functions can recycle RAM.

[Jerry Messina]

You might also want to try adding

Code: Select all

#option _showvar = true

to your main module. (This option was discussed briefly here http://sfcompiler.co.uk/phpBB3/viewtopi ... t=_showvar )

Normally, after you compile if you look at the resulting .ASM file you'll see the stack frame variables listed something like this:

Code: Select all

F0_U01 EQU 26
F0_U32 EQU 26
F0_U32H EQU 27
F0_U32HH EQU 28

where the 'Fxxxx' designates shared frame vars, 'AFxxx' access frame, and 'Mxxxx' are the module-level static (unshared) vars.

With '#option _showvar = true' they get decorated with the procedure name, so you can see which routines are sharing
space on the frame. For example, here these different procedures are all using location 26 in ram:

Code: Select all

ERRNO_F0_S08 EQU 26
GET_DEV_F0_U08 EQU 26
HTYPE_F0_U08 EQU 26
QUERY_DETECTED_F0_U01 EQU 26
GIX_F0_U08 EQU 26
GET_SPEED_F0_U08 EQU 26
WAIT_FOR_POWERUP_F0_U16 EQU 26
WAIT_FOR_POWERUP_F0_U16H EQU 27
STATUS_RQS_F0_U01 EQU 26
STREAM_F0_U08 EQU 26
DATA_AVAILABLE_F0_U01 EQU 26
GETCH_F0_U08 EQU 26
HASH_F0_U16 EQU 26
HASH_F0_U16H EQU 27
PREC_F0_U08 EQU 26

There's all sorts of great nuggets of info here on the forum. It's well worth taking an afternoon or two and just read through the entire thing.