Hvorfor er ' ikke WDC 65816 tilgængelig i “ eksternt ” 16-bit versioner?

65816 har fysisk en 8-bit ALU, selvom mange af de interne registre nu er 16 bit brede. Det tager derfor en ekstra cyklus at udføre hver ALU-operation i 16-bit-tilstand, og dette giver nyttigt den nødvendige tid til at få de ekstra data over databussen (som forbliver meget enkel at interface).

Der er ingen del af kernen, hvor en 16-bit databus er tilgængelig til eksponering, selv i semi-brugerdefinerede versioner af 65816-kernen, som WDC stadig tilbyder til integrerede systemudviklere.

Det ville selvfølgelig være være muligt at designe en ny kerne med en bredere ALU og ekstern databus og dermed med højere ydelse på 16-bit operationer. Det ville endda være muligt at indføre rørledning og caching for yderligere at forbedre ydeevnen. Men resultatet ville kun være 65816 ISA-kompatibelt; det ville ikke være en 65816. Det ville også være større, mere strømhungrigt, dyrere (ikke mindst på grund af den mere komplekse pakke, der kræves for at udsætte den bredere bus) og meget mindre hobbyvenlig.

Kommentarer

• Ifølge databladet ( datasheets.chipdb.org/Western%20Design/w65c816s .pdf ), W65C816 har en fuld 16-bit ALU.
• @StarCat Interessant punkt. Når jeg ser på instruktionstiderne, spekulerer jeg på, hvorfor de ville gider: Det ser ud til, at de virkelig kunne klare sig fint med en 8-bit ALU. (Selv instruktioner som INX er stadig to cyklusser.) De siger måske, at programmørens ‘ syn på det er som en 16- bit ALU (dvs. der er 16-bit tilføjelsesinstruktioner osv.), ligesom en programmør finder Z80 ‘ s 4 -bit ALU , der ikke kan skelnes fra 8085 ‘ s 8-bit ALU?
• 65816 har en 16 bit ALU. Dette er mest synligt, når man sammenligner grene, der fungerer ens i native såvel som emuleringstilstand (8 bit offset), men får ingen straf for sidekrysning i native-tilstand, mens dette stadig forekommer i emulering (og på 65C02). Det er lige så synligt med alle direkte sideoperationer, håndtering af sidekrysning også uden straf.DP i emuleringstilstand viser yderligere, at ALU her får ‘ nedad ‘ til 8 bit, da DH ikke ‘ skal ikke sættes til nul, btu ignoreres.
• @StarCat Det fulde citat er: ” Fuld 16-bit ALU, Akkumulator-, stakpointer- og indeksregistre ” – som måske bare skrives klodset, men synes at antyde, at kun registre er 16 bit brede. Imidlertid overholdes ydeevneegenskaberne for en 16-bit ALU ikke let i denne CPU, fordi de fleste operander (inklusive hukommelsesadresser) skal indlæses fra hukommelsen 8 bit ad gangen. Selvom ALUs fulde bredde bruges til adressering af tilstandsberegninger, bemærker jeg, at hvis DPR ikke er sidejusteret, tager Direct Mode-adgang en 1-cyklus-straf, der er i overensstemmelse med en 8-bit ALU.
• @Raffzahn Med 16-bit-indekser skal der udføres en fuld 16-bit tilføjelse mellem basisadressen og indeksforskydningen. Det ser ud til, at dette ikke kan startes, før basisadressen er fuldstændigt indlæst, muligvis på grund af mangel på interne registre. At det derefter tager to cyklusser for en 16 + 16-tilføjelse, men kun en cyklus for en 16 + 8-tilføjelse, viser at der er en 8-bit adder med øvre-byte-bæreformering, der bruges til dette formål.

65816 er beregnet som en opgraderingssti til eksisterende 6502 kunder. At holde det 8 bit var en fornuftig beslutning fra en brugervisning, da den tilbyder

• Nem opgradering af eksisterende designs
• Fuldt kompatibel med eksisterende software
• Standard 40-pin-pakke har brug for mindre gennem huller og giver billigere håndtering
• Kun en enkelt lås er nødvendig for at bruge det udvidede adresseområde
• Kun standard 8 bit eksterne komponenter er nødvendige

Især de senere er vigtige for omkostningsovervejelse. Til fremstilling tæller hvert hul, da det går ned i tide til at bore og dermed koste. I 1983 var 16 bit komponenter (RAM / ROM) ret sjældne og dyre. Med et 8-bit design blev et antal standard (EP) ROM- og RAM-chips defineret lige efter den nødvendige størrelse, mens en 16-bit databus altid kræver mindst to af hver. Når alt kommer til alt, hvilket design forbi prototypetilstand ikke er følsomt. 65xx-serien var altid målrettet mod lave omkostninger / indlejrede applikationer. Faktisk var dens målmarked meget lig Intel, som 8086 havde forestillet sig at være en opgraderingssti til 8080 / 85 brugere.

I modsætning til Intel, der designede en 16 bit CPU og gjorde 8 bit kompatibel (* 1), forblev WDC 8 bit, hvilket gav mening for CPU-design, da det forenklede udviklingen på grund

• Grundlæggende intern struktur kunne holdes fra 65C02
• Ingen ændringer i generering af grundlæggende adresse
• intet behov for at tilføje en 8/16 bit busprotokol for at få adgang til bytes i et ord
• intet behov for ledelse af instruktionskøer

På den måde blev hele projektet holdt lille nok til at blive håndteret af ressourcer, som en lille virksomhed som WDC kunne levere – uden at sætte fremtid i fare.

Udover at være sammenligneligt let at oprette vinder en 16-bit bus ikke så meget som man kan antage i starten. Når alt kommer til alt handler ydeevne meget om hukommelsesbåndbredde, er det ikke det? 8088 vs. 8086 er et godt benchmark her, da begge bruger nøjagtigt den samme EU (Execution Unit; * 1), mens de kun adskiller sig i busbredden BIU ( Bus Interface Unit) bruger til at få adgang til hukommelse Mens 8086 i teorien skulle levere ca. det dobbelte af ydelsen på grund af en fordobling af båndbredden med den samme urfrekvens, er den virkelige verdens ydeevne kun omkring 30-40%. Dette er endnu mere bemærkelsesværdigt som BIU design fungerer ganske godt ved at udnytte bussen tæt på 100% (* 2)

Så mens en fordobling af busbredden altid vil levere mindre end dobbelt så høj hastighed, vil det blot fordoble et frekvens for et design uden usikkerhed. I 1983 var hukommelsen kommet op til et punkt, hvor et 4 MHz 6500-stildesign var let at opnå, firdoblet thruput uden nogen jitter.

Bundlinje: At forblive 8 bit gav mange fordele i design og for brugere, samtidig med at man undgår unødvendig indsats og omkostninger.

Sidst men ikke mindst, som en bivirkning, kunne 65802 desuden oprettes og tilbyde et fald i erstatning for at bruge 16-bit-funktioner med i eksisterende 65C02-designs.

* 1 – For de fleste dele kan EU ses som den “rigtige” CPU-kerne i 8086

* 2 – Meget af dette skyldes adgang til enkeltbyte, men også ved ikke-justerede hukommelsesord og springmål, som vil bremse en 16-bit bus ned til 8-bit operation. Og mens ny software kunne tage dette i betragtning, vil eksisterende ikke. Et værste eksempel her kan være Applesoft BASIC, var næsten alle markører på nul side som på ulige adresser. For 8 bit passede ingen, med 16 bit er det dødbringende.

Fordelen ved 8-bit ekstern databus og multiplexering af de øverste 8 bit i adressebussen i første udgivelse af 65816 synes klar. Der var faktisk to versioner af chippen: W65C816S som beskrevet i spørgsmålet og W65C802. Ifølge Wikipedia

[The] 65C802 … var identisk inde i 65C816. Begge blev produceret på de samme fabrikationslinjer og divergerede kun i de sidste metaliseringstrin, da chippen blev forbundet til de eksterne stifter. I 65C802 havde disse stifter det samme layout som den originale 6502, hvilket gjorde det muligt at bruge det som drop-in-erstatning, mens det stadig var muligt at bruge 16-bit-behandling af CPUen. Da den brugte den oprindelige pinout, havde den kun 16 adresseringsstifter og kunne derfor kun få adgang til 64 kB ekstern hukommelse. Når hardwareproducenter typisk designede et projekt fra bunden, brugte de 65C816 snarere end 65C802, hvilket resulterede i, at sidstnævnte blev trukket tilbage fra produktionen.

Men dette forklarer ikke, hvorfor alle versioner af 65816 fortsatte med at bruge den eksterne 8-bit interface, selv efter at 65802 blev afbrudt.

Jeg antager, at svaret er simpelt: der er ikke behov for en sådan version af 65C816 i dag. Western Design Center (WDC), 65C816-producenten, fokuserer på IPer og IoT-ting. Jeg antager, at den “nye 65C816” -produktion er en slags nostalgi for dem. Chip- og pakkeversion har ingen klar business case, IMHO.

Et andet spørgsmål er “hvorfor der ikke var nogen 16bit databusversion tilbage i 80erne?” Den rimelige forklaring er: det var en række eksterne begivenheder. Markedet bevægede sig sandsynligvis hurtigere end WDC forventede. I første halvdel af 80erne, da 65C816 blev introduceret, monterede 8bit databussen b efter til de systemer, der allerede er designet til 6502-chippen, og markedet kræver ikke en 16-bit databus. Senere, da 16-bit-periferiudstyr blev tilgængeligt, tilbød 65C816-producenten ikke “næste generations” CPU i tide, så de største kunder, som Apple (// GS) eller Nintendo (SNES), flyttede til det bedre, hurtigere osv. processorer (Motorola, NEC MIPS, …) når de er designet til en ny generation af deres hardware. Dette træk gjorde “16bit databus 65C816” forældet inden dets egen oprettelse.

Kommentarer

• Det forekommer mig, at Apple aldrig ” gik videre til bedre, hurtigere processorer “; IIgs var slutningen på linjen for Apple II, og den fortsatte med at bruge ‘ 816 indtil 1992. (Apple brugte 68000 i Mac, men beslutningen blev taget i sidst i 1980, længe før ‘ 816 startede udvikling.) Og Nintendo startede ‘ ikke udviklingen af SNES indtil tidligst 1988, fem år efter frigivelsen af ‘ 816.
• Sandt, Mac vs. II er forskellige udviklinger. På trods af succesen med Apple IIgs med kun 1,25 M enheder var Apple langt fra at være deres største kunder. SNES-tal er omkring 50 M, medregnet ikke kloner. Og der er en hel del andre indlejrede applikationer i denne region. Generelt har stationære computere måske været den mest synlige brug af 6502 for os, men de er i alt blandt de mindst vigtige. Selv tilføjelse af al Commodore, Apple, BBC og så videre vil kun ende med at bruge mindre end 1% af alle 65xxx-kerner, der nogensinde er bygget.