Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#467 PIC operation not accurate enough (concurrency)

open
nobody
None
5
2012-10-15
2012-09-26
Czerno Bill
No

Artifacts exist with the emulated PICs (also APIC) which lead to non accurate behaviour.
It may be desirable to introduce delays to better model the platform hardware.

Specific case (there may be others, this is merely an example) : in Bochs, when PIC receives
an eligible interrupt request, it passes from the IRR to the ISR instantaneously (as far as the emulated
CPU is aware) : unlike on real platforms, Bochs CPU doesn't get a chance to "see" the request coming into IRR
(reading IRR from the foreground program will always yield zero in Bochs unlike real ISA).

Is this by design, or shouldn't Bochs be designed to let the CPU(s) execute in (quasi)parallelism with
the PICs ?

Similar remarks might apply to other elements of the platform or "chipset" which are running in
parallel, but I'll limit this artefact report to the PIC for definiteness, and because I stumbled on
this case accidentally...

Discussion

  • Czerno Bill
    Czerno Bill
    2012-10-04

    ...From a cursory look at Intel's 8259-A PIC data sheet, it seems a reasonable estimate for the latency from IRn asserted to INT could be 400 ns. If we accept this, and the CPU is to execute IPS instructions per second, then the emulated interrupt controller should yield round[ IPS / 2,500,000 ] "ticks" (leaving the respective IRR bit set ) before resetting IRR bit n and starting the interrupt cycle proper to the CPU.

    If IPS=20 million, that would be 8 ticks for instance.

    Of course this is just an order of magnitude, and it's based on the 8259-A spec. One should check the respective delay for the chipset that Bochs emulates (some sort of Intel BX, iirc). Exact numbers are neither attainable nor necessary anyway.

    Disclaimer : based on'educated guess only. I am not a hardware engineer...

     
  • Hi,

    I think you should explain why the change is needed at all.
    Are you aware of any correctly written software which break because of that ?

    Bochs doesn't aim to be cycle accurate and could allow to cut corners in some places for simplicity and emulation performance. In this case I see a request to trace both simplicity and emulation performance for ... nothing.

    Stanislav

     
  • Czerno Bill
    Czerno Bill
    2012-10-05

    I understand your commentsn Stanislaw, especially the concern about performance, and no, I am not aware of particular PC OS or software that would break because of this inaccuracy : most if not all PC software uses the PIC in interrupt mode and doesn't depend on polling the IRR (rightly so). OTOH it is easy to write a program demonstrating the issue... Also, note it's not a question of being "cycle-accurate" - which the Bochs cannot and does not aim to be. In this case, a state which occurs on a real machine is merely missed in the Bochs.

    In fine it's up to you (the developers) to decide where compromises have to be made for the sake of efficiency. I hope not to many of those are necessary.

     
  • Moved to feature request