You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a basic blink for the RPi Zero/A+ (which is armv6). I based it on the same program I already have in C. When compiled with the 0.9.1 compiler, all is well and I get a binary of 1.9Kb in debug build, and 136B in fast build. Both builds succeed in blinking my light.
With the self hosted, the same program (albeit using backing ints for packed structs) produces a 20Kb binary in debug build and the same 136B binary in fast build. Notably, there is also a problem with @Memset() here as well, but I will be filing a separate issue for that.
Is it perhaps that it is simply including more of the platform specific functions (i.e. cpu feature setups for erratas) in my binary, despite me never calling into them? My binary legit is a basic asm file which sets the sp, disables interrupts, and branches to my zigMain.
Either way, it seems much less efficient to be emitting 10x more machine code into my final binary when the original 2Kb worked. I can see the justification if it legitimately helps with the compiled evaluating safety constraints though.
Expected Behavior
Should emit a binary in debug build that is similar size as the previous compiler (not 10x size increase).
The text was updated successfully, but these errors were encountered:
NerdySouth
added
the
bug
Observed behavior contradicts documented or intended behavior
label
Nov 3, 2022
Here is a zip of my project. It should work fine, if not ill update this. It is a zip so I could include my linker script as well. I included the objdump for the different builds as well as .list files.
Zig Version
0.10.0
Steps to Reproduce and Observed Behavior
I have a basic blink for the RPi Zero/A+ (which is armv6). I based it on the same program I already have in C. When compiled with the 0.9.1 compiler, all is well and I get a binary of 1.9Kb in debug build, and 136B in fast build. Both builds succeed in blinking my light.
With the self hosted, the same program (albeit using backing ints for packed structs) produces a 20Kb binary in debug build and the same 136B binary in fast build. Notably, there is also a problem with @Memset() here as well, but I will be filing a separate issue for that.
Is it perhaps that it is simply including more of the platform specific functions (i.e. cpu feature setups for erratas) in my binary, despite me never calling into them? My binary legit is a basic asm file which sets the sp, disables interrupts, and branches to my zigMain.
Either way, it seems much less efficient to be emitting 10x more machine code into my final binary when the original 2Kb worked. I can see the justification if it legitimately helps with the compiled evaluating safety constraints though.
Expected Behavior
Should emit a binary in debug build that is similar size as the previous compiler (not 10x size increase).
The text was updated successfully, but these errors were encountered: