I suspect they are talking about a design limitation in MS Windows actuallyBrendan wrote: Are these morons serious?? The PIT has a resolution of roughly 838 nS - over one thousand times more precise than the 1 mS resolution they are complaining about.
. They also say "achievable resolution of 2 ms because of performance issues". I guess that's due to a buch of code that seriously goes wrong at a higher frequency - but not the hardware's fault. Well that's exactly what I planned to do in my implementation. Use the timer interrupt in one-shot mode for asynchronous events - I have not yet seen a problem with this.Brendan wrote: OK - so I can assume Microsoft haven't figure out how to use the PIT in "one-shot" mode then. Perhaps they should read some technical material before designing the OS? Even the RTC's periodic interrupt can handle the example they present without problems.
erm... no, the important thing would be for us to understand it.Do not spend too much time trying to figure out why this math works. The basis for the computation is complicated; the important point is that this is how Microsoft operating systems do it, and it works.
Not really. You implement a FAT driver for compatibility with Microsoft operating systems, which the majority of PC users use, making it much easier to move data between your OS and Microsoft's. If Microsoft implemented their own filesystem technically wrong, you would too, since there's no point outside of compatibility for such a stinky filesystem. The FAT document is more about how to be compatible with Microsoft's implementation of the filesystem than why and all those fascinating design (or lack thereof) details.Kemp wrote: I don't like in the FAT document how they say:
erm... no, the important thing would be for us to understand it.Do not spend too much time trying to figure out why this math works. The basis for the computation is complicated; the important point is that this is how Microsoft operating systems do it, and it works.
In fact, they even go on to say:Note, however, that this math does not work perfectly. It will occasionally set a FATSz that is up to2 sectors too large for FAT16, and occasionally up to 8 sectors too large for FAT32.
Surprisingly simple and yet too complicated to explain? As far as I'm concerned, the document writer was just being lazy (as reinforced by other comments in the document).Because it is OK to have a FATSz that is too large, at the expense of wasting a few sectors, the fact that this computation is surprisingly simple more than makes up for it being off in a safe way in some cases.
Possibly. An algorithm can be easy to do, that doesn't mean that *why* it works is not complex.Kemp wrote: Surprisingly simple and yet too complicated to explain?
Hmmm - what are precise interrupts?Crazed123 wrote:This actually makes me ask a completely unrelated question: Do the Pentium Pro and up have precise interrupts anymore, or is that just a legacy feature?
There's the local APIC too (3 timers!) which is much more precise as it uses a 64 bit counter and it's frequency is derived from the CPU's bus speed. Microsoft actually are correct in that power management can interfere with the accuracy of the local APIC timer, which (depending on what you use it for) may or may not be a good or bad thing. For e.g. using it to measure real time in any way is a bad idea, but using it to measure the amount of CPU time used is a good idea (IMHO it's great for schedulers, which isn't too surprising as that's what it was probably designed to be used for). They neglected to mention that hyper-threading can also make the local APIC timer a little tricky (might need some form of work-around, depending on what the local APIC timer is being used for).Crazed123 wrote:And just why do we need a new damned timer to program? As shown by the previous posts, we already have 2.
).In the case of an x86, the PC would be the eip register. According to these properties, at least, it's easier to deal with precise interrupts for an operating system coder, and far harder for imprecise interrupts that don't give you a known state on interrupt.1. The PC (Program Counter) is saved in a known place.
2. All instructions before the one pointed to by the PC have fully executed.
3. No instruction beyond the one pointed to by the PC has been executed.
4. The execution state of the instruction pointed to by the PC is known.
Ahh - OK. In this case, all 80x86 CPUs do or don't support precise interrupts, depending on how much execution state you expect to be saved. All 80x86 CPUs behave in a similar way.Crazed123 wrote:I quote the four properties of precise interrupts, straight from textbook:In the case of an x86, the PC would be the eip register. According to these properties, at least, it's easier to deal with precise interrupts for an operating system coder, and far harder for imprecise interrupts that don't give you a known state on interrupt.1. The PC (Program Counter) is saved in a known place.
2. All instructions before the one pointed to by the PC have fully executed.
3. No instruction beyond the one pointed to by the PC has been executed.
4. The execution state of the instruction pointed to by the PC is known.
--The only aborts on x86 that I know of are double fault and machine-check exceptions.Aborts
An abort is an exception that does not always report the precise location of the instruction causing the exception and does not allow restart of the program or task that caused the exception. Aborts are used to report severe errors, such as hardware errors and inconsistent or illegal values in system tables.
Well, they are superscalar. Any pipelined processor pretty much has to "emulate" precise interrupts by flushing the pipeline. It just gets trickier with out-of-order execution and longer FP pipelines, but that's a concern for the CPU designers fortunately.Crazed123 wrote: Good, now I can give Tanenbaum a good smack for scaring me with that talk of later Pentiums (after Pentium Pro) being superscalars that merely emulated precise interrupts. I had begun to think that newer processors (such as the hyperthreading P4s) might have had the feature dropped from emulation, or that precise interrupts might have been dropped from Itanium or Opteron.
