Native code using Yagarto compiler

Archive
1

Guys,

Ive got an odd problem probably caused by me. The Yagarto compiler is giving me much bigger elf files when I use floats in my program against using doubles I expected the reverse. My native code is working as expected using doubles. My makefile is almost vanilla with the exceptions of -Os flag and a strip. Any suggestions?

Dave.

2

I think I may have a partial answer, refering to,

http://www.tinyclr.com/forum/17/3227/

I found that removing all .0 ands making the values variables my float elf file has lost 3k in size. I havent tried the changes using doubles but I will.

Dave.

3

Update,

Well after changing all the n.0 values to n and changing all the n.n/0.n values to variables my native C code elf file is now 7.8k from 11.8k. On the C code using doubles the elf file dropped from 9.6k to 9.2k using the same method, not as significant as the program using floats, but then all the incoming float values are re-cast to doubles. I started off using doubles but as they cant be passed using invokeEx I changed my program to use floats only to find I had a much bigger elf file. I dont really understand the out come of what I have done and can only assume its methods employed by the compiler??

Dave.

4

Take a look at the .map file produced by the output - it’s likely including separate libraries (not sure if that’s really the correct term here) for both floats and doubles. I had the same problem - I was using floats everywhere but some of my floating point constants were interpreted as doubles (whenever i forgot to append f) so the double libraries are included as well.

Should be right near the top of your .map file, which gets created in the same folder as the .elf file.

5

Nick,

Appending an f to my fnumbers was not an issue (maybe) for me, as I hadnt done it in the first place. What isnt clear from my last post was that I ended up passing the fp values I needed for the 0.n\n.n (I only needed a few) from the managed side, then unpacked on the RLP side. As I am lazy I cannot not be bothered to take a look at the compiler to find out why it was more effcient at producing code for fp variables than it was at producing code for fp numbers.

Dave.