Blåbär...

13 posts in thread

• Johan Olofsson <5809> · Text 937 · w8 · inlagg

  1987-08-25 00:26

  Ärende: Blåbär...

  Jag har nu för första gången i mitt liv lyckats få en Z80-assembler att fungera. Anledningen till att det dröjt ända till nu är, förutom latmasken, att Z80 saknar ordenlig relativ-adressering. Men när jag väl satte igång så visade det sig att jag är osäkrast på hur man lämpligast utför 16-bits operationer. Nu måste jag fråga er som är lite äldre i gamet om råd: - Hur bör man jämföra innehållet i 16-bits register? - Hur bör man inkremera en 16-bits variabel i arbetsminnet? Exempel: COMPARE:EQU * ; jämför innehållet i HL och DE registren, sätt Z-flag ;Version 1 LD A, D CP H RET NZ LD A, E CP L A har osäkert innehåll RET ;Version 2 ; PUSH HL A nollställs ; XOR A ; SBC HL, DE ; POP HL ; RET *H Interupt-rutiner *E ; TICK0: EQU * INCREMERA SINCE MED KLOCKAN PUSH AF PUSH HL ; LD HL, (SINCE) Räkna upp Since INC HL OBS inga flaggor ändras! ; LD A, H ÄR Since = 0 nu ??? OR L JR Z, EXIT (Since får inte "slå över".) LD (SINCE), HL Lagra annars tillbaka Since ; EXIT: POP HL POP AF JPTICK: JP TICK ;
  • Björn Linderson <5829> · Text 938 · w8 · kommentar

    1987-08-25 01:55

    Ärende: Blåbär...

    Öka minnesadress (16 bittar) med 1 LD HL,(adress) INC HL LD (adress),HL Klart.... Taskig uppsättning med relativa hopp?? Det kan jag nog inte godkänna... (sitter med "PROGRAMMING THE Z80" i tassen...) JR nn JR cc nn cc kan vara en av : NZ, Z, NC, C nn är det antal BYTE frammåt / bakåt som den skall hoppa.
    • Björn Linderson <5829> · Text 939 · w8 · kommentar

      1987-08-25 01:57

      Ärende: Blåbär...

      OOPS! Glömde.... DJNZ nn Decrement Jump No Zero - Minska B med ett,testa om noll, och om inte noll, hoppa. Instruktionsuppsättningen är trots allt ganska normal...
    • Johan Olofsson <5809> · Text 941 · w8 · kommentar

      1987-08-25 19:11

      Ärende: Taskig uppsättning relativa hopp - NEJ,

      Taskigt med relativa JUMPs, CALL, och LoaD. Relativa CALLs saknas ju faktiskt helt och hållet! Möjligheten att adresser med IX eller IY plus en 8-bits offset är naturligtvis en stor förbättring mot Intel-8080, men det ger INGEN praktisk möjlighet att ladda och lokalisera PROGRAM-delar oberoende av varandra. Åtminstone 12 bits offset hade behövts! Så vitt jag förstår måste det krävas en rätt så komplicerad "LOADER" för att ladda assemblerad Z80-kod om man inte redan vid assembleringen kan _fixera_ alla adresser! Därför torde nästan alla Z80-pgm göras så. Naturligtvis sparar processorn _tid_ på att slippa addera adress-offset med innehåll i något adress-register, men det blir ju besvärligt att se till att rutiner _inte kolliderar_ med varandra. Z80 funkar alltså bra om man har ETT program som ska köras kontinuerligt, eller om man har många program som _vart och ett_ fyller upp hela minnet med kod och variabler.
      • Björn Linderson <5829> · Text 942 · w8 · kommentar

        1987-08-26 00:51

        Ärende: Taskig uppsättning relativa hopp - NEJ,

        Hmm... LD relativt???? var hittar du det i någon processor?? Indirekta adresseringar, det kan jag vara med på, men relativa? (utöver IX och IY) som är special... Monroe är en Z80-dator, som kör FLER än ett program, och i den maskinen så hamnar inte programmen alltid på samma plats, utan måste vara relativt adresserade. (även basic-tolken) Visst går det att göra det relativt, men å andra sidan, så kanske inte Z80:an är direkt avsedd för det som större processorer måste kunna i och med den större minnesarean och de längre inmstruktionskoderna..
        • Anders Franzén <5258> · Text 943 · w8 · kommentar

          1987-08-26 20:24

          Ärende: Taskig uppsättning relativa hopp - (NEJ) JA!

          I vissa maskiner använder man ett basregister. Detta basregister talar t ex om var programmet börjar i minnet. En instruktion typ LOAD adresserar en area i minnet som beräknas mha basadress och avstånd från basadressen. Sålunda använder man då relativ adressering vid LOAD.
        • Kristoffer Eriksson <5357> · Text 948 · w8 · kommentar

          1987-08-27 23:47

          Ärende: Taskig uppsättning relativa hopp

          Det hittar man i t ex M68000. Där finns både "Program Counter Relative with Offset" och "with Index and Offset". Indexet är då valfritt register.
  • Kristoffer Eriksson <5357> · Text 944 · w8 · kommentar

    1987-08-26 22:37

    Ärende: Blåbär...

    Båda versionerna för 16-bittsjämförelse är rätt, fast observera att i den ena räknade du DE-HL och i den andra HL-DE. Ökningen är också rätt om variabeln inte får slå om. Om inte förbehållet vore kunde man ev göra LD HL,Since INC (HL) JR NZ,Exit INC HL INC (HL) i syfte att tjäna några få maskincykel i alla de fall då bara den låga byten påverkas, jämfört med att hämta in hela variabeln i ett dubbelregister. Det är bara att acceptera att så här jobbigt är det. Z80 är trots allt bara en 8-bittars processor, inte en 16-bittars. De 16-bitts-instruktioner som finns är väl mest avsedda att hantera adresser typ pekare. Apropå relativ adressering, eller brist på sådan, och laddare, så finns det de som gjort sig relokerande laddningsrutiner, om jag får "skryta" lite... Om man för resten tittar på hyffsat större maskiner med minnesmappning, så minskar åter behovet av konsekvent relativadressering, särskilt PC-relativ, eftersom alla program kan placeras på en privat virtuell adress som den kompilerats för från början.
    • Johan Olofsson <5809> · Text 945 · w8 · kommentar

      1987-08-27 01:52

      Ärende: INC av 16-bits variabel

      Just ett sådant svar önskade jag mig. I den aktuella rutinen är det högst väsentligt att kunna spara MOP-ar, så jag har gjort en grundlig jämförelse av alternativen: (Först står hur många bytes OP-koden tar upp, sedan hur lång tid exekveringen tar.) Kristoffers förslag Min ursprungliga kod ------------------- -------------------- 3 10 LD HL, SINCE 3 16 LD HL, (SINCE) 1 11 INC (HL) 1 6 INC HL 2 12/7 JR NZ, T_EXIT 1 4 LD A, H 1 4 OR L 1 6 INC HL 2 12/7 JR Z, T_EXIT 1 11 INC (HL) 3 16 LD (SINCE), HL 2 12/7 JR NZ, T_EXIT 11 = summa 1 11 DEC (HL) 1 6 * DEC HL 1 11 * DEC (HL) 14 = summa Resultat: --------- (med H och L avses nu högre och lägre byte av _ SINCE _ !) Kr. min --- --- Om L<255 33 53 OBS 99,25% av anropen hit Om L=255, H<255 57 53 Om L=255, H=255 80 32 Om H=255 ej medf. dec(L) 63 - samt att 99,25% av anrop tar 33 T Jag väljer därför att utgå från Kristoffers förslag, och _inte_ räkna ner den minst signifikanta byten i variabeln. Till rutinen hör dessutom PUSH, POP och JP, som tar 52 tidsenheter. Därmed har rutinen blivit 20% snabbare.
      • Johan Olofsson <5809> · Text 946 · w8 · kommentar

        1987-08-27 01:52

        Ärende: INC av 16-bits variabel

        beklagar den misslyckade utskriften!
        • Patric Ljung <5455> · Text 961 · w8 · kommentar

          1987-10-07 20:00

          Ärende: INC av 16-bits variabel, ojoj, allmän kommentar

          Ojojoj, en sån massa olika metoder, men som sagt, programmering är konst. Jag skall inte lämna bidrag, och mina egna tankar blir helt virriga. Skall jag lyckas skriva litet assembler idag får jag nog sluta nu. (Dum kommentar)
      • Kristoffer Eriksson <5357> · Text 950 · w8 · kommentar

        1987-08-29 23:42

        Ärende: INC av 16-bits variabel

        Varför får inte SINCE slå om? Det kanske skulle räcka med att sätta en flagga när den slår om, och sedan räkna vidare, så slipper du backa SINCE när du upptäcker att det gått för långt. Eller den höga byten kan agera flagga, så att när den är 255, betyder det att räknaren har nått taket (i stället för när hela SINCE är 65535), så slipper du backa båda byte:arna när du upptäcker att det gått för långt.
        • Johan Olofsson <5809> · Text 951 · w8 · kommentar

          1987-08-30 00:04

          Ärende: INC av 16-bits variabel

          Faen, att du alltid ska uttrycka allting så mycket bättre! Det var ju det jag tänkte på, att Since höga byte kan vara flagga. Man tjänar väldigt många maskincykler på att låta den låga byten bara snurra på.