ee_u32 accessed with %d format specifier

[mysterymath]

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:

1. Cast to int before the format specifier.
2. Use the C99 format specifier macros for uint32_t.
3. Create an EEMBC-specific version of the above macro and add it to the port headers.

[petertorelli]

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?

[mysterymath]

https://github.com/llvm-mos/llvm-mos

LLVM backend for the MOS 6502!

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.

[joseph-yiu]

Hi @mysterymath , @petertorelli ,
Could you check if #76 solve the problem?
Thanks and regards,
Joseph

[joseph-yiu]

Note: Feedback received via #76 . Changes merged into development branch (dev_2026q3).