4 ms·

I suppose it depends how the hardware was broken. If you just needed a delay, this is bad code thats just been randomly iterated until it 'works'. On the othe

• twoodfin 3y ago
  The delays introduced by the repeated PUSH/POPs would be quite short, even on the 8088. How would you propose such making high-precision waits for the external x87 chip? (Assuming they were needed at all.)
  • benj111 3y ago
    if it was just 100 push pops, that would be fine for a delay. 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.
    • peterfirefly 3y ago
      A non-obvious reason for using PUSH/POP instead of a loop could be to generate as many different bus cycles as possible. 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?
      • benj111 3y ago
        It /could/ be that. 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.
        • peterfirefly 3y ago
          I also don't think it is. I think it is just a short and simple delay -- each push/pop pair is only two bytes AND generates 2 word transfers AND doesn't disturb any registers. They probably had a macro or repm loop for it.
          • benj111 3y ago
            But why the redundant FNCLEX and io writes then? 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.
• Palomides 3y ago
  it looks suspicious to me, like the kind of thing you find on page 30 of a processor errata document, something like "single writes to external device fail 0.5% of the time due to a register clearing bug on mask revisions prior to version 23. recommended workaround: write twice."
• wruza 3y ago
  Otoh, these operations are too specific to come up with by random iteration. I believe it was some hardware nonsense that was both arcane and avoided by random iteration.
  • benj111 3y ago
    Is it too specific or is it Adams' sentient puddle? 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.
• brmgb 3y ago
  I can tell from this post that you probably have had the chance of never having to work with or emulate broken hardware (which is to say every pieces of hardware ever). At some point you just stop trying to be sane and just go with what works.