Skrivet av pv2b:
Intressant tanke: Vad är det som hindrar att en processor (kanske en Zen, kanske en Intel) skulle ha två olika frontends samtidigt? Som det går att växla mellan. Ungefär som att växla mellan 32-bitars och 64-bitars läge. Alltså, något man skulle göra på processnivå i operativsystemet.
Du skulle alltså kunna kompilera om ett program till en ARM-binär och plötsligt så skulle du kunna köra ARM-program snabbare än motsvarande x86 eller x64-program utan att för den sakens skull vara långsammare på x86/x64?
Finns flera CPU-modeller med två front-ends. Ett väldigt närliggande exempel är alla ARM modeller som stödjer både 32-bitars ARM och 64-bitars ARM, även om många instruktioner ser snarlika ut i assembler har de inte alls samma binära representation.
Problemet med en CPU med kombinationen x86_64 + ARM64 (egentligen Aarch64) är att front-end på en high-end x86 äter väldigt med transistorer!
Apples A12-systemkrets är runt 80-85 mm², det inkluderar då en relativt kompetent GPU och en kiselmässigt ungefär lika stor "NPU" (network processing unit).
Enligt AnandTechs mätningar i bilden ovan är tar de två Vortex kärnor plus de fyra små kärnorna (Tempest) 12 mm², det inklusive cache. "Små" kärnor är här rätt mycket inom citationstecken då AnandTechs uppföljande artikel konstaterar att dessa har högre IPC än ARM Cortex A73 som i sin tur ligger någonstans mellan dagens Atom och Zen/Skylake (Atom är inte alls var det en gång i tiden var, IPC är numera på Core2 nivå).
Ett CCX tar, enligt AMD, 44 mm². Det är det är alltså fyra kärnor mot Apples kärnor. I båda fallen är CPU-cache inräknat. D.v.s. trots att Apple har en långt bredare front-end och en långt bredare back-end tar det mindre yta än vad ett CCX kommer ta även om det blir "perfekt" skalning (säger inte TSMC upp till 60 % högre densitet för icke SRAM?)
Sedan finns det andra saker. Aldrig tänkt på varför både Intel och AMD stannat på 32 kB L1D$?
Orsaken är att L1D$ är extremt latenskritiskt, om man ser till att varje "grupp" (cache set) i cachen är exakt 4 kB så kan man slå upp i L1D$ parallellt med uppslagningen av virtuell-till-fysisk mappning (cache som kallas TLB).
Man vill inte gärna ha mer än 8 grupper i en L1$ cache, ju fler grupper ju mer ström drar det! Vidare kan man bara göra tricket med parallell uppslagningen om varje grupp är lika stor (eller mindre) än en adress-sida (page), som på x86 är 4 kB i normalfallet. Finns även 2 MB adress-sidor, men det fungerar inte att rent praktiskt att bara köra dessa så man är fast med 4 kB.
ARM stödjer 4 kB, 16 kB samt 64 kB. Apple har droppat stödet för 4 kB, vilket betyder att man kan ha en 8 gruppers L1$ på 128 kB och ändå stödja parallell uppslagning av TLB. Kan bara göras på x86 om man bryter bakåtkompatibilitet.
Vidare: x86 specificerade sin minnesmodell i en tid när multicore knappt fanns. Måste finnas en väldigt exakt definition av vad olika CPU-kärnor kan förvänta sig när det kommer till läsning/skrivning mot RAM. x86 har en extremt "strikt" minneskonsistensmodell -> enkelt för människor att resonera kring, men värdelöst när det kommer till optimeringspotential (något Nvidia Jensen brukar framhålla, GPUer ligger på andra extremen, extremt "lös" minneskonsistensmodell).
64-bitars ARM har en minneskonsistensmodell som är en perfekt match till vad bl.a. C++, Java och C# förväntar sig -> multitrådade program blir mer optimalt. Frågan är hur enkelt/effektivt det skulle bli att designa en back-end som både hanterar ARM och x86.
AMD tänkte ju göra just det med Zen, d.v.s man tänkte designa två CPUer med i princip samma back-end. Det var alltså två separata kretsar, inte en med två front-ends. ARM64 varianten hade kodnamnet K12, men lanserades aldrig. Frågan är om man stötte på tekniska problem eller om man bara insåg att det skulle försämra fokus?