Själv är jag skeptisk till hela CISC konceptet faktiskt, tycker RISC är mer tilltalade för mig som utvecklare eftersom jag hela tiden har 100% koll på saker och ting. När det kommer till x86 kan jag i extrem exemplet köra samma kod två gånger och få olika resultat och det är inget för mig.
Den här typen av klagomål tycker jag mig se rätt ofta från personer som anser att x86 är en dålig arkitektur, det som alltid saknas är konkreta exempel. Vad exakt för korrekt program kan du köra som ger olika resultat på x86 men inte på t.ex. ARM?
Faktum är att jag kan väldigt enkelt visa exakta motsatsen, program som är deterministiskt och korrekt på x86 men som man med enkel analys kan se inte ens är garanterat att någonsin köras färdigt på ARM, atomic_inc_and_return(atomic_t *v) d.v.s. atomärt addera 1 och retunera resultatet. Väldigt enkelt, eller hur?
På x86 ser detta så här både för uni-processor och multiprocessor
lock xadd 0x1, (ptr to v)
På ARM där man potentiellt kör med flera CPU-kärnor ser det ut så här
movs <register1>, #1
dmb
1:
ldrex <register2>, (ptr to v)
add <register2>, <register1>
strex <register3>, <register2>, (ptr to v)
teq <register3>, #0
bne 1b
dmb
Vilken version tror du är snabbast? ARM versionen kör 4 dyra instruktioner
"dmb" (Data Memory Barrier) skapar pipe-line stalls och man behöver 2 sådana för att det ska bli korrekt! "lock" prefix på en instruktion medför implicit barriär på x86 så man kan inte göra fel + CPU kan göra optimeringar då den "vet" att man ska köra en read-add-write mot RAM då det är vad xadd gör.
"ldrex" (load with reserve) är inte heller gratis
Och slutligen "strex" (store conditional) är inte billig och det finns inte heller någon garanti för hur många gånger denna instruktion misslyckas vilket resulterar i en evighetsloop då man måste köra om allt från "1:".
Ovanpå detta krävs också 3 register och inget register på x86...
Så fort man börjar jobba med multicore system så känns x86 som en långt mycket bättre design än RISC just p.g.a. av saker som ovan (ARM, PPC och MIPS fungerar mer eller mindre på exakt samma sätt här).
Andra gör sig lustig över att Pentium räknade fel för 15 år sedan, den man verkar blunda för är den errata som t.ex. moderna ARM CPU:er har. Det är förvånande många fel i Cortex A8 och A9 med tanke på hur simpla dessa är jämfört med Sandy och Ivy Bridge. Atom har inte haft i närheten så många buggar som A8/A9.
Några axplock på buggar i A9
Detta bug har jag hört folk svära om i korridorerna på jobbet då den har klar negativ inverkan på effektiviteten på program som använder flera CPU-kärnor
erratum 764369:
affecting Cortex-A9< MPCore with two or more processors (all
current revisions). Under certain timing circumstances, a data
cache line maintenance operation by MVA targeting an Inner
Shareable memory region may fail to proceed up to either the
Point of Coherency or to the Point of Unification of the
system. This workaround adds a DSB instruction before the
relevant cache maintenance functions and sets a specific bit
in the diagnostic control register of the SCU.
Andra exempel på workarounds till buggar i Cortex A9 som finns i Linux-kärnan
config ARM_ERRATA_742231
bool "ARM errata: Incorrect hazard handling in the SCU may lead to data corruption"
depends on CPU_V7 && SMP
help
This option enables the workaround for the 742231 Cortex-A9
(r2p0..r2p2) erratum. Under certain conditions, specific to the
Cortex-A9 MPCore micro-architecture, two CPUs working in SMP mode,
accessing some data located in the same cache line, may get corrupted
data due to bad handling of the address hazard when the line gets
replaced from one of the CPUs at the same time as another CPU is
accessing it. This workaround sets specific bits in the diagnostic
register of the Cortex-A9 which reduces the linefill issuing
capabilities of the processor.
config PL310_ERRATA_588369
bool "PL310 errata: Clean & Invalidate maintenance operations do not invalidate clean lines"
depends on CACHE_L2X0
help
The PL310 L2 cache controller implements three types of Clean &
Invalidate maintenance operations: by Physical Address
(offset 0x7F0), by Index/Way (0x7F8) and by Way (0x7FC).
They are architecturally defined to behave as the execution of a
clean operation followed immediately by an invalidate operation,
both performing to the same memory location. This functionality
is not correctly implemented in PL310 as clean lines are not
invalidated as a result of these operations.
config ARM_ERRATA_720789
bool "ARM errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID"
depends on CPU_V7
help
This option enables the workaround for the 720789 Cortex-A9 (prior to
r2p0) erratum. A faulty ASID can be sent to the other CPUs for the
broadcasted CP15 TLB maintenance operations TLBIASIDIS and TLBIMVAIS.
As a consequence of this erratum, some TLB entries which should be
invalidated are not, resulting in an incoherency in the system page
tables. The workaround changes the TLB flushing routines to invalidate
entries regardless of the ASID.
config ARM_ERRATA_743622
bool "ARM errata: Faulty hazard checking in the Store Buffer may lead to data corruption"
depends on CPU_V7
help
This option enables the workaround for the 743622 Cortex-A9
(r2p*) erratum. Under very rare conditions, a faulty
optimisation in the Cortex-A9 Store Buffer may lead to data
corruption. This workaround sets a specific bit in the diagnostic
register of the Cortex-A9 which disables the Store Buffer
optimisation, preventing the defect from occurring. This has no
visible impact on the overall performance or power consumption of the
processor.
config ARM_ERRATA_751472
bool "ARM errata: Interrupted ICIALLUIS may prevent completion of broadcasted operation"
depends on CPU_V7
help
This option enables the workaround for the 751472 Cortex-A9 (prior
to r3p0) erratum. An interrupted ICIALLUIS operation may prevent the
completion of a following broadcasted operation if the second
operation is received by a CPU before the ICIALLUIS has completed,
potentially leading to corrupted entries in the cache or TLB.
config ARM_ERRATA_754322
bool "ARM errata: possible faulty MMU translations following an ASID switch"
depends on CPU_V7
help
This option enables the workaround for the 754322 Cortex-A9 (r2p*,
r3p*) erratum. A speculative memory access may cause a page table walk
which starts prior to an ASID switch but completes afterwards. This
can populate the micro-TLB with a stale entry which may be hit with
the new ASID. This workaround places two dsb instructions in the mm
switching code so that no page table walks can cross the ASID switch.
config ARM_ERRATA_754327
bool "ARM errata: no automatic Store Buffer drain"
depends on CPU_V7 && SMP
help
This option enables the workaround for the 754327 Cortex-A9 (prior to
r2p0) erratum. The Store Buffer does not have any automatic draining
mechanism and therefore a livelock may occur if an external agent
continuously polls a memory location waiting to observe an update.
This workaround defines cpu_relax() as smp_mb(), preventing correctly
written polling loops from denying visibility of updates to memory.
Jämför det med errata Linux har för x86, den innefattar fix för FPU buggen i Pentium och den s.k. "foo" buggen i Pentium II, sedan finns inga andra workarounds.
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
