Hello mates.
I'm coding in my little spare time (big family eats time! ;) ) another makefile generator to my own use and firstly to learn to code.
I need advice in some areas but hope you are polite cos this is my first ever program in MUI, C, MorphOS/Amiga, any computer! ;)

First, why is the executable so big for such simple program? Around 165 Kb. [SOLVED]
What about the Gui design? What need to be changed?
What are the most used compiler option to be included?
What about the generated makefile?
Any suggestion is welcome to improve my coding skills. Thanks!

Gcc Prefs

Greetings,
tolkien

[ Editado por tolkien 21.11.2015 - 19:41 ]

Quote:

Did you strip it?

I think, the most important advice is to always use the -noixemul switch: By compiling and by linking too.

By the way, I like much better the hand written make systems, but it's up to you.
To learn, this project is also fine. ;)

Quote:

As Jaca correctly guessed, the executable isn't stripped. Furthermore it's compiled with -g, which adds debugging information to the executable. The debugging information alone is 94kB large.

Quote:

Quote:
Optimisations (-O2/-O3), debugging (-g), Ixemul/Libnix (-noixemul), warnings (-Wall), additonal errors (-Werror-implicit-function-declaration, for example, is quite useful)

And for going further again, the default start file that is linked at the beginning of the exectuable which is responsible for jumping to the "int main()" entry point and setting up for you some libraries (don't remember the list... sorry) and some more stuff like stdio things does about 10KB.

You can write your own startup code if you don't need all those fancy things. Krashan published recently a nice example of a custom start file on Morphos-files.net. You can get it here http://morphos-files.net/download/DemoSim

About 8KB saved. :)

Beware, if you do your own startup code, you can't use stdio stuff anymore for example! You'll have to use *only* AmigaOS API or stuff that do not rely on I/O from the standard C library (this include printf, sprintf, snprintf etc...).

Another tip to save some space is using the inline keyword of the C langage. If you're doing some MUI custom class, it is pretty usefull for the dispatcher and can save some more bytes.

If your MUI API starts to become complex with lot of similar objects kind, avoid the use of the provided macros and write (non inlined!) functions. This will seriously reduce the MUI instanciation code.

A last step to get some more juice is using a lzma compression: 400KB executable can be shrunk to less than 200KB. Beware, the version string of the executable is lost in the process and need to be appended to the end...

All in all, if you mix all those things together, you should seriously reduce the size of your binary.

Wow....thanks for all tips. Don't remember if I striped It but It's very possible I included debbuging. I have a few things to change then. You are the best mates.

Edit: I had -g enabled. Now is 71Kb!

[ Editado por tolkien 21.11.2015 - 13:00 ]

Quote:I have discussed writing custom startup code throughly in MorphOS Programmer's Handbook.

I have read the excelent Krashan's handbook.
Don't really need a custom startup but I was thinking that the program was too big for what It does.
With -s and without -g It has a decente size.

EDIT: And using dos.library instead stdio.h reduce the size to the half. Now around 30Kb.

[ Editado por tolkien 21.11.2015 - 19:45 ]

Quote:
One I use often is -ffast-math
Basically, that gives the compiler permission to change given mathematical operations around to more optimal ones, if it would "logically" produce the same exact result, but might not in practice.

For example:
a/=2.0f;
and
a*=0.5f;

should produce the same result, but due to "how floating point works", might not. It's highly likely the results are close though. Division is, of course, more expensive operation.

As for warnings, I'd also recommend -Werror, which makes all warnings errors (so they stop the build, so you can't miss them), as many of them just ARE always wrong.

If you think that's too much, there's of course stuff like -Wno-error=unused-function -Wno-error=unused-variable that disable some of the "lesser" warnings (often annoyingly triggered when you're debugging the code, and just try to temporarily disable some code)

Also, one "good practice" is to have version defined inside your program, as shown f.ex. here (seems to be some OS4 site, but I assume they haven't changed that...) for use with the version command (or icon info window).