You don't need a scope to make sure this function performs reasonably.

1000 calls to this function, with 10 as argument should be 10 thousand milliseconds - or 10 seconds.
100 calls to this function, with 100 as argument should also be 10 thousand milliseconds - or 10 seconds.

Have you verified that you can turn on a LED on a processor pin, and have the LED lit for 10 seconds before it is turned off?

By the way - busy-loop delays like that can often be totally removed since they don't actually do anything. They don't have any side effect, leaving the processor or the memory in any different state. So the compiler don't see a use for the loop.

Yet another thing - a busy-loop delay depends on what the generated code looks like. So it differs between different compiler manufacturers, or between different versions of the compiler from the same manufacturer or because of memory model or optimization setting or what registers etc happens to be available.

When you write low-level code, it is very good to have a digital oscilloscope. But lots of things can be tested without one, if you have a couple of LED or a multimeter. But it is up to you to sit down and think how code can be split up into smaller blocks, and how individual blocks can be tested.

If you have a state machine where multiple pins should toggle in some sequence, you can test that by introducing much longer delays between each pin change, so the action is slowed enough that you can see it with your eyes. Then you know the sequence is correct. And as I mentioned earlier - a fast delay can be checked by calling it many times, and verify that the delay gets properly scaled.