shouldn't double be %lf?

Double is overkill for this, I'll change the equation to float. The table https://cplusplus.com/reference/cstdio/printf/ suggests that L would be used for long double, while l seems to be for integers unless I'm misunderstanding it.

Changing 0x%lx to 0x%zx seems be OK for both gcc and xcc, I'll update the patch with it.

Yep, I've added functions to get time and cycles. The patch now also computes MCPS with file read/write consumption excluded.

Thanks, yes that works!

Double is overkill for this, I'll change the equation to float. The table https://cplusplus.com/reference/cstdio/printf/ suggests that L would be used for long double, while l seems to be for integers unless I'm misunderstanding it.

long long for consistency?

Thanks, yes changed now!

typo

Fixed, the previous print was without path. Better this way.

indent

Same, I have no idea what's wrong with this indent. My emacs bash mode indents this way.

Mix of tabs and spaces again?

indent

Sorry, I have no idea what's wrong with indent. Help?

Spaces on one line and tabs on the next feels fishy, even for shell scripts.

It's unfortunate that we have some files with tabs and other files with spaces in the same project but I agree 100% with @paulstelian97 : let's please not cross the line where we have a mix of tabs and spaces in the same file!

So @singalsu please find the shortcut in your editor that lets you quickly switch between tabs and spaces like the rest of us :-)

PS: I can't resist sorry: this sort of time-consuming discussion is exactly why tabs suck. Off-topic.

The file is already without my patch a mix of tabs and spaces. I can convert them all to spaces then.

M-x untabify is now done.

I checked and there are only 5 tabs right now. Feel free to convert them to spaces or to leave them alone, as long as you don't add any it's fine by me.

it may be a int32 usage, no need int64.
https://elixir.bootlin.com/zephyr/v1.7.0-rc2/source/drivers/timer/xtensa_sys_timer.c#L41

int32 should be enough, max should be set to: 400,000?

I'd keep this as 64 bits. With 400 MHz 32 bit counter overflows at 10.7s. Other Xtensas can be over 1 GHz clocked and we can support also other processor simulators too in the future.

cycle should be a wrap data, once it go to max, then will go back to zero, so there is another issue with the code,
please refer below:

if (cycles1 > cycles0)
	diff = cycles1 - cycles0;
else
	diff = UINT32_MAX - cycles0 + cycles1;

it is not a always increase data.

so there is another issue with the code,

What was the first issue?

cycle should be a wrap data, once it go to max, then will go back to zero,

Yes and that's OK because unsigned integers (unlike signed integers) are guaranteed to wrap around by the C standard

import numpy as np
np.uint32(5) - np.uint32(0xffffffff)

6

https://www.acepace.net/integerQuiz/

int32 should be ok, since it is delta between one module. no way to exceed int32

Yes, it's true a single file copy should not consume over 32 bit worth of cycles but having this 64 bits avoid type casts. The overhead from this is small and it makes this more future proof, so I'd keep it as is. Unless you or others really want me to change this to smaller size.

As far as I understand this code will only ever run on a GHz 64bits CPU so I don't see what difference 32 bits would make.

Mixing signed and unsigned is fraught with peril and signed overflow is undefined so unsigned is clearly better here.