Vampire V4 julkaistiin A500:lle

http://www.tivi.fi/Kaikki_uutiset/legendaarinen-amiga-tietokone-palaa-entista-ehompana-6667966

Tästä löytyy kuvia mitä on tarjolla:
http://www.apollo-core.com/index.htm?page=products

Apollo 68080 CPU
Performance is application dependent:
up to ~ 1000MHz 68030 / 500MHz 68040 / 250MHz 68060
512 MB DDR3 Memory
Dual Flash Chips
SAGA GFX Core : Truecolor DIGITAL VIDEO OUT
FastIDE/CompactFlash Controller 13MB/sec
SDcard for Data exchange
USB
RJ45 100BaseTX Ethernet
Expansion ports (e.g. Wifi Module)

Vampire V4 ilmestyy myös A1200:lle ja standalone versiona myöhemmin. Kaikissa V4:ssa on hardFPU (noin 160 MFLOPS). V2:ssa oli vielä softaemulaatio, koska FPU ei mahtunut kokonaisuudessaan V2:en FPGA:lle.

43

558

Vastaukset

  • Olisi kyllä aika hurjaa jos nopeus olisi oikeasti tuota tasoa. Eikös se ollut Petro Tyschenko, joka aikanaan totesi, kuinka helppoa olisi jos olisi saatavilla 200 MHz:n 68080 ?

    • Yllämainittu nopeus koskee lähinnä tilannetta, jossa ajetaan 68080:lle optimoitua koodia. Vanha koodi pyörii varmaan noin 2-3x hitaammin, mutta 68060:lle optimoitu koodi varmaan jo paremmin. Superskalaarinen arkkitehtuuri vaatii että konekäskyt tulevat tietyssä järjestyksessä, jotta suoritus olisi mahdollisimman nopeaa. Joka tapauksessa esim. 100 MHz:lla 400 MIPS on maksimi, eli 4 konekäskyä per kellonjakso on maksimi 68080:lla.

      Kuitenkin mukana tulee myös AMMX- ja AMMX2-käskykanta, jotka voivat nopeuttaa laskentaa aivan huimasti mm. videon dekoodauksessa, mp3/jpeg-kompression käsittelyssä, alpha blendauksessa, ja tekstuurien filtteröinnissä. Nämä vastaavat Intelin MMX/SSE-käskykantaa, ja AMMX on kokonaislukupohjainen, ja AMMX2 liukulukupohjainen. MMX otettiin käyttöön Intelin Pentium-prosessoreissa ja SSE on alkaen Pentium III:sta.


    • m36-intj kirjoitti:

      Yllämainittu nopeus koskee lähinnä tilannetta, jossa ajetaan 68080:lle optimoitua koodia. Vanha koodi pyörii varmaan noin 2-3x hitaammin, mutta 68060:lle optimoitu koodi varmaan jo paremmin. Superskalaarinen arkkitehtuuri vaatii että konekäskyt tulevat tietyssä järjestyksessä, jotta suoritus olisi mahdollisimman nopeaa. Joka tapauksessa esim. 100 MHz:lla 400 MIPS on maksimi, eli 4 konekäskyä per kellonjakso on maksimi 68080:lla.

      Kuitenkin mukana tulee myös AMMX- ja AMMX2-käskykanta, jotka voivat nopeuttaa laskentaa aivan huimasti mm. videon dekoodauksessa, mp3/jpeg-kompression käsittelyssä, alpha blendauksessa, ja tekstuurien filtteröinnissä. Nämä vastaavat Intelin MMX/SSE-käskykantaa, ja AMMX on kokonaislukupohjainen, ja AMMX2 liukulukupohjainen. MMX otettiin käyttöön Intelin Pentium-prosessoreissa ja SSE on alkaen Pentium III:sta.

      Niin tuo AMMX2 ei taida olla mikään liukulukupohjainen, sitä saa vielä odottaa, vaan pelkkä parannus AMMX-käskykantaan.


  • Tekeekö tuollaisella oikeasti jotain vaan onko vain nörttien lelu?

    • Vampire FPGA:lla on lähtökohtaisesti kysyntää sen vuoksi, että vanhoja Amigan erikoispiiristöjä ei ole valmistettu yli 20 vuoteen, samaten uusia Motorolan m68k-sarjan prosessoreita ei juuri valmisteta enää. Näin ollen uutta rautaa ei saada juuri mistään ja sen vuoksi esim. 68060-kiihdytinkorttien hinnat ovat nousseet aika huimasti viime aikoina, kun kysyntää kuitenkin on. Turha siis urputtaa siitä, miksi kukaan haluaa ostaa vanhaa Amiga-rautaa, markkinat ja kysyntä ovat mitä ovat.

      Riippuu siitä mitä itse haluaa, jos pelkkä softaemulaatio ei kelpaa, ja ei myöskään välitä näistä PPC-Amigoista, jotka ovat epäyhteensopivia vanhojen Amigojen kanssa, niin Vampire FPGA on hyvä valinta, siinä on kuitenkin moninkertaisesti tehoja verrattuna 50 MHz 68060-suorittimeen, ja uusia parempia näyttötiloja, jne.


    • "pelkkä softaemulaatio ei kelpaa, ja ei myöskään välitä näistä PPC-Amigoista, jotka ovat epäyhteensopivia vanhojen Amigojen kanssa"

      PPC-Amigat kuitenkin kykenee ajamaan vanhojen amigoiden softat noin 99%:sti.

      Mutta alkuperäinen klassikossa on toki aina omanlaisensa fiilis, mutta nekään ei 100% olleet yhteensopivia edes keskenään saatikka jonkun uuden prosessorituotoksen kanssa. Tuossa mielessä vampire toki voi olla parempi kuin alkuperäinen prossu, koska yhteensopiivuutta voi säätää ohjelmallisesti, prossua ei tarvitse vaihdella.


    • Se on insinöörimäisten-kokeilunhaluisten-nörttien-lelu.
      Muut pysyköön kaukana.
      Tällöin ei tule pettymystä.


    • amigisti-nisti kirjoitti:

      "pelkkä softaemulaatio ei kelpaa, ja ei myöskään välitä näistä PPC-Amigoista, jotka ovat epäyhteensopivia vanhojen Amigojen kanssa"

      PPC-Amigat kuitenkin kykenee ajamaan vanhojen amigoiden softat noin 99%:sti.

      Mutta alkuperäinen klassikossa on toki aina omanlaisensa fiilis, mutta nekään ei 100% olleet yhteensopivia edes keskenään saatikka jonkun uuden prosessorituotoksen kanssa. Tuossa mielessä vampire toki voi olla parempi kuin alkuperäinen prossu, koska yhteensopiivuutta voi säätää ohjelmallisesti, prossua ei tarvitse vaihdella.

      Softaemulaatiota saa halvemmalla ja paremmin esim. WinUAE:lla. PPC-prosessorit ovat varsin epäonnistuneita tekeleitä, RISC-tyyppisiä, hankala ohjelmoida käsin, mutta kuitenkaan eivät kovin tehokkaita, jos vertaa samalla kellotaajuudella muihin suorittimiin. Ainakin vanhemman sukupolven PPC-prosessorit ovat hitaita (601, 603, 604, 620, ja G3/G4). Modernit PPC-Amigat (X1000 ja X5000) taas ovat liian kalliita että niitä kukaan haluaisi, ja niissä aivan samat ongelmat kuin PC-tietokoneissa, eli täysin epäyhteensopivia hardware-tasolla vanhojen Amigojen kanssa.

      Täytyy muistaa että Vampire FPGA:ssa tulee mukana myös SAGA, joka on siis toteutus AAA-piiristöstä, joka jäi Commodorelta tekemättä. Koska Amigan 3.x käyttöjärjestelmä on hyvin kevyt, ei tarvita GHz-luokan prosessoria sitä pyörittämään, kun se onnistuu jo melko hyvin 8 MHz 68000-prosessorilla. Voitte varmaan kuvitella miten se lentää 100 MHz:n 68080-prosessorilla, vaikka korkeampaa resoluutiota käyttäisikin. AGA-koneet olivat vielä hitaita, johtuen hitaasta grafiikkamuistista, mutta Vampire FPGA:ssa muistinopeus on noin 600 MB/s.


    • >Softaemulaatiota saa halvemmalla ja paremmin esim. WinUAE:lla.

      Mutta tällöin on pakko käyttää windowsia kaikkine satoine puutteineen ja v*ttumaisuuksineen.

      > PPC-prosessorit ovat varsin epäonnistuneita tekeleitä,

      Höps. Melkolailla parhaat koskaan tehdyt RISC suorittimet.
      Nytkin superkoneissa käytetään paljon PPC sukuisia.

      > RISC-tyyppisiä,

      Aikakautensa tuote. Silloin oli yleinen näkemys että RISC:llä voidaan tehdä tehokkaampia prosessoreja. Mutta tilanne on muuttunut sikäli että kaikissa prosessoreissa on konepellin alla jotain muuta kuin RISC tai CISC vaikka käskykanta olisi jompi kumpi.

      Nykyisin RISC prosessorit ovat kuitenkin yleisimpiä ja käytetyimpiä prosessoreja maailmassa.
      Pari vuotta sitten miltei jokainen pelikonsolikin oli powerpc pohjainen.

      > hankala ohjelmoida käsin,

      Höps.
      Paljon helpompi ohjelmoida kuin binääriperverssit intelit.
      Mutta PPC amigoita voi ohjelmoida ongelmitta myös 68000 CISC koodilla, jos haluaa.
      Toimii ihan suoraan.

      Erona kuitenkin alkuperäisiin se että konekieltä ei samassa määrin ole pakko käyttää koska prossutehoa on moninkertainen määrä.

      >mutta kuitenkaan eivät kovin tehokkaita, jos vertaa samalla kellotaajuudella muihin suorittimiin.

      Ainoastaan moderni intel on samalla kellotaajuudella merkittävästi nopeampi.
      Amigalle ei kuitenkaan ole juurikaan ohjelmistoa joka hyötyisi esim. yli 2ghz prosessorista.
      Nykyiset PPC amigat on jopa satoja kertoja nopeampia kuin alkuperäiset.
      Nopeus on siis suhteellista.

      >Ainakin vanhemman sukupolven PPC-prosessorit ovat hitaita (601, 603, 604, 620, ja G3/G4).

      Jos vertaa saman aikakauden muihin prosessoreihin, ei ne niin hitaita olleet.
      PowerPC prossut eivät vain pärjää moderneille intel/AMD tuotteille.

      >Modernit PPC-Amigat (X1000 ja X5000) taas ovat liian kalliita että niitä kukaan haluaisi, ja niissä aivan samat ongelmat kuin PC-tietokoneissa,

      Isot/tehokkaat Amiga on aina olleet kalliita.
      Mun koneiden hinnat euroiksi muunnettuna
      -A500 800€
      -A2000 1700€
      -A4000 2300€ + 060 CPU 1200€ + 3D 500€
      -Sam440ep 1000€

      Tuon SAM:n hankinnan jälkeen en ole nuita vanhempia enään käynnistänyt ... ehkä kertaakaan.

      >eli täysin epäyhteensopivia hardware-tasolla vanhojen Amigojen kanssa.

      On totta että jos haluaa videon kautta naatiskella AGA/OCS/ECS ominaisuuksista, tällöin on oltava vanhoja amigoita (kaikki eri mallit).
      Mutta jos haluaa tehdä muutakin (jotain puolimodernia) niin sitten mielestäni on oltava A4000/060:aa nopeampi laite. Mieluummin yli 1000Mhz kuin alle.

      >Täytyy muistaa että Vampire FPGA:ssa tulee mukana myös SAGA, joka on siis toteutus AAA- piiristöstä, joka jäi Commodorelta tekemättä.

      Sille vain ei ole oikein mitään softaa joka sitä tukisi.
      Itse kun hankin näytönohjaimen AGA koneeseen, en AGA:aa enään käyttänyt kuin demoissa yms. jotka ei näytönohjainta ymmärtäneet.

      Mikään FPGA pohjainen näytönohjain ei pärjää moderneille näytönohjaimille, tuskin edes mun vanhalle cybervisionille.

      >Koska Amigan 3.x käyttöjärjestelmä on hyvin kevyt, ei tarvita GHz-luokan prosessoria sitä pyörittämään, kun se onnistuu jo melko hyvin 8 MHz 68000-prosessorilla. Voitte varmaan kuvitella miten se lentää 100 MHz:n 68080-prosessorilla,

      Omassa AGA koneessa on 50Mhz 68060 ja sillä AOS3 toimii jouhevasti. Sanoisin kuitenkin että 8Mhz prossu liikuttaa vain perus 3.1 käyttistä joten kuten. Esim. AOS3.9 käyttikselle 25Mhz 030 on suosittelemani minimi.

      Mun tehokkaimmassa amigamyllyssä 666Mhz PPC ajaa Amigasoftaa reilusti nopeammin.
      Joku voisi sanoa FPGA 68080:sta "mutta kuitenkaan eivät kovin tehokkaita".

      Mielestäni SAM440ep+AOS4.1 -kombinaatiolla yhteensopivuus commodoren aikaisiin sovelluksiin on parempi kuin mun A4000 koneella, johtunee siitä että oikealla raudalla yhteensopivaksi säätäminen (mode promotion yms) on vaikeampaa.

      >vaikka korkeampaa resoluutiota käyttäisikin.
      >AGA-koneet olivat vielä hitaita, johtuen hitaasta grafiikkamuistista, mutta Vampire FPGA:ssa muistinopeus on noin 600 MB/s.

      AGA:ssa taisi olla 28MB/s.
      Mun A4000 näytönohjaimessa 180MB/s väylällä toimi 1024x768x24bit grafiikat hyvällä nopeudella.
      Ja nykyisessä SAM440ep koneessa on 1600MB/s muistiväylä grafiikalle. 1920x1080x24bit toimii nopeammin kuin yksikään amiga sitä aikaisemmin.

      Voin minäkin joskus ehkä vampirea kokeilla... mutta x5000 kiinnostaa enemmän... kun vain olisi 2000€ ylimääräistä.


    • PowerPC- ja ARM-prosessoreissa on vakio 32-bittinen konekäskypituus, mikä aiheuttaa todella paljon turhaa koodia. Jos haluaa ladata 64-bittisen osoitteen rekisteriin, niin siihen vaaditaan yhteensä 5 konekäskyä PowerPC-prosessorilla. Myöskin 32-bittiseen osoitteeseen vaaditaan useita käskyjä. 680x0-prosessorilla osoitteen lataamiseen tarvitaan vain yksi käsky. Samat ongelmat tulevat eteen tietysti kun vakioita haluaa käsitellä, yhdessä 32-bittisessä konekäskyssä on tilaa useinkin vain yhdelle 16-bittiselle luvulle, koska toinen puolikas menee itse konekäskyn koodaamiseen. 680x0-prosessorissa on taas vaihtuvanpituiset konekäskyt, joihin mahtuu kaksi 32-bittistä lukua tai 68080-prosessorissa kaksi 64-bittistä lukua. Puhumattakaan siitä, että RISC-arkkitehtuurit ovat load/store-tyyppisiä, ei ole mitään monimutkaisia osoitusmuotoja, joita tarvitaan sujuvaan konekieliohjelmointiin.

      Käyttämäsi 667MHz SAM440ep on myös hidas, se hävisi 93 MHz:n 68080:lle yhdessä lajittelubenchmarkissa, jonka Apollocore-tiimi teki vertauksena PPC-suorittimiin. Tässä PowerPC:n hitaus käy ilmi, siinä SAM440ep:ssa on myös jotain ongelmia muistinopeudessa.
      http://www.apollo-core.com/index.htm?page=performance

      Niin, todellakin vain AmigaOS 3.0-3.1 toimivat 68000-prosessorilla, ja AOS 3.5-3.9 vaativat paljon enemmän, mutta nämä ovat jotain puolivirallisia käyttöjärjestelmäpäivityksiä, eivät Commodoren tekemiä. Nythän tulee myös päivitys 3.1:lle 3.1.4 muodossa, se on virallinen päivitys.


    • Jos minä haluaisin konekielellä koodata, koodaisin toki 68k koodia koska se toimii SAM440ep:ssä ihan suoraan.

      Aina tietenkin löytyy keinotekosiia/synteettisiä testejä joka 68080 saadaan nopeammaksi kuin ikivanhalla PPC440 prossulla, jossa ei ole edes L2 välimuistia.
      Moderneissa on kuitenkin. Samoin löytyy 128bittiset vektorilaskentayksiköt ja 128bittiset muistiväylät ja ytimiä riittämiin.

      >puolivirallisia käyttöjärjestelmäpäivityksiä, eivät Commodoren tekemiä. Nythän tulee myös päivitys 3.1:lle 3.1.4 muodossa, se on virallinen päivitys.

      Kyllä ne aivan virallisia olivat. Myöskään 3.1.4 ei tule olemaan commodoren tekemä.
      AOS4.1 on viimeisin virallinen Amigakäyttis joka pohjautuu 3.1 koodiin.


    • Pidän AOS-versioita 3.5 ja 3.9 epäonnistuneina, ne olivat lähinnä kosmeettisia parannuksia, joissa käyttöliittymän grafiikkaa parannettiin ja lisättiin TCP/IP-pino, ja muita apuohjelmia. Voi myös kysyä miksi siirryttiin taas takaisin 3.1-versioon, kun tätä 3.1.4 päivitystä tehdään. 3.1.4 versiossa sentään yritetään korjata vanhoja bugeja esim. tiedostojärjestelmästä ja muista käyttöjärjestelmän osista, mitkä olisi pitänyt tehdä kauan aikaa sitten, eikä vain lisätä uusia ominaisuuksia. 3.1.4 toimii myös edelleen 68000-prosessorilla, toisin kuin 3.5 ja 3.9.


    • Minun tietääkseni haage&partner ei ole koskaan luovuttanut 3.5 ja 3.9 versioissa käytettyjä lähdekoodeja. Siksi re-start on tehty 3.1:stä sekä 4.1:n että tuohon 3.1.4:n.


    • m36-intj kirjoitti:

      Softaemulaatiota saa halvemmalla ja paremmin esim. WinUAE:lla. PPC-prosessorit ovat varsin epäonnistuneita tekeleitä, RISC-tyyppisiä, hankala ohjelmoida käsin, mutta kuitenkaan eivät kovin tehokkaita, jos vertaa samalla kellotaajuudella muihin suorittimiin. Ainakin vanhemman sukupolven PPC-prosessorit ovat hitaita (601, 603, 604, 620, ja G3/G4). Modernit PPC-Amigat (X1000 ja X5000) taas ovat liian kalliita että niitä kukaan haluaisi, ja niissä aivan samat ongelmat kuin PC-tietokoneissa, eli täysin epäyhteensopivia hardware-tasolla vanhojen Amigojen kanssa.

      Täytyy muistaa että Vampire FPGA:ssa tulee mukana myös SAGA, joka on siis toteutus AAA-piiristöstä, joka jäi Commodorelta tekemättä. Koska Amigan 3.x käyttöjärjestelmä on hyvin kevyt, ei tarvita GHz-luokan prosessoria sitä pyörittämään, kun se onnistuu jo melko hyvin 8 MHz 68000-prosessorilla. Voitte varmaan kuvitella miten se lentää 100 MHz:n 68080-prosessorilla, vaikka korkeampaa resoluutiota käyttäisikin. AGA-koneet olivat vielä hitaita, johtuen hitaasta grafiikkamuistista, mutta Vampire FPGA:ssa muistinopeus on noin 600 MB/s.

      "Softaemulaatiota saa halvemmalla ja paremmin esim. WinUAE:lla."

      Halvempaa ja parempaa on kirjoittaa koodi niin, että sen voi kääntää nappia painamalla uusiksi kun alusta muuttuu.

      Tuossa toisessa viestissä mainittu SDL on esimerkiksi oikein kiva, vuosikymmenestä toiseen sama koodi toimii.


  • Sillä siis vain pelataan jotain typeriä ja lapsellisia pelejä onnettomalla muinaisajan grafiikalla?

  • Mitä jos joku firma julkaisee "Mini Amigan" samalla idealla kuin tuo uusi C-64 Mini? Mini Amigalla saisi pelattua ja puuhailtua alkuperäisen Amigan pelejä ja ohjelmia mutta tutun näköisen konepellin alla onkin tämänpäivän tekniikkaa.
    Ostin itse juuri tuon mini kuusnelosen, aika jänskä vekotin :) Mulla oli joskus aito C-64:n mutta tuli myydyksi pois. Amiga 500 sen sijaan on vielä tallessa.

  • Pysykää aiheessa, tämä ei ole mikään ketju C64:sta, tai peliohjaimista.

    Tässä on yksi esimerkki (apollocore-foorumista otettu) miten tehokasta 68080/AMMX-konekieli on, kyse on siis softaspriteistä, ja oletetaan että jokainen pikseli on 256 väriä ja chunky-formaatissa, eli sama kuin PC:n 256-värin VGA-moodi, resoluutio voi tietysti olla mitä tahansa. Koska 68080 on 64-bittinen voidaan 8 pikseliä käsitellä kerralla. 4 :n operandin käskyt ovat AMMX:ää, koska 68080 konekielessä on vain kaksi operandia.

    Nopeus on noin 400 MB/s tällä rutiinilla, taitaa olla varmaan yli 500 kertaa nopeampi kuin A500:n blitteri, tosin tässä on myös etuna chunky-näyttömoodin käyttäminen.

    LOOPX:
    MOVE.Q (A0)+,D1 ; load 8 pixel (each 256 color)
    PCMPeq.B D0,D1,D2 ; check for background pixel, create mask
    BSEL D2,(A1),D1,D3 ; load background and combine bytes
    MOVE.Q D3,(A1)+
    DBF D7,LOOPX

  • Pojilla on mennyt vähän aikaa V4 Vampiren kehittelyyn, ja nyt vasta joskus kesällä ensimmäiset V4-standalonet tulevat ehkä myyntiin.

    Tehoa riittää, nyt kun Sysinfoa on vähän korjailtu, niin se näyttää 68060-68080 prosessorien tehot oikeammin:

    http://www.apollo-core.com/knowledge.php?b=2&note=20840

    Eli tehoa lähes 200 MIPSiä ja MFLOPSeja yli 100 / 106 MHz:n kellotaajuudella. Se on paljon Amigalle, ja paljon enempää tuskin tarvitaan, kunhan ei nykyajan bloattia yritetä portata Vampirelle. Myös jotain parannettua Voodoo-tyyppistä 3D-näytönohjainta yritetään implementoida FPGA:lle myöhemmin, mutta suhtaudun tähän vähän varauksella. Pääasiassa on lähinnä että 2D-pelit pyörivät tarpeeksi nopeasti esim. 640x512 resoluutiolla/256 väriä, parempaa ei kyllä tarvita.

    • Tuo on hyvin alhainen suorituskyky, ja kuvanlaatu on heikko.

      Raspberry Pi 4 maksaa muutaman kympin, ja siinä on 3840x2160 resoluutio eikä mitään värirajoitteita.

      Ymmärrän toki tuon minimalismi ajatuksen, että ei tehdä möhköä ja ymmärrän myös koodin optimointajatuksen mutta sekin on vähän huono syy hankkia tuota. Sitä voi tehdä vaikka tuolla Raspberry Pi:llä. Paitsi että jos tekee Raspberry Pi:llä jotain siistiä se on kova juttu jos leuka putoaa lattiaan muutaman kympin tietokoneen mahtavilla tehoilla.

      Jos se on myyntivaltti, että sama laite ajaa vanhoja Amigan ohjelmia niin tuo on lähinnä nostalgianälkään.


    • Et ole käyttänyt Amigaa aikaisemmin? Itse käyttöjärjestelmä on suunniteltu toimimaan 8 MHz:n MC68000:lla. Vampire V4:n on noin 300 kertaa nopeampi, ja sillähän se käyttöjärjestelmä lentää. AmigaOS on moninkertaisesti kevyempi pyörittää kuin esim. Windows 95, vaikka tarjoaakin suunnilleen samat ominaisuudet. Muistiakin kuluu huomattavasti vähemmän.

      Mitä resoluutioon tulee, niin 2D-toimintapeleihin ei useinkaan tarvita enemmän kuin 640x512, mutta kyllähän sitä saa paljon enemmän tietysti Vampirella. On vaikeaa myöskin tehdä grafiikkaa käsin bitmap-pohjaisesti korkealla resoluutiolla. Lähes kaikki pelit Amigalle tehtiin 320x200 tai 320x256 resoluutiolla ja 16/32 värillä. Copper-apupiirillä sai sitten huomattavasti enemmän värejä näytölle.

      Mitä tulee Raspberry Pi:hin, se ei yksinkertaiseti kelpaa, ARM/PowerPC-prosessorit ovat kehnoja, ja niitä ei voi helposti ohjelmoida assembler-kielellä. Amigalle suuri osa softasta on kuitenkin tehty assemblerkielellä, ja tehdään edelleen, koska se ei ole niin vaikeaa hyvän prosessorin ansiosta.


    • "Et ole käyttänyt Amigaa aikaisemmin?"

      Olen toki.

      "Vampire V4:n on noin 300 kertaa nopeampi, ja sillähän se käyttöjärjestelmä lentää."

      Ei se myöskään tee oikein mitään.

      "AmigaOS on moninkertaisesti kevyempi pyörittää kuin esim. Windows 95, vaikka tarjoaakin suunnilleen samat ominaisuudet."

      Sekään ei tee oikein mitään. Ankea käyttää. 80- ja 90-luvun oksennuksissa oli myös paljon bugeja vaikka eivät tehneet juuri mitään.

      "Mitä resoluutioon tulee, niin 2D-toimintapeleihin ei useinkaan tarvita enemmän kuin 640x512"

      Näyttää röpelöiseltä.

      "On vaikeaa myöskin tehdä grafiikkaa käsin bitmap-pohjaisesti korkealla resoluutiolla."

      Alkoivat jo 80-luvun puolella esirenderöimään, että pikselien asettelun sijasta kirjoitetaan vaikka skriptiä että asetellaan primitiivejä kuten pallo, kuutio, kartio, torus jne. ja skaalaillaan, tehdään CSG:tä, tai vaikka polygonimeshiä.

      Siitä saadaan sitten saadaan laskettua ns. täydellisesti halutulla resoluutiolla ja frameja niin paljon kuin haluaa. Niitä perusprimitiivejä voi nysvätä vaikka yhtä paljon kuin 320x200 tarkkuudelle sopii pikseleitä mutta saadaan laskettua vaikka 3840x2160 tarkkuudelle natiivisti.

      "Mitä tulee Raspberry Pi:hin, se ei yksinkertaiseti kelpaa, ARM/PowerPC-prosessorit ovat kehnoja, ja niitä ei voi helposti ohjelmoida assembler-kielellä."

      ARM prosessorit ovat oikein mainioita. Niissä on paljon elegantimpi käskykanta kuin Motorolassa tai Intelin/AMD:n jutuissa.

      Mutta, sillä ei ole merkitystä. Kääntäjät on keksitty sitä varten, että ei tarvitse assembleria kirjoittaa. Ennen muinoin kääntäjät oli toki alkeellisempia kun silloin yritettiin ensisijaisesti saada se kääntäjä toimimaan. Nykyään ne optimoivat. Meni jo joskus 90-luvulla sellaiseksi, että ihminen ei saanut käsin assemblerilla nysvättyä nopeammaksi. Olivat aika poikkeavia juttuja missä onnistui ja oli joku sisin silmukka missä oli kierretty kääntäjä.

      Tosin silloinkin oli vaikka käytössä kääntäjä mikä haki optimaalisen käskykombon hakemalla sitä bruteforcella jostain hakuavaruudesta, että jätetty koneet rouhimaan sitä optimaalista assemblerkoodia: https://en.wikipedia.org/wiki/Superoptimization

      Käytännössä sitten kun on kyse isomman mittakaavan optimoinneista, voi ihminen jäädä kakkoseksi kun hyödynnetään rinnakkaisuutta ja pitää varmistaa, että koodissa ei ole minkäänlaisia sivuvaikutuksia ja kehittyneet välineet auttaa varmistamaan sitä.

      Yksi merkittävä asia mikä myös pitää huomioida on bugit. Yksi ihminen ei oikein pysty hallitsemaan valtavia määriä koodia kun se koodikokonaisuus ei enää sovikkaan kehittäjän päähän. Yli 100000 rivillä alkaa tulla ongelmia joten onkin sitten tarvetta myös saada koodirivejä vähemmälle.

      "Amigalle suuri osa softasta on kuitenkin tehty assemblerkielellä, ja tehdään edelleen, koska se ei ole niin vaikeaa hyvän prosessorin ansiosta."

      Siinä ei kuitenkaan ole oikein mitään järkeä tehdä assemblerkielellä kun voi tehdä siistimmän, nopeamman, siirrettävän ja virheettömämmän käyttämällä kääntäjää.


    • m36-intj kirjoitti:

      Et ole käyttänyt Amigaa aikaisemmin? Itse käyttöjärjestelmä on suunniteltu toimimaan 8 MHz:n MC68000:lla. Vampire V4:n on noin 300 kertaa nopeampi, ja sillähän se käyttöjärjestelmä lentää. AmigaOS on moninkertaisesti kevyempi pyörittää kuin esim. Windows 95, vaikka tarjoaakin suunnilleen samat ominaisuudet. Muistiakin kuluu huomattavasti vähemmän.

      Mitä resoluutioon tulee, niin 2D-toimintapeleihin ei useinkaan tarvita enemmän kuin 640x512, mutta kyllähän sitä saa paljon enemmän tietysti Vampirella. On vaikeaa myöskin tehdä grafiikkaa käsin bitmap-pohjaisesti korkealla resoluutiolla. Lähes kaikki pelit Amigalle tehtiin 320x200 tai 320x256 resoluutiolla ja 16/32 värillä. Copper-apupiirillä sai sitten huomattavasti enemmän värejä näytölle.

      Mitä tulee Raspberry Pi:hin, se ei yksinkertaiseti kelpaa, ARM/PowerPC-prosessorit ovat kehnoja, ja niitä ei voi helposti ohjelmoida assembler-kielellä. Amigalle suuri osa softasta on kuitenkin tehty assemblerkielellä, ja tehdään edelleen, koska se ei ole niin vaikeaa hyvän prosessorin ansiosta.

      Jos nyt jostain syystä kokee, että assembler paradigmana on mitä ideaalisin niin sitä voi kirjoittaa vaikka tällä: https://webassembly.org/

      Saa modernin raudan mukavuudet käyttöön ja koodi siirrettäväksi.


    • M-Kar kirjoitti:

      "Et ole käyttänyt Amigaa aikaisemmin?"

      Olen toki.

      "Vampire V4:n on noin 300 kertaa nopeampi, ja sillähän se käyttöjärjestelmä lentää."

      Ei se myöskään tee oikein mitään.

      "AmigaOS on moninkertaisesti kevyempi pyörittää kuin esim. Windows 95, vaikka tarjoaakin suunnilleen samat ominaisuudet."

      Sekään ei tee oikein mitään. Ankea käyttää. 80- ja 90-luvun oksennuksissa oli myös paljon bugeja vaikka eivät tehneet juuri mitään.

      "Mitä resoluutioon tulee, niin 2D-toimintapeleihin ei useinkaan tarvita enemmän kuin 640x512"

      Näyttää röpelöiseltä.

      "On vaikeaa myöskin tehdä grafiikkaa käsin bitmap-pohjaisesti korkealla resoluutiolla."

      Alkoivat jo 80-luvun puolella esirenderöimään, että pikselien asettelun sijasta kirjoitetaan vaikka skriptiä että asetellaan primitiivejä kuten pallo, kuutio, kartio, torus jne. ja skaalaillaan, tehdään CSG:tä, tai vaikka polygonimeshiä.

      Siitä saadaan sitten saadaan laskettua ns. täydellisesti halutulla resoluutiolla ja frameja niin paljon kuin haluaa. Niitä perusprimitiivejä voi nysvätä vaikka yhtä paljon kuin 320x200 tarkkuudelle sopii pikseleitä mutta saadaan laskettua vaikka 3840x2160 tarkkuudelle natiivisti.

      "Mitä tulee Raspberry Pi:hin, se ei yksinkertaiseti kelpaa, ARM/PowerPC-prosessorit ovat kehnoja, ja niitä ei voi helposti ohjelmoida assembler-kielellä."

      ARM prosessorit ovat oikein mainioita. Niissä on paljon elegantimpi käskykanta kuin Motorolassa tai Intelin/AMD:n jutuissa.

      Mutta, sillä ei ole merkitystä. Kääntäjät on keksitty sitä varten, että ei tarvitse assembleria kirjoittaa. Ennen muinoin kääntäjät oli toki alkeellisempia kun silloin yritettiin ensisijaisesti saada se kääntäjä toimimaan. Nykyään ne optimoivat. Meni jo joskus 90-luvulla sellaiseksi, että ihminen ei saanut käsin assemblerilla nysvättyä nopeammaksi. Olivat aika poikkeavia juttuja missä onnistui ja oli joku sisin silmukka missä oli kierretty kääntäjä.

      Tosin silloinkin oli vaikka käytössä kääntäjä mikä haki optimaalisen käskykombon hakemalla sitä bruteforcella jostain hakuavaruudesta, että jätetty koneet rouhimaan sitä optimaalista assemblerkoodia: https://en.wikipedia.org/wiki/Superoptimization

      Käytännössä sitten kun on kyse isomman mittakaavan optimoinneista, voi ihminen jäädä kakkoseksi kun hyödynnetään rinnakkaisuutta ja pitää varmistaa, että koodissa ei ole minkäänlaisia sivuvaikutuksia ja kehittyneet välineet auttaa varmistamaan sitä.

      Yksi merkittävä asia mikä myös pitää huomioida on bugit. Yksi ihminen ei oikein pysty hallitsemaan valtavia määriä koodia kun se koodikokonaisuus ei enää sovikkaan kehittäjän päähän. Yli 100000 rivillä alkaa tulla ongelmia joten onkin sitten tarvetta myös saada koodirivejä vähemmälle.

      "Amigalle suuri osa softasta on kuitenkin tehty assemblerkielellä, ja tehdään edelleen, koska se ei ole niin vaikeaa hyvän prosessorin ansiosta."

      Siinä ei kuitenkaan ole oikein mitään järkeä tehdä assemblerkielellä kun voi tehdä siistimmän, nopeamman, siirrettävän ja virheettömämmän käyttämällä kääntäjää.

      AmigaOS ei tee mitään? Mitä sen sitten pitäisi tehdä? Tehokas moniajo, ja ikkunointijärjestelmä siinä missä nykyaikaisissa järjestelmissäkin. Helposti laajennettavissa, mikrokernelisysteemi. Esim. AmigaOS 3.1:ssa, joka oli viimeinen Commodoren tekemä käyttisversio, ei ollut TCP/IP-tukea, mutta sen pystyi helposti rakentamaan myöhemmin ethernet-driverina ja nettiapplikaationa, joka käytti driveria, joka ei olisi mahdollista esim. Linuxissa, koska kaikki driverit kuuluvat kerneliin.

      Amigalle saa myös useimmat GNU-työkalut, kuten make, awk, gcc, sed, latex, emacs, gnuplot, jne. Ne eivät tarvitse Linuxia toimiakseen. Nykyään niitä ei tosin enää ylläpidetä, uudemmat versiot olisikin vaikeaa saada toimimaan enää Amigalle, niiden binäärit ovat paisuneet kuin pullataikina, tuomatta juurikaan lisäarvoa käyttäjille.

      Jos tarkoitat ray-tracingia ja vastaavia tekniikoita, niin toki niitä renderöityjä grafiikoita tehtiin joihinkin Amiga-peleihin, kuten esim. Stardustiin, mutta tuo menetelmä ei vaan sovi kaikenlaisen grafiikan tekemiseen.

      Se nyt ei pidä paikkaansa, että kääntäjät pystyisivät tekemään parempaa koodia kuin kokenut assemblerohjelmoija. gcc:n m68k-backend tuotti heikkoa koodia vielä 90-luvun lopulla, ja siinä pystyi helposti kirjoittamaan parempaa koodia, vaikka ihan yksinkertaisesta loopista. Sen jälkeen m68k tuki lopetettiin gcc:stä. Tein joskus myös työtä 2000-luvun lopulla Texas Instrumentsin DSP C-kääntäjän kanssa, sen tuottama DSP-koodi oli myös surkeaa, ja sen vuoksi siinä oli valmiit optimoidut DSP-rutiinit assemblerkielellä toteutettuna, joita sitten käytettiin C-ohjelmissa.

      Kun nyt katselen omia strategioitani lyhentää assemblerkoodiani, niin makroja voi käyttää myös assemblerilla, ja usein käytetyt valmiit rutiinit voi kääntää binääriksi tiedostoon ja ladata ohjelmaan, johon sitten vain hypätään. Näin ohjelmarivien määrä saadaan alaspäin.

      ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. Elegantti se ei ainakaan ole assemblerohjelmoijan näkökulmasta. Asiaa on käsitelty aikaisemmin tässä ketjussa.

      Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL).


    • m36-intj kirjoitti:

      AmigaOS ei tee mitään? Mitä sen sitten pitäisi tehdä? Tehokas moniajo, ja ikkunointijärjestelmä siinä missä nykyaikaisissa järjestelmissäkin. Helposti laajennettavissa, mikrokernelisysteemi. Esim. AmigaOS 3.1:ssa, joka oli viimeinen Commodoren tekemä käyttisversio, ei ollut TCP/IP-tukea, mutta sen pystyi helposti rakentamaan myöhemmin ethernet-driverina ja nettiapplikaationa, joka käytti driveria, joka ei olisi mahdollista esim. Linuxissa, koska kaikki driverit kuuluvat kerneliin.

      Amigalle saa myös useimmat GNU-työkalut, kuten make, awk, gcc, sed, latex, emacs, gnuplot, jne. Ne eivät tarvitse Linuxia toimiakseen. Nykyään niitä ei tosin enää ylläpidetä, uudemmat versiot olisikin vaikeaa saada toimimaan enää Amigalle, niiden binäärit ovat paisuneet kuin pullataikina, tuomatta juurikaan lisäarvoa käyttäjille.

      Jos tarkoitat ray-tracingia ja vastaavia tekniikoita, niin toki niitä renderöityjä grafiikoita tehtiin joihinkin Amiga-peleihin, kuten esim. Stardustiin, mutta tuo menetelmä ei vaan sovi kaikenlaisen grafiikan tekemiseen.

      Se nyt ei pidä paikkaansa, että kääntäjät pystyisivät tekemään parempaa koodia kuin kokenut assemblerohjelmoija. gcc:n m68k-backend tuotti heikkoa koodia vielä 90-luvun lopulla, ja siinä pystyi helposti kirjoittamaan parempaa koodia, vaikka ihan yksinkertaisesta loopista. Sen jälkeen m68k tuki lopetettiin gcc:stä. Tein joskus myös työtä 2000-luvun lopulla Texas Instrumentsin DSP C-kääntäjän kanssa, sen tuottama DSP-koodi oli myös surkeaa, ja sen vuoksi siinä oli valmiit optimoidut DSP-rutiinit assemblerkielellä toteutettuna, joita sitten käytettiin C-ohjelmissa.

      Kun nyt katselen omia strategioitani lyhentää assemblerkoodiani, niin makroja voi käyttää myös assemblerilla, ja usein käytetyt valmiit rutiinit voi kääntää binääriksi tiedostoon ja ladata ohjelmaan, johon sitten vain hypätään. Näin ohjelmarivien määrä saadaan alaspäin.

      ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. Elegantti se ei ainakaan ole assemblerohjelmoijan näkökulmasta. Asiaa on käsitelty aikaisemmin tässä ketjussa.

      Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL).

      "Mitä sen sitten pitäisi tehdä?"

      Esimerkiksi saada samaan järjestelmään useita samanaikaisia käyttäjiä ja suojattua eri käyttäjiä toisiltaan, kuin suojattua myös eri ohjelmia toisiltaan.

      Tietojenkäsittelyn rinnakkaistaminen on myös kova juttu. Jos nyt seurailee vaikka tätä vuosikymmenien kehitystä niin pari asiaa vaikuttaa vahvasti:

      1. Von Neummannin pullonkaula.

      Tarkoittaa sitä, että piirit kyllä laskevat kokoajan paremmalla hyötysuhteella mutta siinä on pullonkaulaa ja latenssia kun haetaan tietoa hitaammasta muistista

      https://en.wikipedia.org/wiki/Von_Neumann_architecture#Von_Neumann_bottleneck

      2. Rinnakkaistaminen

      Yhtä laskevaa yksikköä ei voida nopeuttaaa kuin tiettyyn pisteeseen saakka, että prosessointia pitää saada skaalattua mahdollisimman paljon jakamalla sitä useille suoritinyksiköille. Alkaen vaikka lisäämällä CPU-ytimiä, GPU-ytimiä, palvelimia jne.

      Rinnakkaistamiselle sitten on omat rajansa myös.

      A = B + C
      D = A + E

      Niin ei tuo rinnakkaistu koska jälkimmäinen operaatio riippuu aikaisemmasta. Rinnakkaistamiselle on myös tällainen efekti mikä liittyy latenssiin: https://en.wikipedia.org/wiki/Amdahl's_law

      Eli siis kuinka siis maksimoidaan laskennan rinnakkaistumista ja minimoidaan Von Neumannin pullonkaulan vaikutusta on avainjuttu kun revitään suorituskykyä.

      Nuo pätevät universaalisti mille tahansa raudalle ja tarkoittaa käytännössä sitä, että käsiteltävä data pitäisi saada sopimaan mahdollisimman nopeaan muistiin ja rinnakkaistettua suoritinytimille mitä koneessa tai vaikka useassa keskusyksikössä.

      "Nykyään niitä ei tosin enää ylläpidetä, uudemmat versiot olisikin vaikeaa saada toimimaan enää Amigalle, niiden binäärit ovat paisuneet kuin pullataikina, tuomatta juurikaan lisäarvoa käyttäjille."

      GNU projektin peruspalikoissa on aika paljon ominaisuuksia että en nyt niitä ottaisi minimalistiseen systeemiin muutenkaan. Tämä taitaa olla viimeisin mikä uppoaa Amigaan ja siinä on rapsittu ylimääräiset pois peruspalikoista: https://www.openbsd.org/55.html

      Koodi on myös kohtalaisen siivottua, että pystyisi mergettämään tuoreimmasta OpenBSD:stä korjaukset.

      "Se nyt ei pidä paikkaansa, että kääntäjät pystyisivät tekemään parempaa koodia kuin kokenut assemblerohjelmoija."

      Pystyy, kun käy vaikka bruteforcella läpi mikä on optimaalisen käskysarjan tai sitten kun tulee nämä mitkä toimii isommassa mittakaavassa, että rinnakkaistetaan ja sitten jos vaikka pitää kopioida puurakenne paikasta toiseen niin tuotetaan koodia missä kopioidaan vain pointteri ja samaa rakennetta käytetään useassa säikeessä kun kääntäjä varmistaa, että siinä koodissa ei ole yhtään sivuvaikutuksia mikä estää tämän.

      GCC tuskin tuotti optimaalista 68k koodia missään kohtaan. Tuskin sitä kehitettiin enää ihmeemmin kun 68k prossut väistyi silloin 90-luvulla. Assemblerilla sai Intelille hinkattua Pentium II vehkeillä mutta sen jälkeen meni kääntäjäteknologia kuin myös prosessorien sisäinen käskydekooderi ja suoritusjärjestyksen optimointi sellaiseksi, että menetti merkityksen. C:llä sai oikeastaan aina yhtä hyvää. Ehkä just joku silmukka jossain missä otettiin SIMD huomioon ja bruteforcella kävi että sai sieltä sisimmästä silmukasta viimeisimmät kellojaksot pois mutta se oli sitten siinä. 90-luvun lopulla assembler oli jo hyvin merkityksetön.

      Käytännön ohjelmoinnissa kompleksisuuden hallinta on aika keskeistä, myös suorituskykyä optimoidessa.

      Noin esimerkiksi, C:llä saa oikein hyvin tehtyä optimoituja ja kapseloituja komponentteja mutta nimiavaruus rajoittaa scopettamista. Se onkin suunniteltu niukemmille muistimäärille ja että tehdään komponentteja joita joissa datavirtoja putkitetaan: https://en.wikipedia.org/wiki/Pipeline_(Unix)

      Ja tietysti kun jokainen komponentti on omassa prosessissa ja kommunikoi käyttöjärjestelmän putkien kanssa niin siitä tulee myös hävikkiä vaikka tuossa käyttöjärjestelmä rinnakkaistaa. Joku service mikä käynnistää aina palikan tekee latenssia.

      Muistinkulutus pysyy pienenä toki mutta tässä on abstraktiohävikkiä, että voi olla kiinnostuksia ajaa kokonaisuutta enemmän samassa prosessissa. Sitä varten sitten on vaikka oliokieliä kuten vaikka C++ missä suurempi nimiavaruus, että voi saman prosessin sisälle rakentaa niitä kapseloituja komponentteja.

      Kieli on kompleksisempi mutta tuo itseasiassa helposti suuremman suorituskyvyn kapseloiduilla komponenteilla kun jää se abstraktiohävikki pois kun ajetaan samassa prosessissa niitä komponentteja. Ja uudemmat kääntäjät sitten osaa tehdä isomman mittakaavan optimointia kun käyvät kaikkien komponenttien koodimassaa läpi mitä siihen käännökseen tulee. Sattumalta uudemmat kääntäjät alkoikin sitten rohmuta muistia paljon enemmän siinä käännöksessä mutta tuo tulee siitä, kun pyrkivät käsittelemään koko koodimassaa muistissa yhtenä käännettävänä kokonaisuutena, eikä niin että käännetään vaikka sed:istä yksi palikka ja cat:ista toinen.


    • M-Kar kirjoitti:

      "Mitä sen sitten pitäisi tehdä?"

      Esimerkiksi saada samaan järjestelmään useita samanaikaisia käyttäjiä ja suojattua eri käyttäjiä toisiltaan, kuin suojattua myös eri ohjelmia toisiltaan.

      Tietojenkäsittelyn rinnakkaistaminen on myös kova juttu. Jos nyt seurailee vaikka tätä vuosikymmenien kehitystä niin pari asiaa vaikuttaa vahvasti:

      1. Von Neummannin pullonkaula.

      Tarkoittaa sitä, että piirit kyllä laskevat kokoajan paremmalla hyötysuhteella mutta siinä on pullonkaulaa ja latenssia kun haetaan tietoa hitaammasta muistista

      https://en.wikipedia.org/wiki/Von_Neumann_architecture#Von_Neumann_bottleneck

      2. Rinnakkaistaminen

      Yhtä laskevaa yksikköä ei voida nopeuttaaa kuin tiettyyn pisteeseen saakka, että prosessointia pitää saada skaalattua mahdollisimman paljon jakamalla sitä useille suoritinyksiköille. Alkaen vaikka lisäämällä CPU-ytimiä, GPU-ytimiä, palvelimia jne.

      Rinnakkaistamiselle sitten on omat rajansa myös.

      A = B + C
      D = A + E

      Niin ei tuo rinnakkaistu koska jälkimmäinen operaatio riippuu aikaisemmasta. Rinnakkaistamiselle on myös tällainen efekti mikä liittyy latenssiin: https://en.wikipedia.org/wiki/Amdahl's_law

      Eli siis kuinka siis maksimoidaan laskennan rinnakkaistumista ja minimoidaan Von Neumannin pullonkaulan vaikutusta on avainjuttu kun revitään suorituskykyä.

      Nuo pätevät universaalisti mille tahansa raudalle ja tarkoittaa käytännössä sitä, että käsiteltävä data pitäisi saada sopimaan mahdollisimman nopeaan muistiin ja rinnakkaistettua suoritinytimille mitä koneessa tai vaikka useassa keskusyksikössä.

      "Nykyään niitä ei tosin enää ylläpidetä, uudemmat versiot olisikin vaikeaa saada toimimaan enää Amigalle, niiden binäärit ovat paisuneet kuin pullataikina, tuomatta juurikaan lisäarvoa käyttäjille."

      GNU projektin peruspalikoissa on aika paljon ominaisuuksia että en nyt niitä ottaisi minimalistiseen systeemiin muutenkaan. Tämä taitaa olla viimeisin mikä uppoaa Amigaan ja siinä on rapsittu ylimääräiset pois peruspalikoista: https://www.openbsd.org/55.html

      Koodi on myös kohtalaisen siivottua, että pystyisi mergettämään tuoreimmasta OpenBSD:stä korjaukset.

      "Se nyt ei pidä paikkaansa, että kääntäjät pystyisivät tekemään parempaa koodia kuin kokenut assemblerohjelmoija."

      Pystyy, kun käy vaikka bruteforcella läpi mikä on optimaalisen käskysarjan tai sitten kun tulee nämä mitkä toimii isommassa mittakaavassa, että rinnakkaistetaan ja sitten jos vaikka pitää kopioida puurakenne paikasta toiseen niin tuotetaan koodia missä kopioidaan vain pointteri ja samaa rakennetta käytetään useassa säikeessä kun kääntäjä varmistaa, että siinä koodissa ei ole yhtään sivuvaikutuksia mikä estää tämän.

      GCC tuskin tuotti optimaalista 68k koodia missään kohtaan. Tuskin sitä kehitettiin enää ihmeemmin kun 68k prossut väistyi silloin 90-luvulla. Assemblerilla sai Intelille hinkattua Pentium II vehkeillä mutta sen jälkeen meni kääntäjäteknologia kuin myös prosessorien sisäinen käskydekooderi ja suoritusjärjestyksen optimointi sellaiseksi, että menetti merkityksen. C:llä sai oikeastaan aina yhtä hyvää. Ehkä just joku silmukka jossain missä otettiin SIMD huomioon ja bruteforcella kävi että sai sieltä sisimmästä silmukasta viimeisimmät kellojaksot pois mutta se oli sitten siinä. 90-luvun lopulla assembler oli jo hyvin merkityksetön.

      Käytännön ohjelmoinnissa kompleksisuuden hallinta on aika keskeistä, myös suorituskykyä optimoidessa.

      Noin esimerkiksi, C:llä saa oikein hyvin tehtyä optimoituja ja kapseloituja komponentteja mutta nimiavaruus rajoittaa scopettamista. Se onkin suunniteltu niukemmille muistimäärille ja että tehdään komponentteja joita joissa datavirtoja putkitetaan: https://en.wikipedia.org/wiki/Pipeline_(Unix)

      Ja tietysti kun jokainen komponentti on omassa prosessissa ja kommunikoi käyttöjärjestelmän putkien kanssa niin siitä tulee myös hävikkiä vaikka tuossa käyttöjärjestelmä rinnakkaistaa. Joku service mikä käynnistää aina palikan tekee latenssia.

      Muistinkulutus pysyy pienenä toki mutta tässä on abstraktiohävikkiä, että voi olla kiinnostuksia ajaa kokonaisuutta enemmän samassa prosessissa. Sitä varten sitten on vaikka oliokieliä kuten vaikka C++ missä suurempi nimiavaruus, että voi saman prosessin sisälle rakentaa niitä kapseloituja komponentteja.

      Kieli on kompleksisempi mutta tuo itseasiassa helposti suuremman suorituskyvyn kapseloiduilla komponenteilla kun jää se abstraktiohävikki pois kun ajetaan samassa prosessissa niitä komponentteja. Ja uudemmat kääntäjät sitten osaa tehdä isomman mittakaavan optimointia kun käyvät kaikkien komponenttien koodimassaa läpi mitä siihen käännökseen tulee. Sattumalta uudemmat kääntäjät alkoikin sitten rohmuta muistia paljon enemmän siinä käännöksessä mutta tuo tulee siitä, kun pyrkivät käsittelemään koko koodimassaa muistissa yhtenä käännettävänä kokonaisuutena, eikä niin että käännetään vaikka sed:istä yksi palikka ja cat:ista toinen.

      Toki se oliorakenne tuo myös oman abstraktiohävikkinsä mutta uuden prosessin käynnistäminen vie helposti enemmän aikaa kuin alustaa uusi luokka samassa prosessissa.

      "ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. "

      Ei päde: https://www.howtogeek.com/393139/mobile-cpus-are-now-as-fast-as-your-desktop-pc/

      "Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL)."

      Asian juttu se että miksi se pitää saada toimimaan Amigalla kun koodi toimii siirrettävästi, suorituskykyisemmin, pienemmillä wateilla, paremmilla ominaisuuksilla ja halvemmalla Raspberry Pi 4:llä?

      Tuo on kuitenkin Amigaan verrattuna supertietokone.


    • M-Kar kirjoitti:

      Toki se oliorakenne tuo myös oman abstraktiohävikkinsä mutta uuden prosessin käynnistäminen vie helposti enemmän aikaa kuin alustaa uusi luokka samassa prosessissa.

      "ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. "

      Ei päde: https://www.howtogeek.com/393139/mobile-cpus-are-now-as-fast-as-your-desktop-pc/

      "Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL)."

      Asian juttu se että miksi se pitää saada toimimaan Amigalla kun koodi toimii siirrettävästi, suorituskykyisemmin, pienemmillä wateilla, paremmilla ominaisuuksilla ja halvemmalla Raspberry Pi 4:llä?

      Tuo on kuitenkin Amigaan verrattuna supertietokone.

      Taitaa aika monella nykyisellä Amigan käyttäjällä olla jonkinlaista fanaattisuutta, kun pitävät kiinni vanhasta systeemistä, vaikka se onkin teholtaan aika vaatimaton ja siitä puuttuu monia nykyajan mukavuuksia (esmes kunnon rullahiirituki).

      Itsekin kyllä mielelläni verestäisin vanhoja muistoja, mutta meikän Amiga hajosi aikoja sitten. Se oli kyllä yleiseen tasoon verrattuna melko kova mylly (060/50, 16 megaa muistia, Voodoo 3 1600x1200/16 bit), mutta ei tietenkään vedä vertoja tuolle Vampirelle tai edes PPC-Amigoille. Tosin AmigaOS 4:n etuna olisi, että sille ilmeisesti saisi jopa Qt Creatorin...


    • M-Kar kirjoitti:

      Toki se oliorakenne tuo myös oman abstraktiohävikkinsä mutta uuden prosessin käynnistäminen vie helposti enemmän aikaa kuin alustaa uusi luokka samassa prosessissa.

      "ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. "

      Ei päde: https://www.howtogeek.com/393139/mobile-cpus-are-now-as-fast-as-your-desktop-pc/

      "Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL)."

      Asian juttu se että miksi se pitää saada toimimaan Amigalla kun koodi toimii siirrettävästi, suorituskykyisemmin, pienemmillä wateilla, paremmilla ominaisuuksilla ja halvemmalla Raspberry Pi 4:llä?

      Tuo on kuitenkin Amigaan verrattuna supertietokone.

      Hienoa teoriaa, mutta pysytään aiheessa: m68k:lle ei ole mitään hyvää C-kääntäjää, joka tuottaisi hyvää koodia. Ei tietystikään myöskään 68080:lle ja AMMX:lle. Tässä kyllä yritettiin tehdä jotakin backendiä gcc:lle, mutta homma osoittautui liian monimutkaiseksi.

      Ja tuskin koodingenerointi toimii optimaalisesti monille muillekaan alustoille. En ole kokeillut ARM/x64-alustoja, mutta epäilen että tässäkään ei optimaalisuus toteudu kaikissa skenaarioissa. Ongelmana ei näissä järjestelmissä muutenkaan ole koodin laatu, vaan yleinen bloatti, liikaa softakerroksia ja muuta roinaa välissä.

      Hyvä asia vaan että ARM on saamassa prosessoreitaan paremmiksi kuin Intel, vielä muutama vuosi sitten ARM oli selvästi hitaampi kuin Intelin prosessorit. Intelin prosessorit ovatkin sisäisesti rumia, hyvä että kostautuu jossakin vaiheessa.

      M68k-prosessorit olivat aina parempia kuin Intelin vastaavat. Toivottavasti nekin löydetään uudelleen, uudemmilla valmistustekniikoilla saisi esim. 68060:n kellotaajuuden nostettua ihan uusille lukemille. M68k:t ovat ARM:n tapaan myös energiatehokkaita, mutta niissä on myös paras kooditiheys (code density) kaikista tavallisista prosessoreista, mikä myös parantaa suorituskykyä.


    • m36-intj kirjoitti:

      Hienoa teoriaa, mutta pysytään aiheessa: m68k:lle ei ole mitään hyvää C-kääntäjää, joka tuottaisi hyvää koodia. Ei tietystikään myöskään 68080:lle ja AMMX:lle. Tässä kyllä yritettiin tehdä jotakin backendiä gcc:lle, mutta homma osoittautui liian monimutkaiseksi.

      Ja tuskin koodingenerointi toimii optimaalisesti monille muillekaan alustoille. En ole kokeillut ARM/x64-alustoja, mutta epäilen että tässäkään ei optimaalisuus toteudu kaikissa skenaarioissa. Ongelmana ei näissä järjestelmissä muutenkaan ole koodin laatu, vaan yleinen bloatti, liikaa softakerroksia ja muuta roinaa välissä.

      Hyvä asia vaan että ARM on saamassa prosessoreitaan paremmiksi kuin Intel, vielä muutama vuosi sitten ARM oli selvästi hitaampi kuin Intelin prosessorit. Intelin prosessorit ovatkin sisäisesti rumia, hyvä että kostautuu jossakin vaiheessa.

      M68k-prosessorit olivat aina parempia kuin Intelin vastaavat. Toivottavasti nekin löydetään uudelleen, uudemmilla valmistustekniikoilla saisi esim. 68060:n kellotaajuuden nostettua ihan uusille lukemille. M68k:t ovat ARM:n tapaan myös energiatehokkaita, mutta niissä on myös paras kooditiheys (code density) kaikista tavallisista prosessoreista, mikä myös parantaa suorituskykyä.

      "Hienoa teoriaa, mutta pysytään aiheessa: m68k:lle ei ole mitään hyvää C-kääntäjää, joka tuottaisi hyvää koodia."

      Nykypäivänä on helpompaa tehdä oma kääntäjä joka optimoi kuin kirjoitella assembleria. Tekee vaikka oman backendin LLVM:lle. Saa just niin hyvän kuin itse osaa optimoida.

      "Ongelmana ei näissä järjestelmissä muutenkaan ole koodin laatu, vaan yleinen bloatti, liikaa softakerroksia ja muuta roinaa välissä."

      Nyt en ihan käsitä... Ihan ohjelmoijasta se on kiinni mitä kerroksia sinne haluaa.

      Backendissä käytännössä I/O kerros siellä se, että ne vie aikaa kun vaikka tehdään tiedosto, luetaan tai kirjoitetaan. Kaikki muu koodi sitten voidaan ajaa ilman mitään roinaa.

      Frontendissä sitten on ohut kerros missä webassembly käännetään prosessorin natiiviksi JIT:llä mutta se vaikuttaa vain moduulin käynnistykseen. Shaderit käännetään sitten suoraan GPU:lle niin, että siellä ei ole mitään välissä.

      " M68k:t ovat ARM:n tapaan myös energiatehokkaita, mutta niissä on myös paras kooditiheys (code density) kaikista tavallisista prosessoreista, mikä myös parantaa suorituskykyä."

      Koodin tiheys lähinnä auttaa siinä, että välimuistiin sopii enemmän. Kasvattamalla välimuistin kokoa, tuo etu menee.

      Käskyjen dekoodaaminen RISC käskyiksi tosin vaatii piiriltä tilaa ja voi vaatia osia mitä ajetaan tupla tai tripla kelloilla, ja sitten tulee ongelmia nostaa normikellotaajuutta kun siellä sellaisia kuumana käyviä pisteitä siellä sirulla.

      Nuo prosessorien tavukoodit mitä nyt on käytössä, ovat kaikki vanhoja. Ei ole mitenkään mahdotonta rakentaa uutta tavukoodia mitä tehty sen mukaan mitä nykyisin tiedetään pullonkauloista piirisuunnittelussa.

      Ohjelmoijalle sillä ei ole väliä. Kaikki koodi kirjoitetaan kuitenkin mahdollisimman korkealla tasolla ja käännetään alustan ymmärtämään muotoon, että sillä ei ole väliä vaikka prosessorin tai runtimen tavukoodin muoto vaihtuu.

      Lopputulos siis se, että hinta, watit ja suorituskyky ratkaisee ja lähtökohta on se, että toimii oikein. Jos on buginen tai ei toimi niin se on sitten paska.


    • Ja täytyy mainita että itse en ole vielä hankkinut ensimmäistäkään Vampire-korttia, koska pidän koko projektia vielä keskeneräisenä.

      Ja en kyllä hankkisi tuota A500/A600-malleille. Siinä nyt on ongelmia mm. virtalähteen kanssa, pitää ehkä hankkia isompi, alkuperäinen virtalähde ei välttämättä käy. Ja sitten pitää ehkä jotain kondensaattoreita vaihtaa/poistaa emolevyltä. Lisäksi ei välttämättä kovin stabiili tuo kortti, kun pitää kytkeä kiinni ruuveilla alkuperäisen prosessorin päälle. A1200:ssa on sentään laajennusportti, johon kortti vaan laitetaan kiinni. Noissa V2-malleissa lisäksi osittainen softFPU ja ei AGA-tukea. SAGA on vielä keskeneräinen ja ei kelpaa minulle lainkaan. Blitter myös softapohjaisesti emuloitu CPU:lla. Siinä lähtee mukavasti tehot, kun ei ole oikeaa blitteripiiriä rakennettu FPGA:lla, ja tämä ei vastaa lainkaan alkuperäistä Amiga-arkkitehtuuria jossa blitteri pystyi toimimaan rinnakkain prosessorin kanssa.

      On jäänyt kyllä huono maku suuhun koko apollocore FPGA-projektista. V4 ei ole vieläkään valmis, ei taida olla tiimillä resursseja saada valmiiksi asioita. Olisivat tyytyneet vain 68080-FPGA prosessoriin, jonka sitten saisi laajennuskorttina muistilla varustettuna.


  • Näin tubessa videon jossa 500:n Amigan oikean kyljen laajennusporttiin tökättiin joku uusi piirikortti ja käyttöjärjestelmäpäivitys joka toi Amigan nykypäivän tasolle, mm. internet yhteys.
    Tavallaan ihan hienoa mutta en halua kuitenkaan tehdä moista omalle 500:lleni koska Amigalla haluan retroilla, tehdä asiat juuri kuten silloin joskus enkä halua siitä tämän päivän konetta. Eri asia jos julkaistaisiin joku ihan uusi Amiga malli joka olisi alunperinkin tämän päivän tasolla. Olisihan se taas hienoa mennä kauppaan ostamaan uusi Amiga :D

    • Perkele siis Amigan VASEMMAN kyljen laajennusporttiin!!


  • Tässä oli juttua äskettäin V4-standalone laitteesta, joka on siis täydellinen uusi Amiga FPGA:na implementoituna. Sen täytyy siis implementoida kaikki Amigan rauta, niin että kaikki vanha softa toimii muutoksitta.

    Ongelmia tulee lähinnä siinä että miten uusi rauta sopii yhteen vanhan Amigan kanssa. Hyvä uutinen on että siihen voi liittää nykyaikaisen USB-näppäimistön ja hiiren. Laite ei kuitenkaan tarvitse mitään USB-drivereita, vaan kaikki on FPGA:lla toteutettu, jonkinlainen oma toteutus USB:sta, joka myös toteuttaa vanhan Amigan hardware-rajapinnan. Demot ja pelit siis pitäisi toimia USB-näppäimistön ja hiiren kanssa, vaikka ne kytkevät pois käyttöjärjestelmän.

    Ehkä muutkin ottavat oppia, nykyaikainen hardware on rumaa. Vanhassa Amigassa pystyi helposti tekemään oman pienen driverin näppäimistölle / hiirelle, kun käyttöjärjestelmän kytki pois päältä, jotka olivat ehkä yhteensä sata riviä assemblerkoodia. USB-hardware/protokolla on sen sijaan monimutkainen kokonaisuus, jonka monimutkaisuutta ei tarvita hiiren/näppäimistön hallintaan.

  • Mutta nykyaikainen softa on kaunista. Vanhat ohjelmat ovat pääsääntöisesti kauheita.

Ketjusta on poistettu 1 sääntöjenvastaista viestiä.