Hvorfor er ' ikke WDC 65816 tilgjengelig i “ eksternt ” 16-biters versjoner?

65816 har fysisk en 8-bit ALU, selv om mange av de interne registerene nå er 16 bits brede. Det tar derfor en ekstra syklus å utføre hver ALU-operasjon i 16-biters modus, og dette gir nyttig tid som trengs for å få ekstra data over databussen (som fortsatt er veldig enkel å grensesnitt).

Der er ingen del av kjernen der en 16-bits databuss er tilgjengelig for eksponering, selv i semi-tilpassede versjoner av 65816-kjernen som WDC fremdeles tilbyr for innebygde systemutviklere.

Det ville selvfølgelig vært være mulig å designe en ny kjerne med en bredere ALU og ekstern databuss, og dermed med høyere ytelse på 16-biters operasjoner. Det ville til og med være mulig å innføre rørledning og hurtigbufring for ytterligere å forbedre ytelsen. Men resultatet ville bare være 65816 ISA-kompatibelt; det ville ikke være en 65816. Det ville også være større, mer strømkrevende, dyrere (ikke minst på grunn av den mer komplekse pakken som kreves for å eksponere den bredere bussen), og mye mindre hobbyvennlig.

Kommentarer

• I henhold til databladet ( datasheets.chipdb.org/Western%20Design/w65c816s .pdf ), har W65C816 en full 16-bit ALU.
• @StarCat Interessant punkt. Ser jeg på instruksjonstidene, lurer jeg på hvorfor de ville bry seg, skjønt: det ser ut til at de virkelig kunne klare seg helt fint med en 8-bit ALU. (Selv instruksjoner som INX er fortsatt to sykluser.) Kanskje sier de at programmereren ‘ s syn på det er som en 16- bit ALU (det vil si at det er 16-biters instruksjoner for å legge til osv.), akkurat som en programmerer finner Z80 ‘ s 4 -bit ALU som ikke skiller seg fra 8085 ‘ s 8-bit ALU?
• 65816 har en 16 bit ALU. Dette er mest synlig når man sammenligner grener, som fungerer likt både i native og emuleringsmodus (8 bit offset), men får ingen straff for sideovergang i native mode, mens dette fremdeles forekommer i emulering (og på 65C02). Det er like synlig med all direkte sideoperasjon, håndtering av sidekryssing også uten straff.DP i emuleringsmodus viser videre at her får ALU rett og slett ‘ senket ‘ til 8 bit, ettersom DH ikke ‘ t trenger å settes til null, btu blir ignorert.
• @StarCat Det fulle tilbudet er: » Full 16-bit ALU, Akkumulator-, stakkpeker- og indeksregister » – som kanskje bare er klossete skrevet, men ser ut til å antyde at bare registre er 16 bits brede. Imidlertid blir ytelsesegenskapene til en 16-biters ALU ikke lett observert i denne CPUen, fordi de fleste operander (inkludert minneadresser) må lastes fra minnet 8 bits om gangen. Selv om hele bredden på ALU brukes til adresseringsmodusberegninger, bemerker jeg at hvis DPR ikke er sidelinjert, tar direkte modus tilgang en 1-syklus straff som er i samsvar med en 8-bit ALU.
• @Raffzahn Med 16-biters indekser må det utføres et fullstendig 16-bits tillegg mellom basisadressen og indeksforskyvningen. Det ser ut til at dette ikke kan startes før basisadressen er fullstendig lastet, muligens på grunn av mangel på interne registre. At det deretter tar to sykluser for en 16 + 16-tilsetning, men bare en syklus for en 16 + 8-tilsetning, viser at det er en 8-biters hugger med øvre byte-forplantning som brukes til dette formålet.

65816 er ment som en oppgraderingsbane til eksisterende 6502 kunder. Å holde det 8 bit var en fornuftig beslutning fra et brukerbilde, da det tilbyr

• Enkel oppgradering av eksisterende design
• Fullt kompatibel med eksisterende programvare
• Standard 40-pinners pakke trenger mindre gjennom hull og gir billigere håndtering
• Bare en enkelt sperre er nødvendig for å bruke det utvidede adresseområdet
• Bare standard 8-biters eksterne komponenter er nødvendig

Spesielt det siste er viktig for kostnadsvurderingen. For produksjon teller hvert hull, ettersom det går ned i tide å bore og dermed koste. I 1983 var 16-biters komponenter (RAM / ROM) ganske sjeldne og dyre. Med en 8-biters design ble en rekke standard (EP) ROM- og RAM-brikker definert bare etter størrelsen som trengs, mens en 16-bits databuss alltid krever minst to av hver. Tross alt, hvilken design tidligere prototypetilstand ikke er følsom. 65xx-serien var alltid målrettet mot lave kostnader / innebygde applikasjoner. Faktisk var målmarkedet omtrent som Intel anså for 8086 som en oppgraderingsbane for 8080 / 85 brukere.

I motsetning til Intel, som designet en 16-biters CPU og gjorde 8-biters kompatibel (* 1), forble WDC 8 bit som var fornuftig for CPU-design da det forenklet utviklingen på grunn

• Grunnleggende intern struktur kan holdes fra 65C02
• Ingen endringer i generering av grunnleggende adresse
• ikke behov for å legge til en 8/16 bit bussprotokoll for å få tilgang til byte i et ord
• ikke behov for ledelse av instruksjonskøer

På den måten ble hele prosjektet holdt lite nok til å bli håndtert av ressurser et lite selskap som WDC kunne tilby – uten å sette fremtid i fare.

Foruten å være relativt enkel å lage, går ikke 16-biters buss så mye som man kan anta i begynnelsen. Tross alt handler ytelse mye om minnebåndbredde, er det ikke det? 8088 mot 8086 er et flott målestokk her, da begge bruker nøyaktig samme EU (Execution Unit; * 1) mens de bare er forskjellige i bussbredden til BIU ( Bus Interface Unit) bruker for å få tilgang til minne. Selv om 8086 i teorien burde levere omtrent dobbelt så god ytelse på grunn av dobling av båndbredden med samme klokkehastighet, er den virkelige verdens ytelsesøkning omtrent 30-40%. design fungerer ganske bra i å bruke bussen nær 100% (* 2)

Så mens dobling av bussbredden alltid vil gi mindre enn dobbelt hastighet, vil det bare doble klokkefrekvensen til et design. uten usikkerhet. Innen 1983 hadde Memory kommet opp til et punkt der en 4 MHz 6500-stildesign var lett å oppnå, firedoblet gjennomgang uten jitter.

Poenget: Å bo 8 bit ga mange fordeler i design og for brukere, samtidig som man unngår unødvendig innsats og kostnader.

Sist men ikke minst, som en bivirkning, kan 65802 opprettes i tillegg, og tilbyr et fall i erstatning for å bruke 16-biters funksjoner med i eksisterende 65C02-design.

* 1 – For de fleste deler kan EU sees på som den «virkelige» CPU-kjernen i 8086

* 2 – Mye av dette kommer på grunn av tilgang til enkeltbyte, men også av ujusterte minneord og hoppmål, som vil bremse en 16-biters buss ned til 8-biters drift. Og mens ny programvare kan ta hensyn til dette, vil eksisterende ikke. Et eksempel på verste fall her kan være Applesoft BASIC, var nesten alle pekere på null side som på rare adresser. For 8 bit brydde ingen seg, med 16 bit er det dødelig.

Fordelen med 8-biters ekstern databuss og multiplexing av de øverste 8 bitene i adressebussen i første utgivelse av 65816 virker tydelig. Det var faktisk to versjoner av brikken: W65C816S som beskrevet i spørsmålet og W65C802. I følge Wikipedia ,

[The] 65C802 … var identisk inne i 65C816. Begge ble produsert på de samme fabrikasjonslinjene og divergerte bare i løpet av de siste metalliseringsstadiene da brikken ble koblet til de eksterne pinnene. I 65C802 hadde disse pinnene samme oppsett som den opprinnelige 6502, som gjorde det mulig å bruke den som utskiftningsbytte, samtidig som 16-biters prosessering av CPU-en kunne brukes. Da den brukte den opprinnelige pinouten, hadde den imidlertid bare 16 adressepinner, og kunne derfor bare få tilgang til 64 kB eksternt minne. Når maskinvareprodusenter designet et prosjekt fra grunnen av, brukte de vanligvis 65C816 i stedet for 65C802, noe som resulterte i at sistnevnte ble trukket fra produksjonen.

Men dette forklarer ikke hvorfor alle versjoner av 65816 fortsatte å bruke det eksterne 8-biters grensesnittet selv etter at 65802 ble avviklet.

Jeg antar at svaret er enkelt: det er ikke behov for en slik versjon av 65C816 i dag. Western Design Center (WDC), 65C816-produsenten, fokuserer på IP-er og IoT-ting. Jeg antar at den «nye 65C816» -produksjonen er en slags nostalgi for dem. Chip og pakkerevisjon har ingen klar business case, IMHO.

Et annet spørsmål er «hvorfor det ikke var noen 16bit databussversjon tilbake på 80-tallet?» Den rimelige forklaringen er: det var en sekvens av eksterne hendelser. Markedet beveget seg sannsynligvis raskere enn WDC forventet. I første halvdel av 80-tallet, da 65C816 ble introdusert, monterte 8bit databussen b etter til systemene som allerede er designet for 6502-brikken, og markedet krever ikke en 16-biters databuss. Senere, da 16-biters periferiutstyr ble tilgjengelig, tilbød ikke 65C816-produsenten «neste generasjons» CPU i tide, så de største kundene, som Apple (// GS) eller Nintendo (SNES), flyttet til det bedre, raskere osv. prosessorer (Motorola, NEC MIPS, …) når de designet en ny generasjon av maskinvaren. Dette trekket gjorde «16bit databuss 65C816» foreldet før den ble opprettet.

Kommentarer

• Det virker for meg at Apple aldri » gikk videre til bedre, raskere prosessorer «; IIgs var slutten på linjen for Apple II, og den fortsatte å bruke ‘ 816 til 1992. (Apple brukte 68000 i Mac, men avgjørelsen ble tatt i sent på 1980, lenge før ‘ 816 startet utvikling.) Og Nintendo startet ikke ‘ utviklingen av SNES tidligst til 1988, fem år etter utgivelsen av ‘ 816.
• Sant, Mac vs II er forskjellige utviklinger. Til tross for suksessen til Apple IIgs, med bare 1,25 M-enheter, var Apple langt fra å være deres største kunder. SNES-tallene er rundt 50 M, medregnet ikke kloner. Og det er ganske mange andre innebygde applikasjoner i den regionen. Generelt har stasjonære datamaskiner vært den mest synlige bruken av 6502 for oss, men de er totalt sett blant de minst viktige. Selv å legge til alle Commodore, Apple, BBC og så videre, vil bare ende opp med å bruke mindre enn 1% av alle 65xxx-kjerner som noen gang er bygget.