Varför finns inte ' WDC 65816 i “ externt ” 16-bitarsversioner?

65816 har fysiskt en 8-bitars ALU, även om många av de interna registren nu är 16 bitar breda. Det tar därför en extra cykel att utföra varje ALU-operation i 16-bitarsläge, och detta ger användbar tid som behövs för att få extra data över databussen (vilket förblir väldigt enkelt att gränssnitt).

Där är ingen del av kärnan där en 16-bitars databuss är tillgänglig för exponering, även i de semi-anpassade versionerna av 65816-kärnan som WDC fortfarande erbjuder för inbyggda systemutvecklare.

Det skulle naturligtvis vara kunna utforma en ny kärna med en bredare ALU och extern databuss, och därmed med högre prestanda vid 16-bitarsoperationer. Det skulle till och med vara möjligt att införa pipelining och caching för att ytterligare förbättra prestanda. Men resultatet skulle bara vara 65816 ISA-kompatibelt; det skulle inte vara en 65816. Det skulle också vara större, mer energikrävande, dyrare (inte minst på grund av det mer komplexa paket som krävs för att exponera den bredare bussen) och mycket mindre hobbyvänligt.

Kommentarer

• Enligt databladet ( datasheets.chipdb.org/Western%20Design/w65c816s .pdf ) har W65C816 en fullständig 16-bitars ALU.
• @StarCat Intressant punkt. När jag tittar på instruktionstiderna undrar jag varför de skulle bry sig: det ser ut som om de verkligen kunde klara sig bra med en 8-bitars ALU. (Även instruktioner som INX är fortfarande två cykler.) Kanske säger de att programmeraren ’ ser på den som en 16- bit ALU (det vill säga det finns 16-bitars tilläggsinstruktioner etc.), precis som en programmerare hittar Z80 ’ s 4 -bit ALU som inte kan skiljas från 8085 ’ s 8-bitars ALU?
• 65816 har en 16-bitars ALU. Detta är mest synligt när man jämför grenar, som fungerar samma i både native och emuleringsläge (8 bit offset), men får inget straff för sidkorsning i native mode, medan detta fortfarande sker i emulering (och på 65C02). Det är lika synligt med alla direkta sidoperationer, hantering av sidkorsning också utan straff.DP i emuleringsläge visar vidare att här ALU helt enkelt får ’ nedåt ’ till 8 bitar, eftersom DH inte ’ t måste ställas in på noll, btu ignoreras.
• @StarCat Hela citatet är: ” Full 16-bitars ALU, Ackumulator-, stackpekare- och indexregister ” – som bara kan skrivas klumpigt men verkar antyda att endast register är 16 bitar breda. Prestandaegenskaperna för en 16-bitars ALU observeras dock inte lätt i denna CPU, eftersom de flesta operander (inklusive minnesadresser) måste laddas från minnet 8 bitar åt gången. Även om ALU: s hela bredd används för att beräkna lägesberäkningar, noterar jag att om DPR inte är sidinriktad, tar direktlägesåtkomster en 1-cykelstraff som överensstämmer med en 8-bitars ALU.
• @Raffzahn Med 16-bitarsindex måste ett fullständigt 16-bitars tillägg utföras mellan basadressen och indexförskjutningen. Det verkar som att detta inte kan startas förrän basadressen har laddats helt, möjligen på grund av brist på interna register. Att det sedan tar två cykler för en 16 + 16-tillägg, men bara en cykel för en 16 + 8-tillägg, visar att det finns en 8-bitars adderare med övre byte-bärförökning som används för detta ändamål.

65816 är avsedd som en uppgraderingsväg till befintliga 6502-kunder. Att hålla det 8 bitar var ett vettigt beslut från en användarvy eftersom det erbjuder

• Enkel uppgradering av befintliga mönster
• Fullt kompatibel med befintlig programvara
• Standard 40-stiftspaket behöver mindre genom hål och erbjuder billigare hantering
• Endast en enda spärr behövs för att använda det utökade adressområdet
• Endast standard 8-bitars externa komponenter behövs

Speciellt de senare är viktiga för kostnadsöverväganden. För tillverkning räknas varje hål, eftersom det går ner i tid för att borra och därmed kosta. 1983 var 16-bitars komponenter (RAM / ROM) ganska sällsynta och dyra. Med en 8-bitars design definierades ett antal standard (EP) ROM- och RAM-chips precis efter den storlek som behövs, medan en 16-bitars databuss alltid kräver minst två av vardera. När allt kommer omkring, vilken design tidigare prototyp tillstånd inte är kostnadskänslig. 65xx-serien var alltid inriktad på en låg kostnad / inbäddade applikationer. Faktum är att dess målmarknad var ungefär som Intel tänkt för 8086 som en uppgraderingsväg för 8080 / 85 användare.

Till skillnad från Intel, som designade en 16-bitars CPU och gjorde 8-bitars kompatibel (* 1), förblev WDC 8 bitar vilket var meningsfullt för CPU-design eftersom det förenklar utvecklingen på grund

• Grundläggande intern struktur kunde hållas från 65C02
• Inga ändringar i grundläggande adressgenerering
• inget behov av att lägga till ett 8/16 bitars bussprotokoll för åtkomst av byte i ett ord
• inget behov av instruktionsköhantering

På den vägen hölls hela projektet tillräckligt litet för att hanteras av resurser som ett litet företag som WDC kunde tillhandahålla – utan att lägga framtida i riskzonen.

Förutom att vara jämförelsevis lätt att skapa, går en 16-bitars buss inte så mycket som man kan anta först. Trots allt handlar prestanda mycket om minnesbandbredd, är det inte? 8088 mot 8086 är ett bra riktmärke här, eftersom båda använder exakt samma EU (Execution Unit; * 1) medan de bara skiljer sig åt i bussbredden BIU ( Bussgränssnittsenhet) använder för att komma åt minne. Även om 8086 i teorin borde leverera ungefär dubbelt så hög prestanda på grund av att bandbredden fördubblats med samma klockhastighet, är den verkliga prestandaförstärkningen ungefär 30-40%. design fungerar ganska bra för att använda bussen nära 100% (* 2)

Så medan fördubbling av bussbredden alltid kommer att ge mindre än dubbelt så hög hastighet, kommer det bara att fördubbla klockfrekvensen för en design utan någon osäkerhet. År 1983 hade Memory kommit upp till en punkt där en 4 MHz 6500-stildesign var lätt att uppnå, fyrdubblat genomgång utan jitter.

Slutsatsen: Att stanna 8 bitar gav många fördelar i design och för användare, samtidigt som man undviker onödig ansträngning och kostnad.

Sist men inte minst, som en bieffekt skulle 65802 kunna skapas i tillägg, med en ersättning för att använda 16-bitarsfunktioner med i befintliga 65C02-mönster.

* 1 – EU kan för de flesta delar ses som den ”riktiga” CPU-kärnan i 8086

* 2 – Mycket av detta beror på åtkomst till en enda byte, men också med ojusterade minnesord och hoppmål, vilket saktar ner en 16-bitars buss till 8-bitars drift. Och även om ny programvara kan ta hänsyn till detta kommer befintlig inte att göra det. Ett värsta fall exempel här kan vara Applesoft BASIC, var nästan alla pekare på noll sida som på udda adresser. För 8 bitar brydde sig ingen, med 16 bitar är det dödligt.

Fördelen med 8-bitars extern databuss och multiplexering av de översta 8 bitarna i adressbussen i första utgåvan av 65816 verkar tydlig. Det fanns faktiskt två versioner av chipet: W65C816S som beskrivs i frågan och W65C802. Enligt Wikipedia var

[The] 65C802 … identisk inuti till 65C816. Båda producerades på samma tillverkningslinjer och divergerade endast under de senaste metalliseringsstegen när chipet anslöts till de externa stiften. I 65C802 hade dessa stift samma layout som originalet 6502, vilket gjorde det möjligt att använda den som en drop-in-ersättning samtidigt som 16-bitars bearbetning av CPU-enheten fortfarande kunde användas. Eftersom den använde den ursprungliga pinout hade den dock bara 16 adresspinnar och kunde därför bara få åtkomst till 64 kB externt minne. När hårdvarutillverkare utformade ett projekt från grunden använde de vanligtvis 65C816 snarare än 65C802, vilket resulterade i att den senare drogs ur produktionen.

Men detta förklarar inte varför alla versioner av 65816 fortsatte att använda det externa 8-bitarsgränssnittet även efter att 65802 avbröts.

Jag antar att svaret är enkelt: det finns inget behov av en sådan version av 65C816 idag. Western Design Center (WDC), 65C816-tillverkaren, fokuserar på IP-adresser och IoT-saker. Jag antar att den ”nya 65C816” -produktionen är en slags nostalgi för dem. Chip- och paketrevision har inget tydligt affärsfall, IMHO.

En annan fråga är ”varför det fanns ingen 16-bitars databussversion redan på 80-talet?” Den rimliga förklaringen är: det var en sekvens av externa händelser. Marknaden rörde sig troligen snabbare än WDC förväntade sig. Under första hälften av 80-talet, när 65C816 introducerades, installerade 8-bitars databussen b efter de system som redan är konstruerade för 6502-chipet och marknaden kräver inte en 16-bitars databuss. Senare, när 16-bitars kringutrustning blev tillgänglig, erbjöd 65C816-tillverkaren inte ”nästa generations” CPU i tid, så de största kunderna, som Apple (// GS) eller Nintendo (SNES), gick till det bättre, snabbare osv. processorer (Motorola, NEC MIPS, …) när de designade en ny generation av hårdvara. Detta drag gjorde ”16bit databuss 65C816” föråldrad innan den skapades.

Kommentarer

• Det verkar för mig att Apple aldrig ” gick vidare till bättre, snabbare processorer ”; IIgs var slutet av raden för Apple II och den fortsatte att använda ’ 816 fram till 1992. (Apple använde 68000 i Mac, men beslutet fattades i i slutet av 1980, långt innan ’ 816 började utvecklas.) Och Nintendo startade ’ inte utvecklingen av SNES fram till tidigast 1988, fem år efter lanseringen av ’ 816.
• Det är sant att Mac vs. II är olika utvecklingar. Trots framgången med Apple IIgs, med bara 1,25 M-enheter, var Apple långt ifrån deras största kunder. SNES-siffrorna är cirka 50 M, räknas inte kloner. Och det finns en hel del andra inbäddade applikationer i den regionen. I allmänhet har stationära datorer varit den mest synliga användningen av 6502 för oss, men de är totalt sett bland de minst viktiga. Till och med att lägga till alla Commodore, Apple, BBC och så vidare kommer bara att använda mindre än 1% av alla 65xxx-kärnor som någonsin byggts.