Mikor programoztál assemblyben utoljára?

Programozás

Nem régebben mint egy hete
3% (21 szavazat)
Nem régebben mint egy hónapja
2% (17 szavazat)
Nem régebben mint fél éve
5% (35 szavazat)
Nem régebben mint egy éve
4% (31 szavazat)
Nem régebben mint öt éve
12% (88 szavazat)
Nem régebben mint tíz éve
14% (101 szavazat)
Régebben mint 10 éve
29% (218 szavazat)
Sohasem programoztam assemblyben
31% (230 szavazat)
Összes szavazat: 741

( tetra | 2012. 08. 11., szo – 08:13 )

Utóljára egyetemen. Azelőtt aktívabban, de addigra elhalt :)
Természetesen x86 valós mód.
320x200;8 ftw.
----
India delenda est.
Hülye pelikán

( Dgzt | 2012. 08. 11., szo – 08:15 )

Középiskolában utoljára, de az inkább játszadozás volt. Tavaszi félévben az egyetemen majd újra előjön.
---------------------------
Oszt jónapot!

( kilvadi | 2012. 08. 11., szo – 08:30 )

kozepiskolaban meg az ESZR R10-en. :)

( aludanyi | 2012. 08. 11., szo – 08:39 )

Szórakozás és Code Kata... általában kéthetente hozzáérek legalább egyszer... egyébként (munka stb.) elég ritkán.

( uid_4656 v | 2012. 08. 11., szo – 09:02 )

Valami mikrokontrollert mérés laboron. És meglepte a mérésvezetőt, hogy nem MOV AX,0, hanem XOR AX,AX jellegű művelettel nulláztam :-p

Igaz, programozni sem kell tudni, hacsak nem vagy programozó, a főzés tudás is felesleges, bár kivételt képezhetnek épp a szakácsok...

Már miért is ne kellene tudni? Z80-on majdnem mindig XOR A utasítással töröltem az A regisztert, egyedül akkor használtam LD A, 0 utasítást, ha a flag-ek felülírása gondot jelentett volna. Az előbbi utasítás 1 gépi ciklus, 4 órajel, s 1 byte a memóriában, az utóbbi 2 gépi ciklus, 7 órajel, s 2 byte. Nem mindegy.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én speciel jóideje informatikusként dolgozom, és a munkám során soha nem került elő az assembly. Pedig sokféle különböző dologgal foglalkoztam...

De akkor lássuk csak mit szólsz ehhez: szerintem minden informatikusnak kellene tudnia programoznia Javaban és C#-ban is. Amikor javaban programoztam, akkor szinte mindig a List interface-t használtam a listában tárolt objektumok elérésére, kivéve egyszer, amikor közvetlenül a LinkedList-tel dolgoztam, mert azt követelte meg az implementáció. C#-ban meg LINQ-t használtam, mert az a legkényelmesebb ORM megoldás benne. Itt is volt persze kivétel, akkor, amikor még nem volt LINQ.

Nem mindegy.

:-p

Mindenhez nem érthetsz, mindent nem tudhatsz. Ahogy az assemblyhez, úgy a javahoz sem kell feltétlenül érteni. Meg semmi máshoz sem.

Arra utaltam, hogy az a hozzászólásod nem volt túl informatív, hogy nem is érdemes tudni ilyesmit. Éppen azért, mert ez bármiről elmondható. Nem érdemes érteni az autószereléshez, hacsak nem vagy épp autószerelő. Nem érdemes érteni a C#-hoz, hacsak nem vagy épp programozó. S így tovább.

Mondjuk az én életemben szinte kizárólag assembly programozás jött elő a hardware tervezésen túl, a magasabb szintű programozást más csinálta.

Igazából nem értem, mit is akartál azzal mondani, hogy nem érdemes az assembly programozáshoz érteni. A C#-hoz sem érdemes érteni pl. egy óvónőnek. Szóval tényleg nem értem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nincs (sok) köze a fix utasításhosszhoz, a Motorola 68k pl. CISC, mégis van rajta MOVEQ, amivel 8 bites értéket lehet mozgatni 32 bites regiszterbe (közte 0-t is akár). Annyiban persze köze van, hogy mivel a _minimum_ utasításhossz 16 bit (és az esetleges displacementek mérete is mindig osztható 2 byte-tal), így befér a 8 bites érték az utasításba. Szóval inkább ahhoz van köze, hogy egy processzornak utasításkészlete és architektúrája van, vagy még 64 bites módban is leginkább csak egy 8 bites ISA-ra ültetett gusztustalan patchhegyre emlékeztet... :P

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Az OpenRISC ebből a szempontból szerintem jópofa.
Ott egy regiszterbe betöltés két utasítással történik:
l.movhi - alsó byteok nullázódnak, felső byteokba tölt
l.ori - alsó byteokat vagyolja az adott konstanssal

Sok assemblyt nem láttam sajna (kb csak 8085, 8086, PIC18, PicoBlaze, kis AVR meg ez), de ez tetszett.

A legtöbb RISC rendszeren ugyanígy megy a betöltése a "nagy" konstansoknak (vagyis amit nem lehet utasításba kódolni, mert nem fér el). :)

Sőt nem csak a konstansoknak a betöltése, hanem pl. az fix címekre írás is úgy működik, hogy beolvasod a cím felső 16 bitjét, aztán az alsó 16 bittel offsetelve írsz rá pl:

lis 4,_myvar@ha
stw 3,_myvar@l(4)

Ez 32 bites PPC-n a _myvar-ba írja a az r3 regiszterben lévő értéket.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

meglepte a mérésvezetőt, hogy nem MOV AX,0, hanem XOR AX,AX jellegű művelettel nulláztam

Egy byte spórolás az is! :) Valamikor régen minden ilyen apróság létkérdés volt.
(mondjuk olyankor, amikor még egy apró szubrutint bele kellene préselni valahová, de már csak 17 byte üres hely van a tárban...egyszer konkrétan így jártam Z80-on, aztán addig "vadásztam a biteket", amíg összejött)
-
"Attempting to crack SpeedLock can damage your sanity"

Nem csak 1 byte-ot, de 1 óraciklust is spórolt így.

Spórolásról pedig. Lehet, hogy már a HUPpon is felemlegettem...
A C64-es Falcon Patrolban van egy olyan kódrész, hogy a futó kód relatív ugrással visszalép, de egy korábbi utasításhoz képes +1 byte eltolással, és onnan fut tovább, mert úgy is értelmes a kód. És korrektül el is hagyja a kódrész.

Igaz, egy memória olvasási ciklussal is rövidebb. (többszörösen ágyazott belső ciklusban mennyit számít néha)

Ez a C64 Falcon Patrol kódtrükk nem semmi. Én ZX Spectrumon emlékszem brutális dolgokra, leginkább David Jones kézzel kódolt védelmi rutinjaiból, amiket ascii nézetben értelmes szövegként is lehetett olvasni, és csak úgy röpködtek benne a non-standard Z80 utasítások, amik még a proci gyári specifikációjában sem szerepeltek, csak ilyen-olyan "alvilági" leírásokban.
-
"Attempting to crack SpeedLock can damage your sanity"

( wachag | 2012. 08. 11., szo – 09:22 )

Mostanság OpenRISC processzort rakok FPGA-ba (hobbiból, nem munka). Ott néha hasznos.

( phaul | 2012. 08. 11., szo – 09:26 )

Eloszor azt x-eltem, hogy nem regebben mint egy honapja. Aztan rajottem hogy tegnap irtam C-t amiben assemblyt rakok ossze, uh igy tegnap, csak a fajl nem .asm Egyebkent shader assemblyrol van szo

( slackmania | 2012. 08. 11., szo – 09:27 )

Még Z80-at annakidején, egy-két törés erejéig....:)

( lgb | 2012. 08. 11., szo – 09:47 )

AVR MCU, Z80 es 6502 (pl: 6510) kapcsan mostanaban is, de pl x86-ra mar eleg regen volt.

( Sparhelt | 2012. 08. 11., szo – 10:07 )

Hivatásszerűen Z80-at, még mikor a Segának fejlesztettünk játékot. A többi csak szórakozás. De szép idők is voltak. :-)

( csabezs | 2012. 08. 11., szo – 10:45 )

Nagyon régen. Volt valami dosos .com file,
ami a képernyő felbontását állítgatta, meg
volt valami demó cucc, amiből az indításkori
60 másodperces várakozást kellett likvidálni. :-)

( emberk | 2012. 08. 11., szo – 11:25 )

"Aktívan" már réges régen. Nosztalgiából néha dosbox-ban, de már nem használom. Ráadásul ezekre a mai modern cpu-kra a gcc sokkal gyorsabb asm kódot fordít, mint amit összepatkolok, az i386-os tudásommal. Szívesen beletanulnék a modern cpu-k asm-kódolásába, de nem hiszem, hogy túl produktív tudnék asm-kódolással lenni (ráadásul a numetikus matekban tudtommal a gcc is igen gyors kódot fordít, 5-10%-tempónövekedés miatt nem éri meg).

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( molgab v | 2012. 08. 11., szo – 11:59 )

int 13 mesterek int 13!

by Szarka mester

( Nyosigomboc v | 2012. 08. 11., szo – 13:11 )

Komolyabban >10 eve (eloszor ezt jeloltem).
A kommenteket olvasva rajottem, hogy en is jartam meres laborra, szoval a <10 ev lenne a reallisabb.
Aztan volt egy baratomnak egy projectje (2006-ban), ahol a 8 bites PIC-re a 32 bites aritmetikat en csinaltam. (a bekapcsolas ota eltelt millisecundumokat igy szamolja (csak relativ ido erdekel, es egyszerre max. 1-2 napig fut))
Szorakozasbol meg volt droidbattles robot, az <5 eve.

--
ezt tényleg ennyire nem értitek? - turdus :)

( Erendis42 | 2012. 08. 11., szo – 13:37 )

épp most tanulom... picit több, mint egy hete állítottam elő az első pár soromat önállóan

( NevemTeve | 2012. 08. 11., szo – 13:41 )

Éveken át BS2000-en (IBM/370 kompatibilis). Sok szép dolgot fejlesztettünk, például egy terminal-multiplexer programot, ami azután mind ment a kukába a platformváltáskor.

( nanto | 2012. 08. 11., szo – 15:09 )

vegre egy korrekt szavazas (nincs "csak az eredmeny erdekel" gomb es mindenki le van benne fedve, sot, mindenkire pontos egy radiogomb igaz)

( Rpi88 | 2012. 08. 11., szo – 15:43 )

Egyetemen 8051, 8088/86, de nem tervezek újabban :)

( xe3n | 2012. 08. 11., szo – 15:54 )

MOS 6510/MOS 8500: utoljara 1991-ben
Hitachi 6301: utoljara 1997-ben. Osszesen ket utasitasrol van szo. ;)
x86: utoljara 1998-ban

( Aadaam v | 2012. 08. 11., szo – 16:58 )

Egyetemen kotelezo volt, meg egyszer irtunk driver-t linuxhoz es akkor is kellett valamit ugyeskedni (a driver azota is az adott embedded eszkoz disztrojanak resze)

( nantal | 2012. 08. 11., szo – 17:11 )

Szakközépben PIC mikrokontroller programozáshoz kellett az Assembly (Igaz Microchipes MPASM).

( Sea-you | 2012. 08. 11., szo – 20:18 )

Utoljara keygent irtam, nem ma volt :)

( hrgy84 | 2012. 08. 11., szo – 23:41 )

Kevesebb, mint tiz eve, de hat az is reg volt... Z80 volt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( locsemege v | 2012. 08. 12., v – 02:27 )

Régen nagyon sok Z80, aztán volt 80C32, illetve Dallas DS80C320, aztán sok Microchip PIC család. Meg persze valamennyi 8086 is, de azt elfelejtettem már, s nem is szerettem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( xzsolt | 2012. 08. 12., v – 10:20 )

Én még 6502-vel kezdtem, ha ez mond még valakinek valamit.
Volt még egy kis Z80-is. Azután Intel 8085-től kezdődően.
Alapvetően munkához nem kellett, csak magam kedvére.
Viszont jelenleg van egy számítás igényes feladat (mellékállású munka), amihez a cél CPU (minimum) i7, természetesen 64-bites.

( valacska | 2012. 08. 12., v – 10:25 )

c64 demók - mos6510, majd amiga 500 scene - motorola 68000, majd 80x86 sok-sok évig, kevés pic és avr, manapság arm és infineon időnként.

( gaby | 2012. 08. 12., v – 11:48 )

C64, MCS51, Z80, 8085
A C64-hez meg EPROM égetőm is :-)

( borosspet | 2012. 08. 12., v – 15:20 )

C=16 / C=plus4 alatt, lassan már 20 éve, hobbiból... X86-ra már nem tanultam meg... :-(

( gabor2 | 2012. 08. 12., v – 23:15 )

Meg nagyon regen a McDonalds-oknak csinaltunk egy energetikai merorendszert. Volt valami hibajelzes, hogy ha a sutoben az olaj homerseklete X fok fele megy (nem emlekszem pontosan) akkor szirenazo hanggal kellett jelezni a hibat. Ket valtakozo hangot generaltam assemblyben de ravasz modon mig az elso talan az abszolut A hang volt (660Hz vagy egy oktavval feljebb) a masodik hangot nem a kromatikus skalabol valasztottam hanem valemelyik ket hang koze. Fajdalmasam hamisan hangzott de hatasos volt. :)

( hoild | 2012. 08. 13., h – 03:20 )

Csupán pár napja, és ma is fogok, ha a macroassemblerben való programozás annak számít. Ámde nagyon elvetemült macroasm programozásról van szó, mely felületesen nézve magasszintű scriptnyelvnek tűnhet:
http://newcomer.hu/ENCscript-xmpl.html

( neuromanta | 2012. 08. 13., h – 13:32 )

Pont tegnap, C64-et... az számít? :D

( walaki | 2012. 08. 14., k – 12:23 )

Középiskolában, jobban mondva 5. évfolyamon, sőt, vizsgáznom is kellett belőle. Szerettem, néha hiányzik.
--
www.haiku-os.org