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
In core_main.c, the results of time_in_secs is printed using the %d format specifier, which handles arguments of type int.
However type secs_ret is type ee_u32, which is not int-sized on 16-bit platforms (for which I'm working on an LLVM port :) ).
I got lucky in that my platform is little endian, so the low order 16-bits that will be read by %d are the ones that I want, and there aren't any arguments after the problematic %d's.
Three ways off the top of my head to fix this:
Cast to int before the format specifier.
Use the C99 format specifier macros for uint32_t.
Create an EEMBC-specific version of the above macro and add it to the port headers.
The text was updated successfully, but these errors were encountered:
Good to see 16-bit getting some representation! I think option 2, PRIu32 is the best solution since the intent is to print a 32-bit value. I'll queue this up for the next release, we don't make changes very often, so for the short term I recommend just modifying the printf. I have encountered a case of someone running CoreMark for huge numbers of iterations during testing, so >64Ksec isn't unheard of.
What compiler and target are you using, out of curiosity?
It's still really early days with respect to optimization work (so don't post this anywhere too official ;) ), but I'm happy to report that a 1MHz MOS 6502 achieves 0.0386 CoreMarks/s with our backend.
Looking at the generated output, there's a ton of obvious inoptimalities. It's nice to have such a comprehensive benchmark to work against! Porting it was surprisingly easy, too.
In core_main.c, the results of time_in_secs is printed using the %d format specifier, which handles arguments of type int.
However type secs_ret is type ee_u32, which is not int-sized on 16-bit platforms (for which I'm working on an LLVM port :) ).
I got lucky in that my platform is little endian, so the low order 16-bits that will be read by %d are the ones that I want, and there aren't any arguments after the problematic %d's.
Three ways off the top of my head to fix this:
The text was updated successfully, but these errors were encountered: