Processorarkitektur

16 posts in thread

• Peter Goldmann <5080> · Text 794 · w8 · inlagg

  1987-04-16 21:32

  Ärende: Processorarkitektur

  Finns det numera processorer där alla bussar är separata? Adressbuss Databuss Instruktionsbuss DMA -buss I/O -buss Med en sådan separering skulle processorn bli mycket snabb. Dessutom skulle man kunna ha minnet dynamiskt uppdelat i olika fält/areor och ev ha flera adressbussar en för Dataarean och en för programarean som kunde operera oberoende av varandra. Att man var så snål med trådar/ben tidigare berodde väl på begränsningar i kapslingsteknik. Om man har brottom kunde man ju låta en optisk fiberlänk utgöra snabba bussen för exvis minnet. Ytterligare en fråga: Finns det någon processor som i sig har inbyggt en tolk eller har sina maskininstruktioner så att den direkt förstår MNOMICS. Det borde ju inte vara omöjligt att göra en processor där man istället för 201 skrev RET etc. - borde det inte gå med en grindmatris av snabba sorten? Då skulle man simultant få ut i klartext vad processorn hade för sig och även instruera i klartext. Nästa steg skulle då vara att använda ett lämpligt språk på maskinnära nivå - exvis ?C eller ?FORTRAN och då kunna få processorn att direkt förstå ett språk som är överskådligt för en programmerare. Om man hade en buss på 8x8 trådar skulle man parallelt kunna påföra ord om 8 tecken - dvs instruktioner - i princip som man nu har filnamn när man lagrar på diskett. Det har FÖ förvånat mig att man inte försökt att få de koder som dagens processorer använder att vara lite användarvänliga. Exvis kunde de instruktioner som i MNOMICS börjar på bokstäverna A - F samt 0 som kunde stå för bokstaven O. Alternativt att vissa instruktioner med andra begynnelsbokstäver anslöt till ASCII-värdet decimalt eller i HEX. Kanske det kommer en processor som klarar strukturerad BASIC med en kraft- full BASIC inbyggd och där själva BASIC-processen sker med en speciell processor med kasnke 100MHZ klocka - eftersom avståndet till den area där BASICEN residerar ligger så nära att den höga frekvensen går att genomföra utan att det blir problem med trådar.
  • Mikael Pettersson <2195> · Text 795 · w8 · kommentar

    1987-04-17 00:56

    Ärende: Processorarkitektur

    Framtiden ligger knappast i att slänga ut ett antal Megakronor på att ta fram processorer för att TOLKA BASIC (vilken vedervärdig tanke!). Däremot håller man på med (sen några år) att ta fram mikroprocessorer som är lämpliga att implementera operativsystem och kompilatorer på, speciellt har jag hört talas om några företag som bygger processorer speciellt för UNIX & C. Trevligt! /Pi
  • Peter Thärning <3707> · Text 796 · w8 · kommentar

    1987-04-17 01:02

    Ärende: Processorarkitektur

    Separata adress och databussar har väl de flesta processorer. Om man av någon anledning blir tvungen att ha två signaltyper på samma ledning för att spara pinnar så beror det nog snarare på att man till pinnantalet inte vill överskrida en standard, inte själva kapslingstekniken. Det är nog inte svårare att göra en 46 pinnars DIL (Dual In Line) istället för 40 men vem gör socklar till den? Det verkar väl troligt? Kretsar med inbyggda kompilatorer finns faktiskt redan. I Elfa-katalogen för 85/86 finns medtaget en krets ur 6500-familjen som beskrivs såsom "R65F11 är en förbättrad version av R6502 med FORTH kompilator i ROM" Med den takt utvecklingen på detta område håller idag så är 1985-1986 långt...långt bort i tiden och det är nog dumt att gissa vad som är up to date. Fast frågan är om det lönar sig att integrera högnivåspråk idag. Jag tvivlar på det. I alla fall inte när det rör sig om större system och man inte har hur gott om tid som helst. Nog skulle det vara lite omständligt att köra C på den ovan nämnda R65F11 till exempel. Nu är den ju inte ämnad för det och i såna applikationer då man vill ha snabb FORTH-kod utan en massa mellansteg ifrån källkoden så passar den nog bra. Då är det säkert bättre att låta koden till processorn vara obegriplig, kalla den för maskinspråk och sedan satsa på en kvalificerad utvecklings- miljö istället med användarvänliga källkodseditorer och raffinerade kompilatorer etc. Detta återkommer lite grand i användarvänligheten hos de koder som mikroprocessorerna använder. Om man skulle bygga upp koderna så att de skrivna hexadecimalt relaterade till instruktionsnamnet så kanske det blev något lättare (?...) att handassemblera, men bra mycket besvärligare att skriva en snabb assemblator. För är det inte så att exv. Z80s koder är gjorda så att det underlättar skrivandet av en assemblator?
    • Benny Löfgren SYSOP <2615> · Text 799 · w8 · kommentar

      1987-04-24 07:20

      Ärende: Processorarkitektur

      Nej, varken Z80 eller någon annan processor tror jag är skriven för att medvetet underlätta skrivandet av assemblatorer/kompilatorer! Vad man helt enkelt vill göra är utifrån processorns givna förutsättningar optimera instruktionsuppsättningen/kodningen med avseende på i första hand hastighet, men även minnesåtgång (de två går ofta hand i hand). Det vore vansinnigt att göra tvärtom, dvs att offra exekveringsfart för att få en assembler som är lite snabbare (det är dessutom högst marginella vinster man kan göra för att snabba upp en assembler på det sättet). Assembleringen görs trots allt bara ett fåtal gånger, jämfört med det färdiga programmets exekvering! ( Kommentar i text 800 av Peter Thärning <3707> ) ( Kommentar i text 801 av Mikael Pettersson <2195> ) ( Kommentar i text 802 av Kristoffer Eriksson <5357> ) ( Text 799 ) 
      • Peter Thärning <3707> · Text 800 · w8 · kommentar

        1987-04-24 21:36

        Ärende: Processorarkitektur

        Ja, du har rätt. Jag var inne på den linjen innan så varför jag tvärvände när det gäller Z80s instruktionsrepertoars koder vet jag inte.
      • Mikael Pettersson <2195> · Text 801 · w8 · kommentar

        1987-04-25 00:26

        Ärende: Processorarkitektur

        Z80 är rena hatobjektet för den som skriver kodgeneratorer för kompilatorer. Vad man som kompilatorskrivare gärna vill ha tillgång till är bl a lång relativ-adressering (relativt PC eller register), samt smidighet att nå data på stacken. Det sistnämnda är (tycker jag) det allra viktigaste. Dessutom saknar Z80an mjukvaruinterrupt som kan användas för OS-anrop och liknande. Det finns 8-bittare som har dessa möjligheter, bl a 6809 har jag för mig.
        • Kristoffer Eriksson <5357> · Text 803 · w8 · kommentar

          1987-04-26 03:54

          Ärende: Processorarkitektur

          Vad ska man med mjukvaruavbrott till på en processor där avbrott inte skiljer sig från CALL med mer än att avbrottsflaggan ändras?
          • Mikael Pettersson <2195> · Text 805 · w8 · kommentar

            1987-04-26 22:13

            Ärende: Processorarkitektur

            Bl a därför att CALL måste veta exakt vart den ska, vilket inte ett interrupt behöver eftersom då ligger informationen i någon tabell utpekat av något register. Detta leder till betydligt större flexibilitet, program behöver inte veta i förväg exakt var alla systemrutiner ligger. Det finns en fördel till, med den är inte tillämplig på de rektigt små processorerna (z80, 68xx osv) och det är att processorn normalt jobbar i supervisor- eller user- mode. Man kan koppla mjukvarustyrt interrupt till byte av processormode, vilket inte är möjligt med ett enkelt CALL-schema (där är det t om olagligt att gå från user till supervisor).
            • Kristoffer Eriksson <5357> · Text 807 · w8 · kommentar

              1987-04-26 22:53

              Ärende: Processorarkitektur

              Nej, men då måste den i stället veta det exakta numret på mjukvaru- avbrottet (om det finns mer än ett), så vad är skillnaden mellan att skriva INT 5 mot RST 5 ? Det där med supervisor- och usermode faller ju som du själv noterar när det gäller de processorer vi diskuterar nu, och det var det jag menade med att inget annat hände än att avbrottsflaggn ändrades.
              • Mikael Pettersson <2195> · Text 808 · w8 · kommentar

                1987-04-27 23:52

                Ärende: Processorarkitektur

                Skillnaden är att INT x kan hoppa till OLIKA adresser beroende på vilket värde som ligger i det register som utpekar (mjuka) avbrott. RST x måste dock alltid hoppa till just adress x, och det kan inte ändras.
                • Kristoffer Eriksson <5357> · Text 809 · w8 · kommentar

                  1987-04-29 01:04

                  Ärende: Processorarkitektur

                  Det finns inget register för utpekande av mjuka avbrott i dessa små processorer, alltså är dt ingen skillnad. Dessutom kan RST- rutinerna hoppa vidare till variabla rutiner. (Angående mer avancerade processorer, så har 80286/386 "task gates", och andra lustigheter, som man kan gå igenom med CALL eller JP, varvid man hamnar i en annan task med ega privilegier.)
        • Peter Hollsten <2431> · Text 804 · w8 · kommentar

          1987-04-26 15:40

          Ärende: Processorarkitektur

          Mjukvaruinterrupt skulle inte ha nån fördel gentemot RST instruktionerna. Externa interrupt har ju ändå högre prioritet i dom som har de.
          • Mikael Pettersson <2195> · Text 806 · w8 · kommentar

            1987-04-26 22:18

            Ärende: Processorarkitektur

            Men RST-instruktionerna är ju ändå bara snabba versioner av vanliga CALL, dvs vart man ska måste deklareras explicit I INSTRUKTIONEN. Med mjukvaruinterrupt får man samma flexibilitet som med hårdvarudito: man genererar bara interruptet och sedan tar processorn själv reda på vart den ska genom att titta i någon tabell utpekat av något register. På detta sätt uppnås en total flexibilitet, man kan flytta på rutinernas startadresser utan att behöva kompilera om den kod som anropar rutinerna.
            • Peter Hollsten <2431> · Text 810 · w8 · kommentar

              1987-05-04 19:20

              Ärende: Processorarkitektur

              Ok, då är det väl en tabell i början av minnet för en z80 cpu, därifrån kan man ju sen hoppa var man vill... JA, tabellen är inte speciellt minnessnål eller lång, men å andra sidan så kom ju inte cpu'n ut igår som vissa andra.
      • Kristoffer Eriksson <5357> · Text 802 · w8 · kommentar

        1987-04-26 03:53

        Ärende: Processorarkitektur

        Instuktioner som ENTER, LEAVE, RET n i 80286/386 och LINK, UNLK och den regelbundna register- och instruktionsuppsättningen i 680xx är ju typiskt syftade på kompilatoranvändning, vettja.
  • Kristoffer Eriksson <5357> · Text 798 · w8 · kommentar

    1987-04-19 04:58

    Ärende: Processorarkitektur

    "Mnemonics" kallas orden som används i assemblerspråk. Att ha ett par hundra olika pinnar på en och samma kapsel (tänk dig t ex 4 bussar med 32 signaler i varje) gör lmdningsdragningen på kretskortet där kapseln monteras synnerligen komplicerad, såvida man inte bara kan rada upp alla komponenter och ansluta dem parallelt med samma pinkonfiguration till hela bussen. Många ledare tar även mycket plats och ledningsmaterial. Helst ska det vara så få ledare mellan kapslarna som möjligt, precis som det ska vara så få förbindelser mellan olika programmoduler som möjligt när det gäller mjukvara. När det gäller att ha data och program i minüen med separata bussar, måste man tänka på att en del av datorns flexibilitet hänför sig till möjligheten att ibland betrakta samma minnes- innehållet som data och ibland som program. Även om man nu inte håller på med självmodifierande program, kan man tänkas låta ett program modifiera ett annat t ex en kompilator vars utdata blir ett program, eller en debugger som behandlar gtt annat program som data. Så ska man ha data och program på skilda bussar måste man se till att det finns möjlighet att överföra data mellan de olika minnena. Som ett alternativ till separata bussar kan man lika gärna tänka sig en enda buss som är lika snabb som flera "vanliga" bussar. Det är ju trots allt överföringskapaciteten du är ute efter. Om bussen hinner med att överföra både ett maskinkodsord och ett dataord på den tid processorn tar på sig för att exekvera instruktionen, så har du uppnåt samma mål som med separata program- och databussar, men medtskilligt färre ledare. En separat buss består f ö av både en adress- och en datadel. En ensam adressdel utan datadel gör ju ingen nytta. Tänk dig t ex 32 ledare för adressen och lika många för data i en av bussarna. Det blir 64 ledare för en enda av bussarna. (Och vem vill arbeta med ärre än 32 bittar? :-) Tänk om man har 1 MB programminne, och 1 MB dataminne, och så vill man köra ett program på 10 KB som behöver 1.5 MB dataminne, eller tvärtom... Att bestämma mängdeo data och program i förväg går nog bra för prommade applikationer och för dem som har råd att bestycka båda delarna maximalt (och få dubbelt så mycket överblivet minne mot normalt), men för"oss andra skulle det behövas någon anordning för att flytta minne mellan bussarna. (T ex att alltminnet har både adress- och databuss det också.) DMA står för "Direkt minnes-access", dvs en överföring mellan två minnespositioner eller en minnesposition och en I/O-position, utan processorns inblandning, oftast av ett flertal adresser i följd. Detta görs genom att en DMA-styrkrets tillfälligtsvis övertar styrningen av en buss från processorn, som antingen får vila sig elles göra något som inte involverar bussen. Som man då förstår, är en separat DMA-buss kopplad till processorn ganska meningslös. Operationen måste göras på data- eller I/O-bussen, eller möjligen på en särskild buss som sammanbinder DMA-enheten med minnet, vilket innebär att minnet (i stil med processorn) förses med ytterligare några bussar. Idén att låta processorn använda en maskinkod som är direkt läsbar i ASCII, t ex med 8 bytes per instruktion (vilket innebär en 64- biötars buss exkl adressdelen), vilket väl f ö knappast inkluderar utrymme för operanderna, skulle vara oerhört slösaktigt med minnet. Det finns roligare saker man kan göra med det minnet. Och tänk på att om du med denna 8-bytesbuss kan överföra en hel instruktion i ASCII på en gång, så kan du överföra ännu mer på en gång om du gör det med binär (maskin)kod. Det är knappast någon som sen assemblern uppfanns behöver bry sig om hur processorns maskinkodsinstruktioner ser ut. Sånt är till för assemblern (och debuggern). Dessutom behöver de flesta inte bry sig om hur assembler- instruktionerna ser ut heller nu för tiden, utan det är något för högnivåspråkskompilatorn, som dessutom automatiskt optimerar programkoden.