One of the apparent advantages of using the "newlib" shared library instead of "clib2" was a smaller binary file size but that advantage seems to be defeated by the padding.
Nope your still sharing most of your code with the other apps using it. And the most important advantage is bug fixes to the lib immediatly benefit the using utilising apps.
Not when linking with clib2, then there us a copy of the lib inside every executable. No sharing, unless specifically using the shared-object version of clib which isn't the default when using clib2 AFAIK.
And -O2 does optimize for size as well, or rather, the size shrinks as a result of removal of unnecessary instructions etc. A program rarely become larger with -O2 than without any optimization, but the contrary, usually shrinks 10-30%.
Anyhow I would also really like to know WHY this padding was made. I mean, it cannot have anything to do with FPU alignment because that is only relevant for each individual FPU<->memory access, not where a complete code block is located. FPU padding was probably also mode but this isn't it but something else IMO.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Optimizing with -O2 is still useful. Even if a section (data section I suppose) is padded up to 64kb, that does not mean the code will execute slower. It is just a waste of room, no more. And the data cache won't be impacted because the additionnal padding zone will not be used.
But I just still do not understand why this 64kb alignment is required in the binary file ...
Quote: Quote: One of the apparent advantages of using the "newlib" shared library instead of "clib2" was a smaller binary file size but that advantage seems to be defeated by the padding.
Nope your still sharing most of your code with the other apps using it. And the most important advantage is bug fixes to the lib immediatly benefit the using utilising apps.
Not when linking with clib2, then there us a copy of the lib inside every executable. No sharing, unless specifically using the shared-object version of clib which isn't the default when using clib2 AFAIK.
You should read what I wrote and what I was answering. He stated that the advantage of newlib was lost, I said it wasn't as you are still sharing most of the clibrary code. (newlib is alot bigger than 64k). I didn't mention or imply the same was true of clib2. Clib2 has different advantages (access to amigados level being one important one for a few things I've worked on). I dont thik there is a shared object version of clib2, libc.so is part of newlib.
Quote:
And -O2 does optimize for size as well, or rather, the size shrinks as a result of removal of unnecessary instructions etc. A program rarely become larger with -O2 than without any optimization, but the contrary, usually shrinks 10-30%.
Okay perhaps there is some size loss, depends a lot on the type of program (how much unrolling etc takes place) but it's optimising for performance in the first instance, any size reduction is a side effect, and some parts of the code will grow,
orgin wrote: Perhaps it's time to add the ability to zlib executables ;o)
Please no, I'm worried about that (apparent) unneeded padding in executables, but we are not 1990 anymore HD are cheap and I really prefer huge binaries processed with speed than small compressed binaries processed slowly (especially when you think about the fact that we don't have (currently) the fastest PPC CPUs...). I prefer small unpadded binaries of course.
PS: when I tried recompiling some old projects with the current SDK I did not get padding with zeros but with '0xABADCAFE' ?!?
About the optimization; yes speed is the first concern, but considering how crappy and full of unnecessary instructions unoptimized gcc output is it isn't too strange that it shrings rather than blows up. Besides, -O3 make sometimes considerably larger executables than -O2 because it performs much more inlining and unrolling than -O2.
I did a comparison between Amiga-E code (EC doesn't have an optimizer at all and often doesn't generate the most optimal code) and gcc code of the same program using no optimization and with -O3 and this was the result:
An algorithm took about 7s for E code, 10s for unoptimized C code and 5.5s for -O3 C code.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Seriously, why is everybody hooked up on a few kilobytes of extra space? I don't quite get that, it's not like you are trying to fit things on a floppy disk.
Yeah, the new bintuils align all segments to 64 KB boundaries. Since ELF files are written with mmap() in mind, this means the extra padding is added to the file itself. Not a big deal, as soon as the segments fill up the space requirement will grow less, and in big binaries it will not make a significant difference.
If someone can't live with it, you can grab the binutils source code and fix it; might even be fixable with a linker script, without actually recompiling the binary. But seriously, why bother?
Just my two cents on the topic.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
@Rogue Thanks for explaining how the 64KB padding comes about. Seems it is nothing to do with the Sam440 fix, but rather due to using a newer version of binutils.
I think as long as we know the reason, there will be very few complaints. It was just that thinking the padding was due to Sam440 fix, it seemed totally unnecessary.
I just wanted to understand the reason (it seems that my suggestion about 64kb page size is right, due to the implementation with mmap in mind, as Rogue said).
I don't care about few dozens of additionnal kilobytes in executable. Tiny programs will have a size of 100kb instead of 20 or 40 kb, there is no problem. No complaint to address.
I just wanted to understand the reason (it seems that my suggestion about 64kb page size is right, due to the implementation with mmap in mind, as Rogue said).
If the fixed page size was added with mmap in mind, that might imply that it is related to the SOBJ fixes mentioned in the new SDK release announcement. If that's the case then it might be nice to have an ld script (SDK/gcc/ppc-amigaos/lib/ldscripts) that would be used if an option (like -small or something) is used on the calling command line and skip the page padding. Quote:
I don't care about few dozens of additionnal kilobytes in executable. Tiny programs will have a size of 100kb instead of 20 or 40 kb, there is no problem. No complaint to address.
Effeciency certainly doesn't hurt. Padding all programs with unnecessary data (zeros) will result in virtual memory activation (disk/memory swapping) sooner than might otherwise be necessary and slow down your computer. I can't help but think that scripts which call a series of 5k commands instead of a series of 68k commands would be faster and more effecient.
Based on information presented in this topic, I think I'll continue to compile small commands with the old OS4 SDK since there doesn't appear to be any reason not to do so.
If the fixed page size was added with mmap in mind, that might imply that it is related to the SOBJ fixes mentioned in the new SDK release announcement. If that's the case then it might be nice to have an ld script (SDK/gcc/ppc-amigaos/lib/ldscripts) that would be used if an option (like -small or something) is used on the calling command line and skip the page padding.
You're wrong because there are no mmap functions in AmigaOS 4.x. If the change was made with mmap in mind then it was definitely not made with AmigaOS 4.x in mind.
You're wrong because there are no mmap functions in AmigaOS 4.x. If the change was made with mmap in mind then it was definitely not made with AmigaOS 4.x in mind.
It was Rogue who stated that the file padding was the result of ELF files being written with mmap() in mind, Since the padding apparently had nothing to do with math alignment issues, I was just speculating that it was related to the other improvement listed in the news release (SOBJS).
It was Rogue who stated that the file padding was the result of ELF files being written with mmap() in mind, Since the padding apparently had nothing to do with math alignment issues, I was just speculating that it was related to the other improvement listed in the news release (SOBJS).
Or perhaps there are other OS's on which this change make sense ? Hint: L___X
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
