I
Ian
And some fell on stony ground....Robert Redelmeier said:
(thank goodness!)
Regards
Ian
;-)
(thank goodness!)
Regards
Ian
;-)
M
MooseFET
SSSSHHHHHH! They might hear you!
Learn something new every day.
R
Robert Redelmeier
In comp.sys.ibm.pc.hardware.chips MooseFET said:
They do! How else would you propagate an FDIV-like bugfix?
IIRC, the BIOS writer's guides are NDA-only, and Intel
provides the binary lump under licence.
Reloading the microcode isn't a big deal each boot,
a few kB at MB/s. Too much for embedded, though.
-- Robert
C
chrisv
Radium said:
It's not "so expensive". It's expensive "compared to disk".
B
Bob Myers
Radium said:
No problem; I have yet to see any type of storage that stored
things in imaginary time OR imaginary hardware.
If you can store data, you can store video. And of course the
color matters; you certainly wouldn't want to be storing red
video in green, would you? Something like that could rip
asunder the very fabric of reality!
Bob M.
R
Radium
Why is it more expensive?
A
Alex Colvin
Oh. The other type of ROM I like is analog ROM in the form of variable-
How about the Optigon?
How about the Optigon?
B
Bob Myers
Primarily, because it costs more.
Bob M.
K
kony
As already stated, it's not just my time being wasted.
Anyone who had not been aware of Radium's posting folly
would then be aware after I'd mentioned it. If you don't
like that someone mentioned it, too bad for you.
T
Terje Mathisen
[followups set to c.arch which I read]
You cannot in fact fix any errors of the FDIV kind.
This is because FDIV is/was a non-priviledged opcode, with no way for
the OS/kernel to trap attempts to divide (by good or bad divisors).
I wrote the FDIV workaround code, and the way it worked was by replacing
all FDIV opcodes generated by nearly all x86 compilers:
Instead of a regular FDIV it would generate a call to a fixup function.
This function would first check if the current cpu actually had the bug
or not.
If not, then the CALL FIXUP instruction could be back-patched into a
normal FDIV followed by a few NOPs to make the size work out correctly.
If the bug was present, then the fixup function would go through a
number of steps to make everything work out:
- Store the (64-bit) divisor in memory, then inspect the top 10 bits of
the mantissa. If this number in the [0-1023] range did not correspond to
one of the 5 values which could trigger the bug, then the fixup function
would just jump to a regular FDIV opcode and return. This entire
operation took less than twice as long as a normal inline FDIV, so the
actual overhead was pretty reasonable since very few programs do nothing
but back-to-back FDIVs.
- If the mantissa turned out to be problematical (odds of 5:1024), then
more work was needed:
-- Save the current fp control word, then set the FPU to extended
(80-bit) mode.
-- Multiply both dividend and divisor by 15/16. Since this happened in
extended mode, both operations were exact.
-- Restore the original (64-bit) control word
- Finally, do the FDIV (with 80-bit inputs and 64-bit result!) and
return with the result.
Terje
Robert said:
You cannot in fact fix any errors of the FDIV kind.
This is because FDIV is/was a non-priviledged opcode, with no way for
the OS/kernel to trap attempts to divide (by good or bad divisors).
I wrote the FDIV workaround code, and the way it worked was by replacing
all FDIV opcodes generated by nearly all x86 compilers:
Instead of a regular FDIV it would generate a call to a fixup function.
This function would first check if the current cpu actually had the bug
or not.
If not, then the CALL FIXUP instruction could be back-patched into a
normal FDIV followed by a few NOPs to make the size work out correctly.
If the bug was present, then the fixup function would go through a
number of steps to make everything work out:
- Store the (64-bit) divisor in memory, then inspect the top 10 bits of
the mantissa. If this number in the [0-1023] range did not correspond to
one of the 5 values which could trigger the bug, then the fixup function
would just jump to a regular FDIV opcode and return. This entire
operation took less than twice as long as a normal inline FDIV, so the
actual overhead was pretty reasonable since very few programs do nothing
but back-to-back FDIVs.
- If the mantissa turned out to be problematical (odds of 5:1024), then
more work was needed:
-- Save the current fp control word, then set the FPU to extended
(80-bit) mode.
-- Multiply both dividend and divisor by 15/16. Since this happened in
extended mode, both operations were exact.
-- Restore the original (64-bit) control word
- Finally, do the FDIV (with 80-bit inputs and 64-bit result!) and
return with the result.
Terje
K
krw
As I already stated, it's not your job to save other people from
themselves.
Not only do you not believe people can look out for themselves but
believe they're all stupid. Have you really been appointed by the
Usenet gods to protect the stupid? Wow!
Look who is whining about his toes.
K
kony
R
Robert Redelmeier
ah, but as posted, I read in csiphc. Do you wanna trim?In comp.sys.ibm.pc.hardware.chips Terje Mathisen said:
Sure you can! Just not easily retroactively
AFAIK, currentCPUs use BIOs-loaded microcode so faulty LUTs (among other bugs)
can get fixed.
Your solution is probably the best. But it is not the only one:
Iff you're willing to suffer the performance hit on other FPU
instructions, an OS could leave Task Switch (the lazy x87
context save) bit 3 of CR0 set. #NM (Device not available)
exception would be raised each time, and dealt with by OS code
(subsituting FDIV as necessary). It could also use the EM
(emulation) bit 2 of CR0 to do much the same thing.
This way is probably better since it doesn't slow normal FPU code.
Another solution we used was to ignore the FPU bug. Our data
has _way_ sloppier tolerances and the code considers it
"converged" with far fewer bits. But some people probably are
calcing eigenvalues close to zero. I have far less sympathy
for people using Excel to do accounting.
-- Robert
R
Radium
The Optigon uses discs, not film. When dealing with analog optical
audio, I prefer to use similar film material as was used in the
optical audio tracks of B&W movies.
Also, it's possible to store info other than audio in an optical film
track. For example, computer codes for certain programs. I'd like to
convert my vintage Chessmaster 3000 and Mavis Beacon 2.0 CDs into
optical info stored on an analog film track. Just for the sake of
experimentation.
K
krw
M
MooseFET
Learn something new every day. I guess the NDA is how Intel avoids
letting to much of the magic get away.
K
kony
Then why did you WASTE YOUR TIME?
K
krw
The magic isn't documented either. It's just bits. In addition to
the stuff Robert is talking about, we had things called "chicken-
switches" for options/fixes we weren't quite sure worked. We could
always go back to the previous operation/logic, if need be. Some of
these chicken-switches controlled customer specific options, as well.
K
krw
That's simple. No waste of time at all. I love watching control
freaks twist in the wind.
K
kony
You're gotten so used to wasting time you can't even
recognize it, which is sad.