Retro Preservation Workspace

Monitorn

Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.

← Back to ABC Tools

Meetings · Z80 · Thread

DEC A

16 posts in thread

Petter Stahre <4501> · Text 878 · w8 · inlagg

1987-07-07 21:06

Ärende: DEC A

Påverkar detta kommando verkligen inga flaggor?? Det har i alla fall fungerat utmärkt för mig att använda det, och sedan kontrollera med JP NZ,.... Anledningen till att jag frågar är dels att jag nydligen upptäckte att Zaks bok säger att DEC *inte* påverkar *någon* flagga. En annan anledning, som föranlett mig till detta inlägg är att en ändring i ett assemblerprogram som torde vara helt korrekt har fått programmet att uppföra sig mycket konstigt. Kan det vara så att jag av ren tur fått DEC och JP fungera utmärkt, eller?? / mvh PSt
- David Andersson <5201> · Text 879 · w8 · kommentar
  
  1987-07-07 21:40
  
  Ärende: DEC A
  
  (Fritt ur minnet:) DEC A påverkar inte Carry-flaggan. DEC A påverkar Zero-flaggan. Man kan alltså testa efter DEC A med JP Z. DEC HL, DEC BC m m påverkar inga flaggor alls. Hur kan det stå så galet i Zaks bok? Börjar jag bli åderförkalkad?
- Mikael Carlstedt <7105> · Text 880 · w8 · kommentar
  
  1987-07-07 22:39
  
  Ärende: DEC A
  
  Que??? Vad har du för en upplaga? Det måste vara tyrkfelsnisse som har varit framme! Kan du beskriva lite mer utförligt omständigheterna kring den där ändringen du nämnde? * Girbat *
- Paul Pries <5322> · Text 881 · w8 · kommentar
  
  1987-07-08 09:00
  
  Ärende: DEC A / Flaggor.
  
  Så vitt jag kan se så påverkar inte DEC A i sig själv några flaggor. Det är endast om (A) blir 0 som Z-flaggan sättes. Och då är det ju inte själva instruktionen som har påverkat flaggan, utan resultatet! H/Paul
  - Petter Stahre <4501> · Text 882 · w8 · kommentar
    
    1987-07-08 19:31
    
    Ärende: DEC A / Flaggor.
    
    Jag har nog sett fel. Nu när jag kollar igen, så ser jag att DEC på register-par inte påverkar flaggor. Däremot DEC på enkelregister gör det. / mvh PSt
  - David Andersson <5201> · Text 883 · w8 · kommentar
    
    1987-07-09 09:54
    
    Ärende: DEC A / Flaggor (närmast en språkfråga).
    
    Om A blir noll så sätts Z-flaggan till 1 och om A blir skilt från 0 så sätts Z-flaggan till 0. Jag tycker det är bättre att säga att det är instruktionen som sätter flaggorna än att säga att resultatet gör det. Det finns instruktioner som inte sätter flaggorna fast de ger resultat. T ex DEC HL och instruktionerna som sätter och clerar bitar (SET x,A m m). Alltså "vissa instruktioner påverkar flaggorna"! (Inte "vissa resultat påverkar flaggorna")
    - Peter Goldmann <5080> · Text 884 · w8 · kommentar
      
      1987-07-09 21:43
      
      Ärende: DEC A / Flaggor (närmast en språkfråga).
      
      Om jag har läst rätt i tidigare inlägg så är jag tveksam över terminologien. Avspeglar inte FLAGGORNA realiteter? Alltså oberoende HUR tillståndet uppnåtts kommer om A=0 Zeroflaggan att sättas =1 Naturligtvis kommer detta att kunna ske någon gång för DEC A men även för en mängd andra instruktioner som påverkar A:s inne- håll. Således borde det vara mer stringent att säga att Z flaggan direkt visar A:s tillstånd - punkt slut. För programmeraren blir då slutsatsen att så fort jag opererar på A så bör jag hålla koll på Z - flaggan - räcker inte det för att täcka samtliga fall?
      - David Andersson <5201> · Text 885 · w8 · kommentar
        
        1987-07-10 21:30
        
        Ärende: DEC A / Flaggor
        
        (Varning, 51 rader med ointressanta exempel) Nej, nej, nej. Efter t ex: XOR A LD A,255 så är Z-flaggan 1 fast A är skilt från noll. LD-instruktionen ändrar register utan att påverka flaggorna i Z80. LD A,1 DEC A ;sätter (inte alla) flaggor enligt register A DEC B ;sätter (inte alla) flaggor enligt register B Inte efter någon av dessa instruktioner återspeglas A:s (hela) tillstånd i flaggorna. SET 7,A ;sätt en bit i A Flaggorna ändras inte utan återspeglar resultatet av tidigare operationer som kan finnas i t ex reg HL eller reg C eller inte alls. CCF ;negera carry-flaggan. Varken A:s tillstånd eller något annat registers tillstånd återspeglas nu i carry-flaggan. Antag att följande två operationer alltid gav resultatet 255: ADD A,2 och OR A,128 Då kommer alla flaggor (utom en eller två) att vara lika och verkligen återspegla resultatet. En skillnad är att P/O flaggan troligen är satt av ADD men nollställd av OR. INC HL sätter inga flaggor alls. INC (HL) sätter några få flaggor (som INC A). Efter ADD HL,BC återspeglas inte A:s (men väl HL:s) tillstånd i flaggorna. Möjligtvis kanske med några undantag som jag glömt. Skift- och rotate-instruktioner ska vi bara inte tala om. Som programmerare räcker det alltså inte att tänka att A:s tillstånd återspeglas i flaggorna. Det räcker inte ens att tänka att tillståndet för det senast använda registret återspeglas. Man måste ta hänsyn till vad det var för instruktion också. (I M6809 är det lite enklare. Inte alla, men de flesta instruktioner som ändrar register gör att flaggorna sätts)
      - Kristoffer Eriksson <5357> · Text 886 · w8 · kommentar
        
        1987-07-11 00:01
        
        Ärende: DEC A / Flaggor (närmast en språkfråga).
        
        (Nu skriver jag i princip baa samma sak som inlägget före det här, men det här har jag författat i förväg, så jag sänder in det som det är.) Det finns två möjligheter för flaggor. De kan antingen avspegla resultatet av en operation, eller de kan behållas oförändrade, och alltså fortsätta att avspegla resultatet av någon tidigare operation. Vad som gäller varieraåir för varje flagga och varje instruktion. Läser man en lista som visar vad instruktionerna gör, brukar det även ingå en uppgift om vilka flaggor som påverkas hur för varje instruktion. För att ta några exempel: ADD A påverkar alla flaggor. INC A påverkar allt utom carry-flaggan. ADD HL,DE påverkar bara carry och N. INC HL påverkar ingenting. P/V-flaggan påverkas i vissa instruktioner av resultatets paritet och ibland av overflow. Detta gör att man kan skriva saker som CP A,B INC A RET C LD A,0 RET som ökar A med ett om B>A, och annars nollställer den. Observera att RET C går efter resultatet från CP A,B, eftersom INC A inte påverkar carry-flaggan. På det här sättet slipper jag använda en JR till INC A.
        
        Peter Goldmann <5080> · Text 887 · w8 · kommentar
        
        1987-07-11 10:21
        
        Ärende: DEC A / Flaggor (närmast en språkfråga).
        
        Jag hade fel som David så tydligt visat. Tack för en intressant genomgång!
        
        Peter Goldmann <5080> · Text 888 · w8 · kommentar
        
        1987-07-11 22:28
        
        Ärende: DEC A / Flaggor (närmast en språkfråga).
        
        Läste igenom inläggen igen om flaggorna - skulle man inte kunna säga att om man opererar på A så beakta att Z KAN påverkas. Kan någon då förklara varför man inte valt att låta Z återspegla realiteterna i A? Alltså att oavsett hur A blivit 0000 0000 kommer då Z sättas 1. Det borde ju gå att realisera enkelt genom en AND-grind med 8 inverterade ingångar. Kan någon förklara varför Z80 är så assymetrisk i sin reportoar? Är den ett lappverk? Jag tycker att en processor ska vara förutsägbar i sin reportoar. Av tidigare inlägg tycks det som om vissa instruktioner har fallit bort i standardvarianten - de är åtminstone ej legala, men i special- versioner är de OK. Är inte det bedrövligt? Var det refreshen av dynamiska RAM som gjorde den så populär?
        
        Peter Hollsten <2431> · Text 889 · w8 · kommentar
        
        1987-07-12 01:47
        
        Ärende: Z80 processorn
        
        Det som gorde den populär var väl att 8080 var så populär och z80 kan ju allt som 8080 kan + en del mer. Priset har nog sitt därtill (4kr i större kvantiteter). Orsaken till att 16bit DEC inte ändrar flaggorna ligger i intels grundfilosofi, bakåtkompatibel med 4040. Bakåtkompabilitete har ju även drabbat I*B PC med segmenteringshanteringen som jag personligen hatar djupt.
        
        Stefan Lennerbrant <4364> · Text 890 · w8 · kommentar
        
        1987-07-12 21:04
        
        Ärende: DEC A / Flaggor (närmast en språkfråga).
        
        Mja, skulle det vara bra om flaggorna påverkades av tex LD ? Det är ju ganska vanligt att A innehåller någon slags returnkod, tex: . . LD A,1 RET Z XOR A RET Här går funk ut med A=1 om Z sattes innan. Om Z påverkades av LD A,1 skulle det ju inte längre vara så behändigt, eller hur. mvh
        
        Ulf Dahlen <2422> · Text 893 · w8 · kommentar
        
        1987-07-19 01:29
        
        Ärende: DEC A / Flaggor (närmast en språkfråga).
        
        Flera processorer, t ex 6502, använder sig av filosofin att sätta flaggor vad man än gör. LDA #1 sätter således Z till 0. Och det går ju bra att programmera 6502, så varför inte?
        
        Stefan Lennerbrant <4364> · Text 912 · w8 · kommentar
        
        1987-07-29 20:49
        
        Ärende: DEC A / Flaggor (närmast en språkfråga).
        
        (. Sakfel ! Det går inte bra att programmera 6502 .)
        
        Kristoffer Eriksson <5357> · Text 891 · w8 · kommentar
        
        1987-07-13 00:37
        
        Ärende: DEC A / Flaggor
        
        Man kan ju inte låta flaggorna återspegla innehållet i just A jämt. Man kan vara intresserad i innehållet i andra register också, som HL, eller resultatet av en operation typ CP som ju inte lämnar resultatet någon stanns. Sen är ju inte Z den enda flaggan som finns. Det finns t ex P/V- flaggan som vid aritmetiska operationer indikerar overflow (som f ö inte lagras i resultatets register, utan bara i flaggan) och vid logiska får resultatets paritet, om den påverkas alls. N-flaggan talar om huruvuda den senaste operationen som påverkade flaggan var en addition eller subtraktion, vilket inte har något alls med resultatet att göra. Med detta vill jag visa att det finns anledning att låta varje instruktion detaljreglera vad som händer med de olika flaggorna. Då är det inte långt för CPU:ns konstruktörer att reglera Z-flaggan på liknande sätt. Vissa situationer då det inte finns någon anledning att ändra Z- flaggans innehåll är rent uppenbara: hopp-instruktioner. Det vore ju dumt att om Z avspeglar resultatet av en CP mellan t ex A=10 och B=10 då Z blir sann, och ett hopp görs någonstanns, då återställa Z till falsk pga att A<>0. Det skulle betyda att vill man använda ett resultat till flera villkorliga hopp i rad, måste man göra om operationen direkt före varje hopp (vilket även innebär att registren måste ha kvar sina värden hela tiden). Då är frågan: När bör flaggan påverkas? En svår fråga som varje CPU-konstruktör får brottas med. Och det gäller även 6800-serien (David nämnde 6809). Det som har betydelse för beslutet är vilka fördelar det ger för programmeraren. De fördelar det ger att inte låta alla instruktioner påverka flaggorna, är som jag nämnde att flaggorna avspeglar resultatet av de för programmet intressanta operationerna länge, och inte störs av ointressanta saker som RET, så man inte måste upprepa viktiga test flera gånger, samt får frihet att lägga testet en bit före dess effekt (JP/JR). Nyttan av detta gav jag exempel på i förra inlägget. Intressanta operationer är i synnerhet jämförelser: CP, och i andra hand aritmetiska och logiska operationer. Vad som är intressant varierar förstås med vilka flagga som avses. Vad jag försöker förklara är att det inte är självklart att man alltid vill att flaggorna ska avspegla den allra senast gjorda operationen. Varför just ADD HL,ss inte påverkar Z-flaggan vet jag inte, men den kompletteras fint av ADC som gör det. Därmed finns det en additionsoperation som påverkar flaggan, och en som inte gör det. I övrigt påverkas Z av de flesta operationer som påverkar registren. Faktum är att det inte varierar helt godtyckligt från instruktion till instruktion vad som händer med flaggorna. Jag kan citera början av en sammanfattande tabell: S Z H P/V N C ADD A,s; ADC A,s: ! ! ! V 0 ! SUB s; SBC A,s; CP s; NEG ! ! ! V 1 ! AND s ! ! 1 P 0 0 OR s; XOR s ! ! 0 P 0 0 INC s ! ! ! V 0 - DEC s ! ! ! V 1 - ADD dd,ss - - X - 0 ! ADC HL,ss ! ! X V 0 ! SBC HL,ss ! ! X V 1 ! P=Parity, V=Overflow, !=Enligt operationens resultat, X=Odefinierat, -=Ej påverkad. Iofs är väl Z80 en påbyggd 8080 (eller vad det var), men jag tror inte man ska skylla alltför mycket konstigheter på det (dock kanske ADD HL kontra ADC HL?). Man har lyckats stoppa in ganska mycket i Z80 jämfört med övriga 8-bittars processorer från den tiden. När det gäller processorns asymmetri, så har den väl en del att göra med många instruktioner - få instruktionskoder och begränsat utrymme på chippet...