Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: How common were interrupt bugged 8088s?

  1. #1
    Join Date
    Jan 2013
    Location
    Marietta, GA
    Posts
    3,098

    Default How common were interrupt bugged 8088s?

    When 8088 based machines were common, how likely was it to run in to an 8088 CPU with the interrupt bug?

    Also, is having a PC with this bug a serious issue?

    I'm wondering because I just tested a ~1983 PC clone and CheckIT reports the CPU has that interrupt bug. It sounds like much 8088 code takes that in to consideration, yet if it weren't considered an important issue then why would CheckIT report that? (Other than to make itself look important :P )

  2. #2
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,208
    Blog Entries
    20

    Default

    Not very common--most 5150s used third-party versions (AMD, etc.) of the 8088 which came about after the fixing of the interrupt bug. People coded for it long after machines with it vanished. I wouldn't be surprised to see some oddball program that runs on minimum 80286 still with some of the interrupt-hedging code in it.

  3. #3

    Default

    Quote Originally Posted by Chuck(G) View Post
    I wouldn't be surprised to see some oddball program that runs on minimum 80286 still with some of the interrupt-hedging code in it.
    That's actually very common in my experience. I suppose a lot of code written for 808x just wasn't updated for the 286.
    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

  4. #4
    Join Date
    Jan 2013
    Location
    Marietta, GA
    Posts
    3,098

    Default

    Well, yea, I'd expect that most high-level code compilers would automatically take that in to consideration, and of course some would continue to do it that way even for later CPUs just because. And assembly code imported from an earlier program and not touched out of fear of breaking the magic, is no surprise.

    It does figure that early inexpensive PC clones might use bottom of the barrel, reject, or even reused parts. At any rate, it is interesting to see a machine that seems to have come stock with this CPU.

  5. #5
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,208
    Blog Entries
    20

    Default

    Quote Originally Posted by Krille View Post
    That's actually very common in my experience. I suppose a lot of code written for 808x just wasn't updated for the 286.
    I've always thought it was more of a matter of "that's the way I learned to do it, so why change?" I've run into DI instructions at the beginning of ISRs ("let's really make sure that interrupts are disabled!").

  6. #6
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,778
    Blog Entries
    1

    Default

    Wait, what interrupt bug are we talking about? Because there are several, and one type is present on all 8088s and 8086s:

    REP ES: MOVSB
    or
    ES: REP MOVSB

    On all 808x CPUs, the former will lose the REP after an interrupt, and the latter will lose the ES: after the interrupt. This wasn't fixed until the 386 IIRC, so I always account for this in my code.

    There's also the MOV segreg,xxx bug, although it's more of a feature than a bug (on 808x, MOV SS,xxx is supposed to disable interrupts for the very next instruction which was intended to be MOV SP,xxx -- but it actually disables interrupts when MOVing to any segment register, not just SS).

    If neither of the above are the bug, then what interrupt bug are we talking about?
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Documentation and original disks for: Panasonic Sr. Partner, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  7. #7
    Join Date
    Jul 2010
    Location
    Silicon Forest, Oregon, USA
    Posts
    718

    Default

    Quote Originally Posted by SomeGuy View Post
    It does figure that early inexpensive PC clones might use bottom of the barrel, reject, or even reused parts. At any rate, it is interesting to see a machine that seems to have come stock with this CPU.
    I am assuming you're talking about POP SS/MOV SS bug.

    It is not a serious issue
    First of all you're not using your PC clone for anything serious (I hope).
    Second, the workaround is normally implemented in the BIOS and the software. Even if it is not, the chance of hitting this bug without workaround is not huge - there are only so many places that reload the SS register, normally people would disable interrupts when doing so (regardless of this bug), also you'll need the interrupt to fire right in between loading SS and SP...
    Treat this as having a historically significant processor - the first x86 CPU with a bug
    Considering all of above, replacing it with a non-buggy version will not change anything really. So I'd just keep it the way it is.

    Regarding having the buggy CPU in a cheap PC clone. I think that indeed, the manufacturer was looking for the cheap components around, and perhaps purchased an old(er) stock of Intel 8088's. I don't think they are "rejected parts" though. I don't recall Intel or IBM ever doing a recall on these processors. I've read that IBM did supply a not buggy 8088 with the 8087 FPU upgrade kit. But they didn't collect the buggy 8088 back.

  8. #8
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,208
    Blog Entries
    20

    Default

    Add to this that you have a system that's probably going to be stuck running DOS or CP/M. Interrupts are not usually a huge issue here. Software that actually uses interrupts from that period usually has taken the bug into account, whether it's the segreg one or the multi-prefix "clipping".

    On the early 8085s, there was a reset bug (I don't recall the exact nature of it) and it could be handled with a bit of logic, so code wasn't affected.

    More serious bugs to me are the "you can't do that, even though we said you could" ones. For example, a common MCU states in its datasheets that the SPI can be run at 48MHz, when, in fact, the max is only half that (24Mhz). There's no simple way to get around that, short of lowering your objectives. The better solution is to find another MCU from a different vendor.

  9. #9
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,778
    Blog Entries
    1

    Default

    Quote Originally Posted by sergey View Post
    I am assuming you're talking about POP SS/MOV SS bug.
    Wait, so the bug is that POP SS/MOV SS is supposed to disable interrupts for the next instruction, but doesn't? Ouch.

    Actually, I think I knew this already, but had forgotten. Thanks for the reminder.
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Documentation and original disks for: Panasonic Sr. Partner, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  10. #10
    Join Date
    Jul 2010
    Location
    Silicon Forest, Oregon, USA
    Posts
    718

    Default

    Quote Originally Posted by Trixter View Post
    Wait, so the bug is that POP SS/MOV SS is supposed to disable interrupts for the next instruction, but doesn't? Ouch.
    Yes, Intel 8088 processors marked as "(C)INTEL'78" have this bug. Intel processors with a later copyright year, for example "(C)INTEL '78 '81" and "(C) INTEL '78 '83" don't have it.
    I've never observed this bug on any of 8088 clones nor in 80C88 processors.
    Note that some newer processors (plastic packages, or ceramic MD/TD/QD variants) might be marked with "INTEL (C) 1978"... these processors are not affected by the bug.

    Now, the fix has some unintended consequences - it disables interrupts not only following MOV SS and POP SS, but also after any segment register load (useful for testing, see below).
    In addition to that for whatever reason Harris/Intersil/newer Intel 80C88A processors also disable interrupts after PUSH sreg instructions... OKI 80C88 and older Intel 80C88A (seems to be actually made by OKI) don't do that.

    The bug is fairly easy to detect in the software. Enable single step interrupt and trace through a code that loads a segment register. Do not use SS though... unless you're loading the same valid SS value that it
    already has, or you'll actually hit the bug. Check if single step interrupt gets triggered immediately after MOV sreg. If it does - congratulations, you've got a buggy CPU.
    My code that checks for this bug and also detects the 8088 variety is here: https://github.com/skiselev/8088_bio...o_8088/cpu.inc

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •