The only way to have more fun than abstracting broken software is abstracting broken hardware.
I can imagine somebody spent months on those few lines of assembly.
I can imagine somebody spent months on those few lines of assembly.
If you just needed a delay, this is bad code thats just been randomly iterated until it 'works'.
On the other hand, if the hardware does require such an incantation then it's impressive that someone managed to wade through the brokenness.
I'm inclined to believe it's the former though.
if its 20 push pops foo 10 push pops bar foo 20 push pops foo foo 10 push pops.
to achieve the same delay.
its like: a=1 b=2 result=0 print 1+2 return
it isnt wrong, but its indicative of someone who doesnt understand whats going on. you wouldnt describe it as good code.
We get instruction fetch, memory read, memory write, and probably idle -- and an I/O write (0F0h). We should get the idle cycles because PUSH/POP instructions are single-byte and require a little time for decoding and the 286 BIU fetched 2 bytes at a time so the instruction buffer should get full.
Maybe they wanted that on top of the delay (which is obviously there because they didn't want to use the FWAIT instruction) -- maybe some 80287 chips had internal state machines that could get confused and needed some help?
But I think that's an overly charitable interpretation based on the evidence.
If the source code turns up with detailed comments about why it's like it is. Fine. In the absence of that, I'm not buying it.
As I said, if you just had 100 push pops, fine. But it isnt, it's push pops mixed in with other seemingly redundant code.
I've done similar where you misunderstand something and what you write doesn't work, you strip it down to a minimum working version add on bits which break it, fiddle about with iterating the new bits and afterwards you have an accretion that 'works' but you don't know why.