> From: Michael Bloom <mabl...@dslextreme.com> > nanosleep() would give you the exact timing needed. I'm very much against >polling the time as a solution because it could use up a lot of CPU cycles >that >other processes would love to have. > > "spinning" when there are ways that are more accurate (not to mention >friendlier to other processes who'd like some CPU time) to simulate timing, >is >not the best choice, in my opinion.
Hi Michael, First off, the whole issue was about the code that gets executed only when console ROM is active. Once the bootstrap is started, it is irrelevant. Second, on most platforms you are lucky to get sleep interval with granularity around 1 ms. Never mind 100 us, let alone 1 us. Having system call that takes its argument in nanosecond or femtosecond units does not mean host OS timer events are actually processed at this resolution. But even if they magically were, the cost for no-op system call (userland-kernel-userland context roundtrip) on 3+ GHz x64 CPU is about 1 us, which is approximately the amount of the delay introduced by rom_read_delay loop. The overhead of creating timer entry -- merely creating the entry, without any processing of it -- would exceed the delay required. _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
