You should be able to get an idea of each instruction's execution time. The usual way to do a delay is to run a loop in which a variable increments (or decrements) to some terminal value. Since the loop is invariant, the time it takes to execute is predictable. You can also nest loops for much longer timing periods. Get the first loop tweaked to a useful interval, and just go from there.
Since it's x86 code, how can it not be CPU-dependent? Assembler runs at machine speed. It's hard to imagine any block of code not running faster on a 3 GHz machine than on an old P2 450 MHz.
I'm sure that games have some means of "padding" run time so game play is pretty even across some large range of CPU clocks. Perhaps that might be an area to look into for CPU-independent timing loops.
beenthere, there seems to be a way but it's not working for me, the 5th bit of the 61h port toggles every 15us, which can be used for CPU-clock dependent time delay but like I said it's not working for me.
What OS are you working with? And what is your intended resolution?
As far as I know, for XT or AT port 61h is the PPI control interface. I have never heard any timer of any kind at bit 5 of port 61.
As I mentioned above, your best bet is to use BIOS tick call (int 8) or the derived int 1C or read the tick count directly. These will give you 55ms resolution. If you need something finer, then you have to go directly to the timer chip (probably around 0.8us, I can't remember the exact value).
it worked, although not totally processor speed independent.
n9352527, XT I don't know (I'll look it up), but starting from AT and up to pentium, the 4th bit (I correct my self) of the 61h port is toggled every 15.085us.