Something appears to be wrong with the binary files produced by the public OS 4.1 SDK. Simple shell commands are huge when compiled with the new SDK. Here are some filesize comparisons for one of my shell commands: Compiled with OS4 SDK using newlib ==== 6380 bytes Compiled with OS4 SDK using clib2 ==== 44523 bytes Compiled with OS 4.1 SDK using newlib = 68812 bytes Compiled with OS 4.1 SDK using clib2 == 88179 bytes As you can see, the OS 4.1 binary is over 10 times the size of the OS4 binary. When I examine the huge OS 4.1 binary with a HEX editor I see that the middle of the binary is nothing but 0s (zeros). Surely something is wrong with the OS 4.1 SDK. One of the advantages of newlib is supposed to be smaller filesize but the OS 4.1 binaries are larger than OS 4 clib2 binaries. Before anyone mentions it, I will point out that stripping the files makes little difference. My small OS4 SDK compiled shell commands seem to work normally and I'm wondering if the SAM alignment issues will affect programs that don't use math libraries or sophisticated math at all? Are there any functions or variable types that I should avoid when compiling for SAM with the OS4 SDK?
The larger size is due to the SDK ensuring correct alignment on the PPC440.
I had some SObjs here which increased from about 8K to 80K when recompiled with the new SDK, but apparently this is normal. As you might guess, the increase is due to a massive chunk of zeros. I can't see why the 440 would need things aligned to what must be a 32K offset?!
The larger size is due to the SDK ensuring correct alignment on the PPC440.
Well, that's some expensive ensurance. It certainly would bring into question the wisdom of picking a processor for SAM that requires programs to be padded with many kilobytes of 0s (zeros) in order to function properly. Quote:
I had some SObjs here which increased from about 8K to 80K when recompiled with the new SDK, but apparently this is normal. As you might guess, the increase is due to a massive chunk of zeros. I can't see why the 440 would need things aligned to what must be a 32K offset?!
I tried compiling some large programs (500kb+) and they only seem to grow in size by the same amount (40-80kb). It's small programs that seem to suffer the most in proportion to size. If you are using a number of SObjs in your program then you may use a lot less system memory resources by changing them to static linked libraries. Common sense tells me that 60K of zeros are not needed in a 5k program to assure proper alignment. I think something is wrong. I wish someone could explain exactly what the SAM alignment issues are and exactly what is being aligned. Maybe they're not telling us because we will then know that these huge program sizes are completely unnecessary. Imagine how much larger the OS 4.1 update will be if all the commands & programs are recompiled with the same SDK we're using!
@xenic I thought that Sam440 "alignment issue" was something to do with FPU operations, which may explain why nobody saw any problem with most programs on Sam440.
I too doubt that 60K of zeros is required! But if something really needs that much padding, then you do it at *load time* not compile time!
Well, the OS4 GCC/bintools are open source, go and check the source, or put a report in the bugtracker./
Have you looked at it? The only binutils 2.18 sources I can find are in the vendor branch and don't show any changes for 17 months. The code in the the main "trunk" appears to be binutils 2.14 with the lates changes being made about 8 months ago and appear to be targeted at 68k Amiga. Since I don't use Linux I wouldn't be able to compile it anyway. I'm tired of looking for the current OS4 sources in the repository but will return to fill out a bug report as you suggest. Actually, I'm fine with compiling my little utility with the OS4 SDK and am just looking for an explanation of what the alignment issues are so I can avoid problems. The comments I've read in the forums and news releases make it a little unclear if the alignment issues are only related to math and the use of the math library or if they are more extensive than that.
Yes, it's caused by the latest binutils (or whatever it's called) that now aligns all sections to 64kB offsets. It's a real nuisance for some of us, but it's not limited to OS4 and it's not code that's been written or maintained by any OS4 developers.
[edit] I forgot to mention that when you strip the binary, most of the rubbish will disappear. [/edit]
Yes, it's caused by the latest binutils (or whatever it's called) that now aligns all sections to 64kB offsets. It's a real nuisance for some of us, but it's not limited to OS4 and it's not code that's been written or maintained by any OS4 developers.
That would explain the growth of one of my programs from 6k to 68k in size. It's hard to believe that a 64KB offset would be required to satisfy the alignment requirements of the SAM CPU. It seems more like it would qualify as a bug or unecessary side effect. Quote:
I forgot to mention that when you strip the binary, most of the rubbish will disappear.
That might be the case if the program is compiled with debug options but my programs are only getting less than 1k in size reduction by stripping them.
Well, this does not bode well when I'm out there trying to convince everyone that Amiga is the most superior OS available!!!!
What would the size of SW be if it was compiling the same program for a 64 bit PPC CPU????
I think PPC is the failing here. ONLY Altivec is it's one saving grace.
Doesn't matter to me, though.
I'm waiting for the new HW Hyperion has arranged to be running on (I am assuming that that is what the M.A.P. is ) and Hyperion has every right to continue enhancing their AOS3.1 68K SW if they wish to, and I feel that that will be a significant market for them in the future. Everyone knows I'm talking NatAmi here.
It's a fork, and we'll use it to "stick it" to the competition..... bon app?tit.
Support Amiga Fantasy cases!!! How to program: 1. Start with lots and lots of 0's. 10. Add 1's, liberally. "Details for OS 5 will be made public in the fourth quarter of 2007, ..." - Bill McEwen Whoah!!! He spoke, a bit late.
64kB sounds ridiculous. I looked through the PPC440 manual and the only alignment that seems to be required is a 16-byte alignment at most.
What in an executable could possibly require it to be aligned on a page boundary, because that's the only thing this large?
About FPU alignment it would be a matter of 4 or 8 byte boundary where a G3/G4 could handle a double at a 4-byte boundary but perhaps the PPC440 might need 8-byte boundary or something like that. Not 64kB.
EDIT: Or is it the static data part that needs to be on a page of its own to be able to write protected? It is still wierd that this space has to be reserved in the objects/executables instead of being aligned by LoadSeg().
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
I thought that Sam440 "alignment issue" was something to do with FPU operations, which may explain why nobody saw any problem with most programs on Sam440.
That was my impression too, but I'd like to be sure it's an FPU issue and was hoping that someone "in the know" could tell us for sure. Quote:
I too doubt that 60K of zeros is required! But if something really needs that much padding, then you do it at *load time* not compile time!
If I remember correctly, that's exactly what the original AmigaOS was designed to do. It used a scatter loader which could load program hunks into non-contiugous memory. Apparently, that concept was abandoned for OS4 which has apparently led to the need to "pad" the program binaries to achieve some sort of page alignment. That change now appears to be a step backward in effecient use of memory and hard-ddisk space. It seems a little ironic that OS4 is now going going to use more hard-disk space and memory for programs and then use virtual memory to move data to the hard-disk to free up more memory when needed. That seems a little "a**-backwards" to me.
Well, this does not bode wellwhen I'm out there trying to convince everyone that Amiga is the most superior OSavailable!!!!
What would the size of SW be if it was compiling the same program for a 64 bit PPC CPU????
I think PPC is the failing here. ONLY Altivec is it's onesaving grace.
I don't think it is anything to do with PPC or OS4. If you read what tonyw wrote, this change is not something that has been implemented by OS4 developers. That suggests it is definitely not an OS4 requirement, and probably not a PPC440 requirement. Hopefully it can be fixed.
If it is a deliberate change in binutils, I don't understand why. I see no reason for a 64kb alignment on sections ... maybe except for usage of 64kb pages on some architectures. But again, the section could be copied in a 64kb page when loading.
But this is not related to FPU alignment on PPC440.
@Deniil Good idea that it might be something to do with aligning on an (MMU) page boundary. But really, that should NOT be hard-wired into the executable! (Page size is likely to change for new CPUs and/or new versions of the OS.)
If this IS the reason, then I guess that the SDK "fix" for the Sam440 was just a quick'n'dirty solution, until they have the time to do it right. Which is fine by me, I just wish they had documented that was the case.
I've not been paying much attention to it, I must admit. There has been a lot of complaint about the growth of binary sizes and I <i>think</i> that was the explanation given - that it's something to do with binutils, but I could be wrong.
I'm sure that no one said that there was a 64kB alignment necessary for EP440 or OS4, I think it's 32 bytes at worst (for Altivec?).
It's just binutils ensuring the alignment is correct for the 440ep-based products. Don't worry about it.
I'm not really worried about it. The OS4 SDK works fine for me. What I really want to know is what those alignment issues or requirements are. Most of the SAM OS 4.1 system commands and programs appear to be the same as those on my ?A1 and appear to work fine. That leads me to believe that the alignment issues may only apply in specific circumstances and I'd like to know what those circumstances are. Obviously, someone knows what the alignment requirements are and when they are needed or they would not have been able to apply a fix (padding?) in the current SDK. Quote:
In a future binutils release perhaps we can change binutils to not pad so much in the binary file itself but it was not a priority of course.
It may not have been a priority but the excessive padding defeats the use of the compiler size optimizations. Including an optimization argument (-O2) is fairly useless now that the binary is being padded with empty space (zeros). Any attempt to manually optimize code for size has also becomes futile. It may not be much of an issue for porting huge Linux libraries and applications because the padding seems to be proportionately less significant in a very large program. However, more traditional Amiga programmers who write programs and utilities that primarily use AmigaOS libraries object to excessively large binaries. 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.
What I really want to know is under what circumstances does alignment become an issue on the SAM processor. If my small programs are not going to encounter those circumstances, I would prefer to compile them with the OS4 SDK; which produces much smaller binaries.
It may not have been a priority but the excessive padding defeats the use of the compiler size optimizations. Including an optimization argument (-O2) is fairly useless now that the binary is being padded with empty space (zeros).
-O2 optimises for speed (as a first priority at least) Using it will make your code bigger
Why would you optimiuse for size these days anyway? Unless you have a very specific target in mind, you should optimise for performance.
If you must optimise for size try -Os
Quote:
Any attempt to manually optimize code for size has also becomes futile.
see above
Quote:
It may not be much of an issue for porting huge Linux libraries and applications because the padding seems to be proportionately less significant in a very large program.
Even reasonably size amiga apps could swallow it, but if it could be removed that would be good. But I aggree with ssolie there are more important priorities.
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.
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
) and Hyperion has every right to continue enhancing their AOS3.1 68K SW if they wish to, and I feel that that will be a significant market for them in the future. Everyone knows I'm talking NatAmi here.
