Lue keskustelun säännöt.
MIPS-simulaattori komentokehotteessa
18.04.2016 |
Eli haluan tietää MIPS-simulaattorin jossa on tekstipohjainen käyttöliittymä (esimerkiksi ncurses). Onko ehdotuksi tai suosituksia?
Kommentit (14)
Sisältö jatkuu mainoksen alla
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
miksi shelliversio?
Koska helpompi käyttää SSH:n kautta, varsinkin jos yhteys on hidas.
Vierailija kirjoitti:
Vierailija kirjoitti:
miksi shelliversio?
Koska helpompi käyttää SSH:n kautta, varsinkin jos yhteys on hidas.
Hmm, olet niin nyyppä ettet osaa putkittaa ssh:n kautta työikkunaa mutta kuitenkin käytät mips-simulaattoria. Toisaalta olet niin nyyppä että koitat käyttää sitä toiselta koneelta ssh:n kautta.
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
miksi shelliversio?
Koska helpompi käyttää SSH:n kautta, varsinkin jos yhteys on hidas.
Hmm, olet niin nyyppä ettet osaa putkittaa ssh:n kautta työikkunaa mutta kuitenkin käytät mips-simulaattoria. Toisaalta olet niin nyyppä että koitat käyttää sitä toiselta koneelta ssh:n kautta.
Taidat itse olla nyypiö, kun et ymmärrä, että totta vtus GUI:n ajaminen hitaalla ja varsinkin jos on paljon latenssia imee verrattuna terminaalissa ajettuun versioon verrattuna. (n)cursesta käyttävä softa pyörii hyvin screenissä tai tmux:n alla, vaikka linja olisi alle 9600bps ja pieni pätkiminenkään ei haittaa kun reconnect on helppo ja nopea tehdä uudestaan kun yhteys palaa jotakuinkin toimivaksi., esim. tunnelin tai ruuhkaisen aseman jälkeen.
Olen joskus korjannut junasta tuhansien kilometrien päässä olevia asiakkaiden konfiksia, nostanut yksittäisistä palveluista aina klustereiden koneiden resetointeihin hallitusti yksi kerrallaan, vaikka loss rate on ollut linjalla 50% rikkinäisen reitityksen vuoksi (puolet paluupaketeista hukkuu, kun on kaksi uplinkkiä ja toinen reitti kauempana uplinkistä rikki, eikä käytössä järkevästi tehtyä reititystä, joka droppaisi rikkinäisen reitin ts. BGP konffattu väärin)
GUI:t on ihan kivoja, tunneloitunakin jos yhteys on nopea ja stabiili, mutta vain reaalimaailman tilanteista kokematon aloittelija tai päivänsä labraolosuhteissa tai jossain pelkän RD parissa koskaan kentällä käymätön teoreetikko voi olettaa pärjäävänsä niillä aina.
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
miksi shelliversio?
Koska helpompi käyttää SSH:n kautta, varsinkin jos yhteys on hidas.
Hmm, olet niin nyyppä ettet osaa putkittaa ssh:n kautta työikkunaa mutta kuitenkin käytät mips-simulaattoria. Toisaalta olet niin nyyppä että koitat käyttää sitä toiselta koneelta ssh:n kautta.
Taidat itse olla nyypiö, kun et ymmärrä, että totta vtus GUI:n ajaminen hitaalla ja varsinkin jos on paljon latenssia imee verrattuna terminaalissa ajettuun versioon verrattuna. (n)cursesta käyttävä softa pyörii hyvin screenissä tai tmux:n alla, vaikka linja olisi alle 9600bps ja pieni pätkiminenkään ei haittaa kun reconnect on helppo ja nopea tehdä uudestaan kun yhteys palaa jotakuinkin toimivaksi., esim. tunnelin tai ruuhkaisen aseman jälkeen.
Olen joskus korjannut junasta tuhansien kilometrien päässä olevia asiakkaiden konfiksia, nostanut yksittäisistä palveluista aina klustereiden koneiden resetointeihin hallitusti yksi kerrallaan, vaikka loss rate on ollut linjalla 50% rikkinäisen reitityksen vuoksi (puolet paluupaketeista hukkuu, kun on kaksi uplinkkiä ja toinen reitti kauempana uplinkistä rikki, eikä käytössä järkevästi tehtyä reititystä, joka droppaisi rikkinäisen reitin ts. BGP konffattu väärin)
GUI:t on ihan kivoja, tunneloitunakin jos yhteys on nopea ja stabiili, mutta vain reaalimaailman tilanteista kokematon aloittelija tai päivänsä labraolosuhteissa tai jossain pelkän RD parissa koskaan kentällä käymätön teoreetikko voi olettaa pärjäävänsä niillä aina.
Bingo.
SSH ja TUI toimii kun junan vessa. Varsinkin hitailla ja epävakailla yhteyksillä graafinen käyttöliittymä SSH:n kautta (olen yrittänyt, joten naamat umpeen) on yhtä helvettiä. Yleensä ohjelman saa käyntiin, mutta työtä sillä ei pysty tekemään.
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
miksi shelliversio?
Koska helpompi käyttää SSH:n kautta, varsinkin jos yhteys on hidas.
Hmm, olet niin nyyppä ettet osaa putkittaa ssh:n kautta työikkunaa mutta kuitenkin käytät mips-simulaattoria. Toisaalta olet niin nyyppä että koitat käyttää sitä toiselta koneelta ssh:n kautta.
Taidat itse olla nyypiö, kun et ymmärrä, että totta vtus GUI:n ajaminen hitaalla ja varsinkin jos on paljon latenssia imee verrattuna terminaalissa ajettuun versioon verrattuna. (n)cursesta käyttävä softa pyörii hyvin screenissä tai tmux:n alla, vaikka linja olisi alle 9600bps ja pieni pätkiminenkään ei haittaa kun reconnect on helppo ja nopea tehdä uudestaan kun yhteys palaa jotakuinkin toimivaksi., esim. tunnelin tai ruuhkaisen aseman jälkeen.
Olen joskus korjannut junasta tuhansien kilometrien päässä olevia asiakkaiden konfiksia, nostanut yksittäisistä palveluista aina klustereiden koneiden resetointeihin hallitusti yksi kerrallaan, vaikka loss rate on ollut linjalla 50% rikkinäisen reitityksen vuoksi (puolet paluupaketeista hukkuu, kun on kaksi uplinkkiä ja toinen reitti kauempana uplinkistä rikki, eikä käytössä järkevästi tehtyä reititystä, joka droppaisi rikkinäisen reitin ts. BGP konffattu väärin)
GUI:t on ihan kivoja, tunneloitunakin jos yhteys on nopea ja stabiili, mutta vain reaalimaailman tilanteista kokematon aloittelija tai päivänsä labraolosuhteissa tai jossain pelkän RD parissa koskaan kentällä käymätön teoreetikko voi olettaa pärjäävänsä niillä aina.
Kerro vielä oi guru että miksi ajat sitä mipsi-simulaattoriasi ssh:n yli 9600 modeemilinjalla (mistä helvetistä edes löysit näin hitaan liittymän 2010-luvulla). Prosessorisimulaattoria käytetään tyypillisesti softakehityksessä ja järkevin vaihtoehto olisi ajaa sitä lokaalikoneella tai vaikka (googlen avulla löytyvillä) weppiversioilla jos sitä on pakko verkon yli ajaa.
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
miksi shelliversio?
Koska helpompi käyttää SSH:n kautta, varsinkin jos yhteys on hidas.
Hmm, olet niin nyyppä ettet osaa putkittaa ssh:n kautta työikkunaa mutta kuitenkin käytät mips-simulaattoria. Toisaalta olet niin nyyppä että koitat käyttää sitä toiselta koneelta ssh:n kautta.
Taidat itse olla nyypiö, kun et ymmärrä, että totta vtus GUI:n ajaminen hitaalla ja varsinkin jos on paljon latenssia imee verrattuna terminaalissa ajettuun versioon verrattuna. (n)cursesta käyttävä softa pyörii hyvin screenissä tai tmux:n alla, vaikka linja olisi alle 9600bps ja pieni pätkiminenkään ei haittaa kun reconnect on helppo ja nopea tehdä uudestaan kun yhteys palaa jotakuinkin toimivaksi., esim. tunnelin tai ruuhkaisen aseman jälkeen.
Olen joskus korjannut junasta tuhansien kilometrien päässä olevia asiakkaiden konfiksia, nostanut yksittäisistä palveluista aina klustereiden koneiden resetointeihin hallitusti yksi kerrallaan, vaikka loss rate on ollut linjalla 50% rikkinäisen reitityksen vuoksi (puolet paluupaketeista hukkuu, kun on kaksi uplinkkiä ja toinen reitti kauempana uplinkistä rikki, eikä käytössä järkevästi tehtyä reititystä, joka droppaisi rikkinäisen reitin ts. BGP konffattu väärin)
GUI:t on ihan kivoja, tunneloitunakin jos yhteys on nopea ja stabiili, mutta vain reaalimaailman tilanteista kokematon aloittelija tai päivänsä labraolosuhteissa tai jossain pelkän RD parissa koskaan kentällä käymätön teoreetikko voi olettaa pärjäävänsä niillä aina.
Kerro vielä oi guru että miksi ajat sitä mipsi-simulaattoriasi ssh:n yli 9600 modeemilinjalla (mistä helvetistä edes löysit näin hitaan liittymän 2010-luvulla). Prosessorisimulaattoria käytetään tyypillisesti softakehityksessä ja järkevin vaihtoehto olisi ajaa sitä lokaalikoneella tai vaikka (googlen avulla löytyvillä) weppiversioilla jos sitä on pakko verkon yli ajaa.
En ole 6, mutta suuri osa kysymyksistäsi on yhdentekeviä. Yhteys saattaa olla gui:lle liian hidas ja epävakaa aika monestakin legitiimistä syystä. Vähintään tui todellakin on paljon kätevämpi jos haluaa ajaa ohjelmia etänä.
(Onnistuu locaalistikin, ja tälläkin hetkellä olen konffannut lighttpd:n pyörittämään peräti kahta www-sivustoa lo:n kautta, mutta nyt haluan nimenomaan ajaa MIPSin etänä).
Aikoinaan käytettiin joskus harjoitustyössä koulussa 90-luvun lopulla SPIM-simulaattoria ajamaan MIPS assemblyä. Oli varmasti teksipohjainen. Mutta nämä tällaiset simulaattorit vääntää melkeinpä itse helposti muutamassa viikossa valmiiksi. Varsinkin kun nyt on kyseessä yksinkertainen RISC-pohjainen käskykanta. Teet vain frontin jollakin kielellä, luet sisään sorsaa, ja implementoit käskyt itse, vaikka ihan kotikutoisella mikrokoodilla. Jokaisesta prosessorista saa aina oppaan missä lukee miten käskyt toimivat.
Sisältö jatkuu mainoksen alla
Helpomminhan tuo kysyjä olisi löytänyt softansa googlesta, varsinkin kun kysyjä ei vaivatunut kertomaan millä alustalla tuota simulaattoria ajetaan.
esim. nimellä spim löytyy softa jossa on väittämän mukaan sekä tekstikäyttöliittymä että qt-pohjainen gui. En ole testannut.
Siltikään en ymmärrä miksi sitä pitää ajaa etänä ja vielä jollain supersurkealla linjalla. Jos linjasi on niin surkea että se tiputtelee merkittäviä määriä paketteja niin hanki parempi tai tee kehitystyö lokaalikoneella. Usko pois, säästät hermojasi pidemmän päälle koska edes tekstigui:t eivät toimi todella surkeilla linjoilla. Sitten harmittaa kun monen tunnin työ menee hukkaan kun linja päättää seota just loppuvaiheessa :)
Tämä neuvo ihmiseltä jonka nuoruudessa 1200bps modeemi oli supernopea ja jonka tietoliikenne sekosi jos äiti nosti puhelimen luurin kesken "surffailun". Vanhoissa modeemeissahan ei ollut virheenkorjausta. Se tuli pikkasen myöhemmin.
Vierailija kirjoitti:
Helpomminhan tuo kysyjä olisi löytänyt softansa googlesta, varsinkin kun kysyjä ei vaivatunut kertomaan millä alustalla tuota simulaattoria ajetaan.
esim. nimellä spim löytyy softa jossa on väittämän mukaan sekä tekstikäyttöliittymä että qt-pohjainen gui. En ole testannut.
Siltikään en ymmärrä miksi sitä pitää ajaa etänä ja vielä jollain supersurkealla linjalla. Jos linjasi on niin surkea että se tiputtelee merkittäviä määriä paketteja niin hanki parempi tai tee kehitystyö lokaalikoneella. Usko pois, säästät hermojasi pidemmän päälle koska edes tekstigui:t eivät toimi todella surkeilla linjoilla. Sitten harmittaa kun monen tunnin työ menee hukkaan kun linja päättää seota just loppuvaiheessa :)
Tämä neuvo ihmiseltä jonka nuoruudessa 1200bps modeemi oli supernopea ja jonka tietoliikenne sekosi jos äiti nosti puhelimen luurin kesken "surffailun". Vanhoissa modeemeissahan ei ollut virheenkorjausta. Se tuli pikkasen myöhemmin.
1200bps-modeemit oli lähinnä sähköpostia ja jotain tekstipohjaisia käyttöliittymiä varten. Niitä ei juurikaan halunnut käyttää enää 90-luvun puolenvälin jälkeen tavanomaiseen www-selailuun.
SPIM on asennettu jo aamulla, ja opettelen parhaillaan sen käyttöä.
Sisältö jatkuu mainoksen alla
Osta Ebaysta parin euron Arduino ja leiki sillä.
On. Kysy tietokonepalstalta.