> while testing dos32a, dos4gw, cwsdpmi, cwstub, ... with the "pctest" > program which is part of either dos32a or cwsdpmi, I got a FreeDOS > (I guess) "illegal opcode 0f 31 ..." error message that killed pctest, > at least with some of those DOS extenders. > > Now 0f 31 is "rdtsc" (read time stamp counter, the time stamp counter > is a 64bit counter of CPU cycles since reset). My processor is a > pentium-class one, but no actual Pentium, and it does not have a TSC. > So for my CPU, this is indeed an illegal instruction on my CPU.
So its a Cyrix 586, or AMD 486? Such processors are extremely rare. In any event, its also possible that its a programmer failure. I can't remember the exact details, but there is one mode where the RDTSC instruction is *SUPPOSED* to fault when not executing in ring 0. Its either real mode, v86 mode or both -- my mind is a blank on this right now for some reason. Anyhow, the key here is that DOS4GW is a little strange in that it actually runs its v86 mode in ring 0 if a DPMI server is not already present, whereas most other extenders properly set up a ring 3 mode. This discrepency can lead to unexpected behaviors when trying to execute RDTSC in 16 bit mode. > My question: The message obviously occurs because those DOS extenders > fail to install their own illegal opcode handler. The offending code > looks like this (it is inside 32bit DPMI): If it did install a handler, what would you expect it to do with an RDTSC instruction? That one is kind of hard to emulate -- perhaps you could return something like: (long long)(((double)time(NULL)) * 65536.0 + (++counter)) So this is also part of your problem -- if the application cannot use RDTSC, then what? You can install a timer interrupt handler to increment a volatile variable, but that still has a granularity that is nowhere near that of RDTSC. > [...] > Okay, I was announcing a QUESTION. Do you think it makes sense > to simulate the TSC from DOS, even for DPMI ? We could for example > return 1000000 * timer ticks (the common 40:[6c] value...) or even > some more stupid value. Would that make sense??? Do you know of other > "TSC-less CPU helpers"? You would like it to have a couple properties: 1. It should be proportional to real time. 2. It should always produce increasing (not the same) values on subsequent calls. (otherwise division by zero will happen too often and too easily.) Hence my suggestion above includes the (++counter) term in it. > I personally think that programs SHOULD first check for the existance > of the TSC before using it, but, well... some programs just fail to be > sane. Of course, but pre-P5 processors are extremely rare. Convincing application developers to watch out for this is an uphill battle to say the least. > This ideas / questions / feature suggestions go to whoever knows a nice > solution and of course especially to the kernel people. I do not know of > any other DOS program that relies on the TSC but fails to check for its > existence, but this is probably because I only use pretty old DOS software > that is already happy with a 486 CPU. > > Do not take this as an important feature request, but I would like some > feedback on this mail anyways... I think this is beyond the mandate of freedos. However, it would be a nice feature to have for certain 386/486/Cyrix class processors. -- Paul Hsieh [EMAIL PROTECTED] ---------- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
