 |
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", .. |
@real_het: "En kicsit már elavultnak tartom a 32bites x86 asm tudasomat"
Nézd, én utoljára Z80 assembly-t használtam (igaz akkor főállásban és sokat).
Azóta sok C (majd később C++) kódot írtam.
Oktatási(!) szempontból fontosnak érzem az ASM --> C --> C++/C#/Java utat.
De egyáltalán nem fontos, hogy az ASM milyen architekturáról szól.
Még ma is oktathatnák a Z80-at (mert tiszta gondolatmenetű!) vagy valamelyik PIC eszköz ASM-ét.
Érdektelen. A gondolatmenet felvétele a fontos, hogy a C-re lépésnél ne lógjon a levegőben a processzor/memória architekturák ismerete és a C rendszerközelisége.
Mint ahogy [ma már] nem a tényleges, használható C tudás a végcél, úgy az ASM-et sem valós használatért kell oktatni a programozó képzésben. Az OOP felé továbblépés alapjaihoz tartozik, de valós haszna (a fejlesztők kb. 99%-ában) nincs.  |
Hello!
Ugyan egy delphis példa, de itt egy függvény, aminek a visszatérési értéke a saját kódja:
function GetThisFunctionCode: string;
const s = 'function GetThisFunctionCode: string; const s = $*$; begin Result := (ansireplacestr(ansireplacestr(s, chr(36), chr(39)), chr(42), s)); end;';
begin
Result := (ansireplacestr(ansireplacestr(s, chr(36), chr(39)), chr(42), s));
end;
A "$" jelet "'"-re cserélem, majd a "*"-ot az "s"-re.
Ennek mintájára szerintem meg lehet csinálni.
(Az ansireplacestr kódját, plusz még amire az hivatkozik, bele kellene még ebbe gyömöszölni, de nem ez a lényeg, most csak az elvet mutattam be...) |
Tegnap én is söröztem.  |
Jahj elmelkedjunk!
A spectum vagy c64 asmot en belevernem minden egyetemista informatikusba. Nekem mazlim volt, mert 8 eves koromban lett egy c64-em mindenfele kulso taroloeszkoz nelkul (kazetta se :D), szal ha pl rulettezni akartam, azt meg kellett irnom elotte, amugy meg maradt az 1 darab Jupiter Lander cartridge :d. Ha ezt a (buta) gondolkodasmodot megerti, akkor tisztaban van a Neumann elv-vel es tovabblephet a 4gl nyelvek felé.
Nekem GDF-en volt ilyen 'Mikroprocesszor mukodese' (and, or, not kapukbol egy teljes proci ossze lett rakva :D) tantargy, kar hogy a Humaneroforrasmarketing-re nagyobb hangsuly volt rakvqa lol
Szal' nem azt kell megtanitani, hogy az 53281-es porton van a c64 'videokartyajanak' a hatterszine, hanem csak a mukodesi elvet.
Es ez utan johetnek az extrana plusz orak, hogy hogyan mukodik a SIMD, ami onnantol, hogy a Viktor megteremt 1 milla munkahelyet, a jelenlegi 128bit-rol 256bit-re fog valtani (avx instruction set) :D (a vga-kban ilyen meroszam mar ertelmetlen, mert egy óccó vga is masodpercenkent 1milla*tobbszaz buta float muveletet hajt vegre, persze nem 'altalanos celuan', mint egy x86)
(ui:na most etol megorul a proghu, olyan hosszu lett lol) |
Ok, köszi, belelestem, megnézem alaposabban is!
...hát, nekem kicsit bonyodalmasabban sikerült, de jól eljátszottam vele... 
Üdv, és bocs az OFF-ért!
|
| Ezt quine-nak nevezik, >>itt talalsz par asm-es megvalositast! |
Sziasztok!
Assemblyről lévén szó - szívem csücske még mindig  , a minap egy érdekes feladvány lehetősége jutott eszembe. Net-en nem igazán találtam ezzel kapcsolatosan semmit sem - tekintsétek OFF-nak, játéknak (hiszen az assembly programozás akár játék is lehet...) 
/OFF
Szóval a kérdés a következő:
Írható-e olyan EXE, COM formátumú program (TASM, MASM, NASM...), amely:
1. Forráskódja mindössze egyetlen file (LEBUKAS.ASM);
2. Lefordítva önmagában futóképes (LEBUKAS.COM, LEBUKAS.EXE), futás közben semmilyen külső file-t nem használhat, nem nyithat meg, nem olvashat, átmeneti file-okat sem hozhat létre - azaz kizárólag memóriában dolgozik;
3. Futása eredményeként kiírja a képernyőre saját forráskódját, amelyből született.
Jó fejtörést!
/ON
|
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...
|
|
| |
| RSS források |
 | - | Hírek | | - | Cikkek | | - | Fórumok | | - | Állás/munka |
|
| Top pontgyűjtők |
| » | Micu | 1.030 | | » | Interlock | 280 | | » | mezofi | 150 | | » | Pitta_ | 100 | | » | Frostech0 | 100 | | » | szbzs.2 | 100 | | » | Hack | 100 | | » | Riha | 60 | | » | Akhiles | 50 | | » | mrchandra | 50 | | | |
|
| Top wikieditorok |
| » | Sting | | » | Doi | | » | FlamingClaw | | » | Argathron | | » | Csaboka2 | | » | Vodka | | » | Joexy | | » | Ivn | | » | Balucinho | | » | Kelemzol | | | | » ugrás a wikire |
|
|
