Assembly :: röviden
 Sziasztok!
Szigorúan monoton közeledő 1. assembly vizsgára készülök. A vizsgára kiírtak pár feladatot - mint beugrót - egyet kell belőlük megoldani in assembly és prezentálni. Az alap-probléma minden esetben triviálisnak mondható, gondom a nyelvvel van. A netről letöltött példakódokat a tanár által ajánlott NASMIDE környezet nem fogadja be, pedig ez lenne hatékony tanulási lehetőség - első éves levelezős hallgatóként. Gyakorlaton zászlót, sakktáblát, egyenest "rajzoltunk", .. |
A PC-s assemblynek is megvan a maga helye, bár az igaz hogy a Delphi sem rossz - kb. ugyanazt tudja teljesítményben mint a C++ - azaz nagyon össze kell szednie magát annak aki nagyobb kód esetén jobbat ír.
Viszont az igaz, hogy a desktop rendszerek általában valóban nem realtime rendszerek. És nem azért mert bénák, hanem azért mert arra amire kitalálták őket jobb ha a realtime-nál picit összetettebb ütemezőt használnak, ahol az egyes feladatoknak eltérő prioritásuk van, ahol az egyes folyamatok kezelik a holtpontokat és hasonló érdekességek.
Pl. itt egy kis bevezető a témáról.  |
Hálásan köszönöm a segítséget, elmúlt dolgokon már nem segít, de a jövőben rajta leszek. Köszi még egyszer! Boldog Karácsonyt !
Sz B |
| Linux (megfeleloen konfiguralt kernellel, ilyet hasznal pl. az Ubuntu Studio is AFAIK a preciz idozitesek miatt), vagy a deklaraltan realtime QNX |
"A hering is gyenge favágásban, avagy ha a kacsa nem tud úszni, nem a víz a hülye."
Nem használtam assemblyt PC-n. Felesleges küzdelem lett volna. A célhardverben egyetértek, én is ezt az utat választottam, viszont volt egy olyan része a feladatnak, ami pufferelt adatfolyammal nem volt megoldható, tehát kellettek a pontos időzítések a PC felől is. Másrészt igény volt egy Autocad-es fájl feldolgozására, amit mindenképp PC-n akartam megoldani DOS alatt előzetes átalakítás után, másként előállt volna amit az utolsó mondatodban írtál.
Lényeg az, hogy volt egy célhardver egy DOS-os PC-hez kötve, és a terveim szerint lett volna egy Delphiben megírt program, ami az autocad fájlt átalakította és átküdte volna a DOS-os gépnek, ami elvégezte volna a munkát. Ez bukott meg valaki miatt, aki lazán bevállalta, hogy mindent megold Delphiben célhardverek nélkül. Nem iazán vigasztal, hogy nem jött neki össze. Mindenesetre én a mai napig nem tudok más megoldást a kényelmes ablakos rendszer és egy pontos időzítéseket megkövetelő masina összekapcsolására, mint alkalmazni egy köztes gépet, esetleg egy real-time vezérlésekre alkalmas windows-t(??), ha tényleg megy. Ha van más ötleted és nem kell hozzá nagyon sok pénz, köszönettel várom. |
Azért gondolom, hogy káosz lesz hamarosan, mert ahogy fejlődnek a programok, egyre könnyebb lesz egy bizonyos fokig látványos eredményt elérni. Ez a dilettánsoknál olaj lesz a tűzre és mindenki alkalmazást/játékot akar fejleszteni.
Ez már egy ideje érződik. Nincs ezzel különösebb gond. Majd alkalmazkodik ehhez is a társadalom. Annak idején csak egy "elitebb" réteg használta az internetet. Ma már az is, aki írni és olvasni se tud. Jól van ez így. Nagyobb a piac. |
Egy szerkezetet kellett volna vezérelni olyan időzítéssel, hogy másodpercenként kb 10000 üzenetblokk menjen el nyugtázással. Egy fickó beállított hozzá egy Delphi alatt összedobott programkezdeménnyel, rögtön el is fogadta. A kidolgozás során jöttek rá, hogy a windowsos rendszer nem képes működni. Visszajött, megkérdezte, hogy miért. Javasoltam neki a windows és DOS rendszereken megírt programrészlet időzítéseinek összehasonlítását.
A hering is gyenge favágásban, avagy ha a kacsa nem tud úszni, nem a víz a hülye.
Egész véletlenül mikrovezérlők programozásával is foglalkozom. Kritikus műveleteknél célhardvert és hardveres megszakításokat illik használni. Ha Windows és Delphi helyett DOS - Assembly párost használsz ilyesmire az ugyanúgy mókás. Sok működő MSDOS-QBasic-RS232-RS485-PIC alapú vezérlést láttam amik évek óta kifogástalanul működnek de kivétel nélkül a lényeg mikrovezérlő szinten volt megvalósítva.
Az általad lesajnált magas szintű rendszerek hatékonyan használhatók arra amire valók. Mindent a maga szintjének és céljának megfelelően kell alkalmazni és nincs gond.
Ha mindent assemblyben akarsz megvalósítani akkor elvérzel. Még a tervezési fázison sem jutsz túl amikor más már leszállítja a terméket. |
"valaki mutasson irányt nekem"
senki nem elég? Mindenképp valaki kell? 
Nézd meg az oldalam: Hunasm
-Ami ide le van írva az pont az ami neked kell, kicsit más a syntax ha még mindíg nasmot akarsz használni, de szinte annyi a külömbség csak, hogy:
byte ptr [...] BYTE[...]
word ptr [...] HELYETT: WORD[...] KELL
dword ptr[...] DWORD[...]
Aztán még annyi hogy bss szekcióban nem db,dw,dd hanem resb,resw,resd van és mások a szegmensdefiniáló kulcsszavak.
Ez soknak hangzik de olyan kevés eltérés hogy ha életedben láttál futó példaprogramot akkor is át tudod írni egyikről a másikra egy kis gondolkozással, mellesleg tudom mik a beadandóitok ugyanus többen is kapcsolatba léptetek velem(szvsz. ez MEGALOL) és állíthatom, hogy az oldalon leírtakból bármelyiket össze lehet tenni, minden tudást meg lehet szerezni.
-Neked külön figyelmedbe ajánlom a Snaker 2.0 nevű fejezetet pl. ami technológiailag mindent tartalmaz ami kellhet neked egy kukacos játékhoz, azt hogy a maradékot megcsináld az kb. olyan mint legókockákból összerakni az űrhajót kb.
ui.: Remélem segítőkész voltam, én általában mindenkinek segítek abban és úgy, ahogy kéri. Te és egy másik sorstársad útmutatást kért, az van. Még egy ember volt aki programot is kért(az is volt). Általában ha az emberek azzal keresnek meg, hogy segítsek hogy elinduljanak akkor annak örülök jobban, de persze ez függ attól is hogy mennyire látom az adott embert normális hozzáállásúnak és egyéb háttérinfóktól is függ stb.
Prenex |
Igazából ha iskolai feladat akkor 99.9%-os eséllyel oda mezei DOS-os progit várnak. Ehhez kerítened kell egy DOS-os fejlesztői környezetet. Anno én a Turbo Assemblert használtam, de jó a microsoftos MASM is. Vagy ez:
esetleg ez.
Kell még egy notepad.exe, esetleg egy debugger (a turbo debugger valahol a borland környékén ingyen letölthető, vagy legalábbis valaha az volt).
A régi "szép" időkből már nem sok mindenre emlékszem, de arra igen hogy a legegyszerűbb úgy lesz az életed ha 320x200 8 bit színmélységre kapcsolsz (MCGA üzemmód) így az egész video memóriát egy 64K-s szegmensben kényelmesen tudod kezelni.
Valahogy palettát is lehet állítgatni de arra már nem emlékszem hogyan. Ha ennél több kell akkora VESA környékén nézz szét.
De iskolába szerintem bőven elég az MCGA. Régen sok játék is ment ezzel a felbontással.
A billentyűzetet szintén a BIOS megfelelő funkcióinak hívogatásával tudod megoldani. Int 10H ha jól emlékszem - utoljára vagy 15 éve csináltam ilyesmit. |
Mi folyik itt? Alig teszem ki a lábam máris megy a provokáció?
Zöldfülűként - nem vagyok fiatal - azt gondolom, minden szakma esetén van egy bizonyos alapműveltségi szint, amelyet illik hozni annak, aki be szeretne lépni a körbe.
A lényeg a folyamat, amelynek szeretnék trottyos zöldfülűként is részese lenni.
Sok földi időm nincs a NET-et,a könyvespolcokat böngészni. Azért jöttem ide, mert itt magas a tudás koncentráció, így nagyobb az esélye a megoldásnak, mint pl. a LEHEL piacon.
Úgyhogy valaki mutasson irányt nekem - ha tud és akar - mert jön a vizsga és kirúgják a trottyos zöldfülű s.gg.m.t...
Tehát nem kód kellene ... copi / paszte, hanem irányvektor, de eddig csak ideológiát kaptam, de azért csak így tovább, mert nagyon ez is jó! |
A windowst nagyon sok minden ki tudja nyírni. Egyebek közt egy rosszul megírt driver. Azon persze el lehet vitatkozni hogy mennyire jó hogy egyes drivereket ennyire mélyen beengednek a kernel magjába, viszont a sebesség érdekében meg kellett tenni.
A másik ami meg tud ölni egy windowst az egy vírus. A harmadik ami meg tudja ölni, az mindenféle beépülő program. A negyedik pedig a vírus.
De egy normálisan feltelepített windows normális driverekkel és biztonsági beállításokkal és normális vason igen stabil jószág tud lenni. Nekem évek óta nem volt olyan problémám hogy fagyott volna a windows vagy bármi olyat tett volna amit nem szabad neki. Na most, ha egy program bugos az mindenhol bugos, így nálam is.
Persze úgy könnyebb megbízható rendszert csinálni ha standard hardver van alatta és olyan telepíti fel az oprendszert aki ért hozzá és nem a szomszéd Pistike. De ez a PC platform sajátossága hogy millió hardver van amit kezelni kell, és a júzerek telepítik az oprendszert akik néha olyanokat sem tudnak hogy mi az a winchester. |
És ez így volt az eddig megjelent összes windowsnál is igaz ? Mindegyik olyan jól tesztelt összetevőkből állt, amelyek teljesítették a specifikációkat. Hogyan is tehettek volna szert másként világhírre ?
Az igazság szerintem az, hogy "lényegtelen" alkalmazásokra, ahol nincs semmiféle különleges követelmény, ez jól használható, mert Pl. nemigen dőlnek össze épületek attól, ha egy oldalt valaki nem tud kinyomtatni. Lényegtelen. Attól, hogy nagyon sokan használnak valamit, az még nem lesz megbízható, és erre az állításomra bizonyíték sok millió ember rengeteg elvesztegetett ideje, amit a windows-ok életben tartására fordítottak eddig. Tényleg, ez az idő a specifikációk szerint összesítve mennyi lenne ? |
| De igen. Ezek a rendszerek nagyon szépen mennek - mivel a nagy rendszerek alapvetően kis rendszerekből állanak össze. A kis rendszereket pedig szépen le lehet tesztelni egyenként, illetve ezek kapcsolatát is. A dolog nyitja az hogy minden alkotóelem egy-egy adott dologért felelős, és egy-egy megadott specifikációt kell hogy teljesítsen. |
| Én ezekkel a dolgokkal nem is vitatkoztam. Ugyanakkor állítom, hogy a méret és a bonyolultság növekedésével nő az átláthatatlanság, a hibák előfordulási valószínűsége... Amit legfontosabbnak tartok, az az ellenőrizhetőség. Erre ezeknél a nagyon nagy rendszereknél esély sincs. Tökéletes alkatrészekkel is ugyanez lenne a helyzet. Egyébként mindenütt vannak hardveres hibajavító eljárások. A nagy rendszerek hátrányait akartam kiemelni. Rendszerek rendszerének rendszerének...rendszerét nem lehet hibamentesen, vagy kiszámítható mértékű hibával kezelni. |
A fene se sajnálja le a mikrovezérlőket. Megvannak nekik a jól meghatározott feladataik. Ahogy minden másnak is. A windows vagy a linux Pl. nem arra való hogy realtime dolgokat oldj meg vele, ahogy azt KisJ kolléga is kifejtette. Ahogy a DOS sem arra hogy több felhasználót kezelj vele, hogy több programod fusson, stb. Ha DOS alatt lehalt a rendszered akkor vele halt az egész. Ha közben az írási cache be volt kapcsolva akkor jó eséllyel került bele egy kalap szemét az adatbázisodba. Jó pár olyanom volt anno hogy a Clipper vagy a Paradox DBF közepén jókora kalap szemét volt benne. Windows alatt ha külön adatbázisszerver fut akkor max. a programod rohad le, de az adatbázisszerver fut tovább és az adataid épségben maradnak. És fél kézzel kezel le olyan adatmennyiséget amivel a DOS-os Clipperes rendszer anno órák alatt sem végzett.
Erre programot írni puszta szerencse kérdése. Egyetlen sor egyszerű kiíására sem lehet azt mondani, hogy biztosan végre fog hajtódni következő alkalommal is, miután már megcsinálta ezerszer. Alkatrész szinten programozva mindezekkel lehet számolni.
Egy nagy lófüttyöt lehet. A hibák 99.9%-át a mai windowsokon és linuxokon pont a ratyi kínai hardver okozza.
Vannak megbízható és összetett rendszerek, Pl. az IBM mainframe-ek. Ha felrobbantod a felét akkor a másik fele ír egy log bejegyszést hogy gond van az egyik felével és emiatt kicsit lassabb lesz feldolgozás. De nem is annyiba kerül... |
| Nem én írtam butaságot, hanem tőlem várták egy alapvetően buta elvárás teljesítését, és volt egy Delphiben programozó ember, aki annyira profinak tartotta magát, hogy vállalta a feladatot a legalapvetőbb hardveres ismeretek nélkül. Egyébként így is van rá mód az adatok pufferelésével, de ez a megoldás nagyon sérülékeny. Alkatrész szinten programozáson az alkatrészek és a működésük ismeretét, ill. azt értem, hogy a belőlük fölépített rendszert assemblyben vagy gépikódban programozom. |
Alkatrész szinten programozva mindezekkel lehet számolni.
Mit értesz alkatrész szinten programozás alatt???
|
Szerintem ennyi betüt senki nem fog elolvasni.
Főleg, hogy már az elején butaságot írsz.
Tudni kellene mi mire való.
A DOS realtime a windows NEM.
|
Tök jók ezek a pilótavizsgás fejlesztő eszközök. Egy ismerősömnek akartam készíteni egy progit DOS alatt és mereven elzárkózott előle, mert ablakocskákkal teli, titkárnőknek való csilivili felületet akart. Egy szerkezetet kellett volna vezérelni olyan időzítéssel, hogy másodpercenként kb 10000 üzenetblokk menjen el nyugtázással. Egy fickó beállított hozzá egy Delphi alatt összedobott programkezdeménnyel, rögtön el is fogadta. A kidolgozás során jöttek rá, hogy a windowsos rendszer nem képes működni. Visszajött, megkérdezte, hogy miért. Javasoltam neki a windows és DOS rendszereken megírt programrészlet időzítéseinek összehasonlítását. Kiderült, hogy a windows 7000-szer -HÉTEZERSZER- akkora hibát csinált, mint a DOS.
Szóval akkor most azt kérdezném, hogy ha egy rendszerről eleve tudott dolog, hogy gagyi, akkor a fejlesztőrendszerek miért engednek meg pl. olyan időzítéseket, amit garantáltan nem tudnak teljesíteni ? A válasz annyira egyértelmű, hogy kimondani sem merem. Lehet, hogy túlságosan sarkított a véleményem, de szerintem ma pontosan ugyanazt csinálják a számítógépekkel, mint 25 éve: szöveget szerkesztenek, táblázatokat kezelnek, játszanak... Persze egyre szebb környezetben. A legegyszerűbb hardverek vezérlése viszont csaknem lehetetlenné vált közben. Megalkották az USB szabványokat, ami tök jó, egészen addig, amíg időzített feladatokat nem akarsz csináltatni. Mert ott már az sem jó, ráadásul a sebességekkel való verseny is csak addig jelent valamit, amíg nagy adatblokkokat visznek át. Abban a pillanatban, amikor rövid, de pontos időzítésű üzenetváltásokra van szükség, ezek a rendszerek mind megbuknak, mert óriási mennyiségű "felesleges" információt visznek át, ami a feladat szempontjából mindössze eldobandó teher, és egy néhány kb/sec sebességű "saját fajta" adatátvitel a másodpercenként átvitt hasznos adatok tekintetében simán lekörözheti a csilivili rendszereket.
Van még egy nagy előnye a lesajnált mikrovezérlőknek és kis gépeknek: Rájuk bízhatod akár az életedet is. Pl olyan helyeken, mint a repülés vagy az űrkutatás, ahol fokozottan számolni kell hardveres hibákkal is a beérkező sugárzás romboló hatása miatt, soha nem alkalmaznék olyan gépeket, amelyekben bármikor előre megjósolhatatlan hibák léphetnek fel. Ilyen pl. az összes windows alá írt program már csak tisztán az oprendszer átláthatatlansága miatt is. Erre programot írni puszta szerencse kérdése. Egyetlen sor egyszerű kiíására sem lehet azt mondani, hogy biztosan végre fog hajtódni következő alkalommal is, miután már megcsinálta ezerszer. Alkatrész szinten programozva mindezekkel lehet számolni.
Tennék még egy észrevételt a magas szintű rendszerekkel kapcsolatban. Nézzük meg az internetes kommunikáció egymásra épülő szintjeit ! Ott az derül ki, hogy gyakorlatilag nincs gyártó, aki az OSI szabványoknak megfelelően tervezné a kártyáit vagy a programjait. Valakik a fejükbe vették, hogy héjszerkezetet alkotnak, mert hogy az majd egységesíti a hálózati kapcsolatok rendszerét. Valójában egy hardverszinten kitűnően megérthető rendszerhez alkottak olyan leírást, amihez senki nem igazodik, amit senki nem használ, az csak van. Valakik biztosan doktoráltak ostobaságból. Egyszerűen nem tettek mást, a használhatatlanságig bonyolítottak egy már amúgy is elég bonyolult rendszert. Ugyanezt érzem a mai "magas szintű" fejlesztő rendszerekkel kapcsolatban is. Olyan, mintha füvet akarnék nyírni a kertemben egy kombájnnal. Vagy inkább egy egész kombájnos brigáddal. Ezek a rendszerek tetszőlegesen bonyolíthatóak, a tervezőknek meg senki nem mondja meg, hogy a fene se kíváncsi egy még újabb, még univerzálisabb, még érthetetlenebb, nagyonnagyonnagyon teljes tudású rendszerre akkor, amikor csak egy vonalat akarnék kirajzoltatni. |
Nem érted amit mondani akarok.
Az én programom nem azét lesz jobb, kisebb, stb. mert én okosabb vagyok mint te, hanem azért mert a magasabb szint miatt egyrészt nem kell mindent lefejlesztenem hanem építőkockákból dolgozhatom, másrészt a fordítóprogram megcsinál nekem egy rakás dolgot amit neked nem.
Pl. ha van egy
class akarmi
{
int id;
string nev;
}
struktúrából teszem azt 1000 darab a memóriában
és le akarom név szerint rendezni azokat akiknek az ID-je kisebb mint 1000 akkor ezt C# alatt ennyiből tudom megcsinálni:
var lst=new List<akarmi>();
...
var q = from c in lst
where c.id<1000
orderby c.nev
select c;
foreach(var rw in q)
{
// És itt már azt csinálok az elemekkel amit akarok.
}
Ugyanezt ha meg akarod csinálni assemblyben az úgy kezdődik
hogy írj egy konténert... Aztán írj rá egy rendező algoritmust...
Persze ebből sok minden már készen lehet, de közel sem ennyi minden. |
serébe viszont az én kódom elfut minden .NET-et támogató platformon,
Ez is egy érdekes dolog.
Pár éve minden lepkefing alkalmazás futtatásához Javaruntájm kellett.
Ment a szívás, hogy melyik runtájm verzióval működik jól az alkalmazás.
Aztán ezen programok újabb verziói újra natív kóddal működnek.
De már a következő verzió .net frémvörköt követel.
Persze jó eséllyel ezek is verzió függök lesznek.
Nem azt mondom, hogy a javaruntájm vagy a dotnetfrémwörkkel van a baj, de aki alapdolgokat nem tud, lekódolni az ne akarjon szoftvert fejleszteni.
Aki nem tud programozni azon nincs az a runtájm vagy frémvörk ami segiteni tud.
|
Már évek óta próbálom megértetni veled, hogy pusztán a fejlesztési nyelv alapján nem lehet különbséget tenni programok közt.
Egy program nem lesz jó vagy rossz a nyelvtől.
Ne gondol azt, hogy bárki írhat jó programot.
Egy példa.
Képzelj el, például egy raktárkészlet kezelő programot, ami akár jó is lehetne.
De elmegy tőle az ember kedve, mert a felbukkanó messagebox-ok, ablakokat valamilyen oknál fogva tök idióta pozícióba dobálja. A fejlesztő válasza: A fejlesztőeszköz miatt van.
Ez most jó program vagy rossz program?
A fejlesztőeszköz a hibás?
Ha én assemblyben írok programot az nem feltétlen, jelenti azt, hogy gyors lesz.
Mint ahogyan a te C# programod sem lesz feltétlen jó.
A megelőző hozzászólásomhoz:
Azért gondolom, hogy káosz lesz hamarosan, mert ahogy fejlődnek a programok, egyre könnyebb lesz egy bizonyos fokig látványos eredményt elérni. Ez a dilettánsoknál olaj lesz a tűzre és mindenki alkalmazást/játékot akar fejleszteni.
|
A kód alatt forráskódot értek. És bizony hogy nagyobb lesz.
Az más kérdés hogy te megcsináltad a kis házi makrógyűjteményedet amivel lényegében majdnem C szintre hoztad fel a dolgot. De mondjuk egy alfa-béta algoritmusos amőbát te is nagyobb forráskóddal (sorok száma), több idő alatt és több hibalehetőséggel csinálnál meg assemblyben mint én C#-ban. Ettől persze a te futtatható binárisod valószínűleg picit kisebb és jóval gyorsabb lenne mint az enyém. Cserébe viszont az én kódom elfut minden .NET-et támogató platformon, akár a WinCE ARM platfomján, akár a mono segítségével egy rakás más architektúrán, addig a te progid x86-on kívül gyakorlatilag használhatatlan. Nem véletlenül nem ír ma már senki oprendszert assemblyben, pedig anno a C előtt mindenki abban írta. |
Ettől függetlenül bármit meg lehet írni assemblyben is. Csak tovább tart, sokkal nagyobb lesz a kód, és sokkal nagyobb lesz a hibalehetőség. Cserébe viszont az adott processzoron nagyon gyors lesz.
Ez a kijelntes azert erdekes mert semmi sem tenyszeru belole...
|
Azért ma már nagyon-nagyon ritkán van baj a magas szintű programnyelv fordítójával, legalábbis a nagyobb rendszerek (gcc, visual C++, visual C#, PHP, stb) esetén. Mondjuk a Free Pascal béta verziójában akadhatnak problémák. De nagyobb rendszerek esetén nem annyira jellemző. Gáz is lenne Pl. linux vagy windows esetén ha bugos lenne a C fordító )
A rendszerednek meg nem a hatékonyságával hanem a megbízhatóságával lesznek gondok. Bizonyos bonyolultság felett kellenek a lokális változók, kellenek a paraméterek a függvényeknek, kell a típusellenőrzés, még nagyobb bonyolultságnál már kell az oop, jól jönnek a property-k, lambda kifejezések, linq.
Ettől függetlenül bármit meg lehet írni assemblyben is. Csak tovább tart, sokkal nagyobb lesz a kód, és sokkal nagyobb lesz a hibalehetőség. Cserébe viszont az adott processzoron nagyon gyors lesz.
Amúgy leszámítva a csillivillit, meg a kényelmet én annak idején mindent meg tudtam tenni a DOSos kis 286-omon, mint az XP vel.
Egy fenét tudtál. A kis 286-osodon 64K-s szegmensek voltak ahol egy 1MB-os képfájl kezelése is vaskos szopások árán volt lehetséges. Illetve elvben talán át lehetett vele menni védett módba de valami gáz volt vele, i386 előtt nem nagyon használt senki ilyesmit. Nem tudtál a háttérben lejátszani egy mp3-mas fájlt és az akkori winchestereknek nem volt akkora a kapacitása mint az átlag júzerem által használt adatok mennyisége - zip-pel betömörítve. És még sorolhatnám azokat a dolgokat amikről az akkori DOS-os PC-n csak álmodhattál volna.
Létezett ugyan elvben TCP/IP stack, kérdés mi fért volna még el mellette. A nyomtatóknak nem voltak driverei, mentek a jó kis escape szekvenciák, nyomtatónként mások. Két nyomtatón igen nehéz volt egyforma nyomtatási képet összehozni még karakteresen is. Nem nagyon voltak scannerek, a hangkártya kezelés is folyamatos szívások forrása volt, és még sorolhatnám. |
Na ezt most nem értem!?
Szerintem egy jól megírt rendszer hatékonysága attól függ, hogy mekkora az azt megíró programozó(k) képessége, de ha gáz van a magasabb szintű programnyelv fordítójával, akkor tutira gáz van, még akkor is ha van típuskezelésed! 
Az, hogy a júzer mit vár el, annak mi köze van ahoz, hogy mit tehet meg az ember egy windowsal, vagy mit tehet meg egy 20 éves unixal. Amúgy leszámítva a csillivillit, meg a kényelmet én annak idején mindent meg tudtam tenni a DOSos kis 286-omon, mint az XP vel. Egyébként tényleg: (csak hipotetikusan) Mivel lenne kevesebb ma az informatika mint 20 éve, ha csak a hardver fejlődik, az oprencerek, meg fejlesztőkörnyezetek nemnagyon?
(bár ez lehetne uj topik :) )
|
| Ne hidd. Általában minél magasabb szintű programmal fejlesztesz egy adott bonyolultságú dolgot adott erőforrás felhasználásával, annál stabilabb a rendszered - kivéve ha nincs típuskezelésed. Nem véletlenül használnak a bankok javát és nem assemblyt vagy PHP-t. Az már másik kérdés hogy egyre komplexebb dolgok vannak. A júzer ma már elvárja a multitaskingot, a csilli-villi user interfészt, a többszálúságot, a kommunikációt más rendszerekkel, stb. Az amit ma megtehetsz egy windows-zal azt 20 éve még egy unixos munkaállomással sem tudtad megtenni. |
és ki tudja mi lesz felette.
Összeomlás, tutális káosz, sz4r programok... |
| Igen, a Z80-nal kapcsolatban kb. erre gondoltam. És egy átlag programozónak kb. eddig is kell belemenni - ha nem kimondottan ez a szakmája. Olyan emberből aki ismeri az assemblyt egyre kevesebb kell - szvsz hosszú távon pár ezer szerte a világon. Legalábbis olyan szinten ahol már cache hierarchia és hasonlók játszanak. A Z80 kategóriás 100 forintos mikrovezérlők más téma, de a nagy asztali rendszerek szvsz egyre kevésbé érdekesek ilyen szempontból. A dolgok ugyanis nagyon sokfélék és nagyon gyorsan változnak. Az i386 amikor én assemblyt tanultam vadiúj technológia volt. Azóta viszont már a procik modelljeinek sorszámozását is nehéz nyomon követni, nemhogy az utasításkészletüket. És a programodnak mindegyiken futnia kell - és ha holnap kijön teszem azt egy vadiúj proci akkor jó ha azon is. Nem véletlenül szorította ki az assembly alapú oprendszereket a C alapú unix, windows. Ma meg már lassan a C is túl alacsony szintű, a C++ az assembly és a C# / Java a magas szint. De szvsz 10 év múlva már a C# lesz az alacsony szint és ki tudja mi lesz felette. |
Röviden összefoglalva: döntsük el, hogy pedagógiai céllal tanítunk kezdőknek, vagy konkrét napi használatra való dolgot tanítunk. Pedagógiai szempontból egy néhány napos max. hetes Z80 kurzus csodákat tehet. Ha meg napi szinten hasznos tudást akarunk tanítani, arra kellhet 1-2 év is, és akkor bele kell menni a mai többmagos processzorok, buszrendszerek, memóriavezérlők, pipelineok, cache hierarchiák kutya bonyolult világába.
Az x86 és a DOS-os megszakítások tanítása valahol a kettő között árválkodik, egyik célra sem az a kifejezett tökéletes választás. |
Én érteni vélem, hogy mire gondolt LC, szerintem nincs ellentmondás, és nagyjából egyetértek vele.
Szvsz. arra gondolt, hogy közvetlenül az x86 programozás egyes részleteire nem feltétlenül lesz közvetlen szüksége egy átlag programozónak. Az x86-nál vannak jóval egyszerűbb processzorok, és pl. az x86 szegmenskezelése sem valami általános fundamentális tudás. Ráadásul a különféle assemblerek szintaktikája is esetleges, és azt is meg kell tanulni.
Viszont, hogy hogyan működik a számítógép, arra nagyon is szüksége lehet egy általgprogramozónak is. Ezt a leggyorsabban, legélvezetesebben és leghatékonyabban egy egyszerű proci tanításával lehet elérni; a Z80 ilyen. Ráadásul ha ASM helyett közvetlenül a gépi kódot tanítjuk, akkor azzal sem zavarjuk össze a kezdőt, hogy mit csinál az assembler, így fogja fel egy kezdő a legegyszerűbben, hogy hogyan működik a számítógép. Ráadásul egy egyszerű proci esetében még lejjebb lehet menni, meg lehet mutatni egyes részhardvereket egész részletesen, ezáltal a megértést tovább segítve.
(Persze a sima 8086 nagyon egyszerű egy mai procihoz képest, de még mindig sokkal bonyolultabb, mint egy Z80.)
A másik oldalról viszont szerintem az alapműveltség része azért egy kicsit ismerni a modern architektúrákat is legalább nagyon nagy vonalakban (cache hierarchiák, pipeline-ok, műveletek időköltsége stb: ezeknek már a nagyon nagyjábóli ismerete is sokat segít, ha néha nagyon hatékony kódot kell írni.) |
|
