Intel's Skylake Prime Number Bug.

DecadentLinuxUserNumeroUno, you are just a warm ray of sunshine.

I am not a Skybuck Flying fan.

You losing control of yourself, feeding him, is helpful to know one, least
you.
Killfile him and be done with it.

My2c.

On Tue, 12 Jan 2016 20:00:08 +0000 (UTC), Mark - wrote:

|
| DecadentLinuxUserNumeroUno, you are just a warm ray of sunshine.
|
| I am not a Skybuck Flying fan.
|
| You losing control of yourself, feeding him, is helpful to know one, least
| you.
| Killfile him and be done with it.
|
| My2c.

Good advice. I don't recall his ever once posting anything useful. Or even
intelligible except on rare occasion.

Larc

Doh.

You losing control of yourself, feeding him, is helpful to know one,
least you.
Killfile him and be done with it.

Should be no one.

Good advice. I don't recall his ever once posting anything useful.
Or even intelligible except on rare occasion.

He (Skybuck Flying ), assuming a he and only one person posting under that
nom de plume, is one of a kind.

John Larkin wrote:
On Mon, 11 Jan 2016 11:10:44 -0500,
wrote:

On Mon, 11 Jan 2016 16:44:49 +0100, "Skybuck wrote:

| Hello,
|
| Apperently Intel's Skylake Processors can freeze up when calculating certain
| Prime Numbers.
|
| I am investigating this story further, for now here is a link about it:
|
| https://communities.intel.com/mobile...nts%2F52 4553

Intel is apparently aware of this and is working with its partners to distribute a
fix in form of a BIOS update.

http://arstechnica.com/gadgets/2016/...lex-workloads/

Larc

I wonder how the BIOS can fix an FPU error. Trap exceptions? Change
some firmware?


EXACTLY what i thought.
Maybe the patch is to trap the offending instruction(s) which then
_emulates_ them (correctly?).
A good way to excessively slow down calculations of Pi to umpteen
digits, or do a Fourier on 10^4 digits or more.

I wonder how the BIOS can fix an FPU error. Trap exceptions? Change
some firmware?

Probably adjust timing or voltages to avoid a race condition.

On Tue, 12 Jan 2016 09:25:25 -0800, John Larkin
wrote:



One of the driving forces of "RISC" compared to older "CISC" designs was
to get rid of microcode.

And since by far most modern cpus (both in terms of the numbers
produced, and the number of designs) are microcontrollers, which almost
never use microcode, it's fair to say that only a small proportion of
currently active processors have microcode - even though those
processors are rather important.

I think the fundamental RISC concept is to design an instruction set
that's compiler friendly and not people friendly. CISC attempted to
make assembly programming look like a programming language; RISC
pretty much assumes that binaries are created by compilers.

The original reason of going to microcoding and CISC was the huge cost
of memory. From CPU hardware design point of view it would be nice if
the ALU function (ADD/SUB/AND/OR) and each data path (data selector)
could be directly controlled by a bit in the instruction word.
Unfortunately, for most instructions, there are a lot of "Don't care"
bits, wasting a lot of expensive core memory bits.

One way to avoid this is to use some compact instruction set in core
memory and then use a complex instruction set decoder built from
random logic to generate all the control point signals needed by the
actual CPU hardware. At some point this became too complex and memory
chips were used to convert the compacted instruction set to generate
the individual data path control signals.

In addition, some sequences were common, so it made sense to generate
multiple long instruction word sequences using this compact to
expanded microcode store. Core main memory was slow (about 1 us) so if
the fast semiconductor microcode control store could generate multiple
hardware sequences during that, this was definitively a win. This also
further reduced the number of instruction needed to be stored in the
main program memory.

With the drop of memory prices and when caches become popular, it
became realistic to use long memory words to (more or less) directly
control each data path in the CPU and skip the microcode control
store.

Regarding CISC/RISC development, one might study the instruction set
of the 16 bit Data General Nova from the 1970's. Some instruction set
bits controlled directly the 74181 ALU chip function bits, some the
Carry_In to that chip and some bits were used to control the data
selectors.