Demo makefiles

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Demo makefiles

Post by D3thAdd3r »

I noticed most games in the trunk are outputting something like this for size:

Code: Select all

===================================
Building demo: demos/Uzeamp/default
===================================
make -C demos/Uzeamp/default  UZEBIN_DIR=/home/lee/uzebox.git/branches/streaming-music/bin/

Uzeamp.elf  :
section                     size      addr
.data                         14   8388864
.text                      27294         0
.bss                        3296   8388878
.comment                      17         0
.note.gnu.avr.deviceinfo      60         0
.debug_aranges              1064         0
.debug_info                18341         0
.debug_abbrev               3591         0
.debug_line                13629         0
.debug_frame                2792         0
.debug_str                  4376         0
.debug_loc                 16498         0
.debug_ranges               1048         0
Total                      92020
Now I will admit that I do not fully understand all the data in that format, and perhaps there is something inside those unknowns for me, where I don't see some obvious benefit. But I am willing to guess that more commonly, this is a more useful output for most people:

Code: Select all

AVR Memory Usage
----------------
Device: atmega644

Program:   38722 bytes (59.1% Full)
(.text + .data + .bootloader)

Data:       4006 bytes (97.8% Full)
(.data + .bss + .noinit)
It seems the vast majority of demos currently use the first format. Essentially the only difference is in the makefile, changing this:

Code: Select all

size: ${TARGET}
	@echo
@avr-size ${AVRSIZEFLAGS}
to this:

Code: Select all

size: ${TARGET}
	@echo
	@avr-size -C --mcu=${MCU} ${TARGET}
It is just more concise, and directly the information I usually find myself needing as games inevitably start running to the flash and ram limit. Just curious if someone knows reasons the first format is better, or feel the second format is more concise and useful.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Demo makefiles

Post by nicksen782 »

I like the second format. Actually, I think that Makefiles in general are voodoo to many. The first example is likely so often used because it was probably used by the first Makefile that we all copied when we started. What does the Makefile for Megatris and the SuperMarioDemo look like?

Mine is like some examples out there but with a few changes. Such as an entry for sdBase.o

Example:

Code: Select all

OBJECTS +=  sdBase.o
sdBase.o: $(KERNEL_DIR)/sdBase.S
	$(CC) $(INCLUDES) $(ASMFLAGS) -c  $<
Here is what I do for size:

Code: Select all

	@ echo "" > lastbuild.txt
	@ avr-nm --size-sort -t d -S -s --line-numbers -f sysv ${GAME}.elf
	@ echo >> lastbuild.txt
	@ echo `date` >> lastbuild.txt
	@ echo GAME: ${GAME} >> lastbuild.txt
	@ avr-size ${AVRSIZEFLAGS} >> lastbuild.txt
	@ cat lastbuild.txt
That "avr-nm" part will show you what is using .text and .bss (sizes of functions and arrays and such) which helps to figure out functions that you could likely see benefit in optimizing for size.

The lastbuild.txt ends up looking something like this:

Code: Select all

Sat Aug 12 17:18:22 EDT 2017
GAME: BubbleBobble
AVR Memory Usage
----------------
Device: atmega644

Program:    5068 bytes (7.7% Full)
(.text + .data + .bootloader)

Data:       3177 bytes (77.6% Full)
(.data + .bss + .noinit)
Additionally my Makefile has a couple commands for copying files (easier to use with the online emulator.)

There are great guides on the Internet concerning Makefiles. Still a bit of voodoo ;)
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Demo makefiles

Post by D3thAdd3r »

nicksen782 wrote:That "avr-nm" part will show you what is using .text and .bss (sizes of functions and arrays and such) which helps to figure out functions that you could likely see benefit in optimizing for size.
Ah very nice, that is actually very handy! Will definitely have to use that going forward, as I do generally experiment towards the end to find the smallest design for each function. My normal method was working on 1 function at a time and recompiling to check the difference, but it would be very nice just to see a quick overview of everything, which would dictate where to spend the most optimization time.
nicksen782 wrote:What does the Makefile for Megatris and the SuperMarioDemo look like?
Looks like they are also the cryptic version, almost everything is.

I guess all the current standard does is repeat what is already in the (GAME).lss, like:

Code: Select all

//first lines of (GAME).lss
ZoomingSecretary.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000926  00800100  0000a8c0  0000aa00  2**8
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         0000a8c0  00000000  00000000  00000100  2**8
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .bss          000002a2  00800a26  00800a26  0000b326  2**1
                  ALLOC
  3 .comment      00000011  00000000  00000000  0000b326  2**0
                  CONTENTS, READONLY
  4 .note.gnu.avr.deviceinfo 0000003c  00000000  00000000  0000b338  2**2
                  CONTENTS, READONLY
  5 .debug_aranges 00000580  00000000  00000000  0000b378  2**3
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_info   00007cd5  00000000  00000000  0000b8f8  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_abbrev 00000ee7  00000000  00000000  000135cd  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_line   000056f8  00000000  00000000  000144b4  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_frame  00000d2c  00000000  00000000  00019bac  2**2
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    000020b2  00000000  00000000  0001a8d8  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_loc    00005e02  00000000  00000000  0001c98a  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_ranges 00000740  00000000  00000000  00022790  2**3
                  CONTENTS, READONLY, DEBUGGING
Which I could understand maybe when you are doing radical stuff like Jubatian and Cunning do, but even then I wonder how often that is more important that just plain old flash and ram usage. At least if someone wanted to work on an existing demo, they are probably watching as their flash and ram usage increase with more features.

I guess it is non-critical to update all the demos to show this(though I think it would be worth doing). Going forward I guess I will do the latter method I mentioned, or what nicksen782 has just mentioned. I have to think the only reason the current method is all over the place, is like you say just copying an existing makefile.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Demo makefiles

Post by uze6666 »

I know this is old news sorry, I'm catching up again! :?

So, this is generated on what build chain? Atmel Studios? I have WinAvr492 and I don't see this.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Demo makefiles

Post by D3thAdd3r »

This happens on the couple Linux machines I have with standard gcc setup. I think Jubation, Artcfox, nicksen782 and others will see the same thing if someone can confirm. I don't recall if this happened with MinGW on Windows. I have to figure out how to build on OSX to see if it is different there, but I rarely use anything but Ubuntu/Debian for a while.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Demo makefiles

Post by nicksen782 »

My build environment is on Ubuntu and I use avr-gcc. Actually, I've never used AVR Studio. I use mostly web-based tools that I make myself. Either I'm stuborn or I don't know any better. :roll:

The compile produces files such as (GAME).lss but I usually delete them afterwards within my Makefile. Occasionally I've commented that deletion code out so that I can see those files.

Long ago I used to do all this on Windows with Notepad++ and a batch file with a menu system. I have a web-based system instead which is far more sane especially since I have an Ubuntu Linux instance online that I can utilize for compiling and using the online emulator.

Does this help?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Demo makefiles

Post by uze6666 »

Well, I can see that:

Code: Select all

size: ${TARGET}
	@echo
	@avr-size -C --mcu=${MCU} ${TARGET}
Still gives the same results on windows/WinAVR. So if other confirms it works other plartform I can update all the demos.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Demo makefiles

Post by Jubatian »

It works here as you describe it, however for FoaD I found the new output less useful:

Code: Select all

AVR Memory Usage
----------------
Device: atmega644

Program:   31272 bytes (47.7% Full)
(.text + .data + .bootloader)

Data:        512 bytes (12.5% Full)
(.data + .bss + .noinit)
While the original parameters give this:

Code: Select all

_bin_/foad.elf  :
section                      size      addr
.data                           0   8388864
.res                        25828     31488
.text                       31272         0
.bss                          512   8388864
.comment                       17         0
.note.gnu.avr.deviceinfo       60         0
.debug_aranges               2624         0
.debug_info                 44817         0
.debug_abbrev               12545         0
.debug_line                 60631         0
.debug_frame                 4508         0
.debug_str                   5904         0
.debug_loc                  40196         0
.debug_ranges                1784         0
Total                      230698
Actually there is only one particular information which is missing from the new output. In FoaD the resources go into a .res section at a fixed address (I had to go this path as I am doing maths with addresses which the linker can't cope with, so I need data at fixed addresses in this game). So with the new output I don't see how large is the .res section. The .bss section might look a bit odd, how I am only using 512 bytes, but there it is also because of fixed RAM layout. That 512 bytes are free for linker allocated variables and it is totally full (so truly I have exactly 0 bytes of RAM free in this game). Of course this is totally invisible to the linker no matter what (unless I could somehow tell it that the .bss section's max size is 512).

Of course this is quite nonstandard usage, so I guess it could be changed to the new output for easier understanding for those who aren't doing such complex things.
Post Reply