Szóval az örök kedvenc:
section .text
global _start
_start:
mov ecx, hello_world
mov edx, [ecx] ; read-count
; write
mov eax, 4 ; read
mov ebx, 1 ; stdout
add ecx, 4
int 0x80
; exit
mov eax, 1
mov ebx, 0
int 0x80
section .data
hello_world:
dd 13
db "Hello World!", 0x0a
(fordítása: nasm -o hw.o -f elf hw.asm; ld hw.o -o hw)
Egy komplett (?) kernelhívás-referenciát találtam, ami alapján el lehet indulni. Remélem, hasznos lesz. :)
További erőforrások (nem tudom, hogy a resource-t hogyan kell fordítani):
http://asm.sourceforge.net/ - Egy pár tutorial assemblyhez.
http://docs.cs.up.ac.za/programming/asm/derick_tut/ - Másik induló-doksi.
És most jöjjön a lényeg: miért is assembly? Nem portolható, rémálom a programozása, és még ezeregy ok van ellene, emellett pedig csak néha van megfogható előnye sebességben (számok darálása, etc.). Elvileg van egy hely, ahonnan nem irtható ki: compilerek írásánál.
A gcc pl. as86 assembly kódot generál, ami nekem kész rémálom volt, mivel a NASM-ot szoktam meg, még gimiben, ahol DOS alól assemblyztem (Windows 9x/NT miatt leszoktam róla).
Viszont a Linux relatíve jól dokumentált, így nem volt nehéz megtalálni a szükséges dolgokat (aki ismeri az assemblyt, az tudja, miket kell keresni, a többieknek meg nem nagyon tudom elmagyarázni (összefüggéstelen lennék (imádom az egymásba ágyazott zárójeleket (tényleg :) ))))
Már régen eldöntöttem, hogy szeretnék írni egy fordítót, ami max. assemblyt elő tud állítani. Jelenleg egy brainfuck fordítóra gyűjtöm a bátorságomat. Ehhez viszont illene megtanulni az ELF formátumot, amiről szerencsémre ugyanúgy van dokumentáció. Ha összejön, természetesen értesítem a nagyérdeműt. :)
Addig is: let's assemble.
- vik1984 blogja
- A hozzászóláshoz be kell jelentkezni
- 1247 megtekintés
Hozzászólások
Introk / demók írására sem rossz ;)
- A hozzászóláshoz be kell jelentkezni
Feltéve, ha az ember ért hozzá. Láttam egy Yellow Rose nevű Linuxos demót, az érdekelne, hogy honnan tölthető le. Sajna elveszett az én másolatom.
"No boom today. Boom tomorrow. There's always a boom tomorrow. What? Look, somebody's got to have some damn perspective around here. Boom, sooner or later. BOOM!" -- Lt. Cmd. Ivanova
- A hozzászóláshoz be kell jelentkezni
Nem ismerem, de egyszer le akartam mirrorozni a teljes ftp.scene.org -ot. 198x-tól megvan minden nagyobb scene party teljes anyaga, a versenyművek és a közben készült videók, interjúk, minden. Aztán rájöttem hogy manapság 4-5 giga anyag készül egy partyról, az meg sok :)
- A hozzászóláshoz be kell jelentkezni
Talan ez az: http://pouet.net/prod.php?which=10562
- A hozzászóláshoz be kell jelentkezni
Koszi, ez az.
"No boom today. Boom tomorrow. There's always a boom tomorrow. What? Look, somebody's got to have some damn perspective around here. Boom, sooner or later. BOOM!" -- Lt. Cmd. Ivanova
- A hozzászóláshoz be kell jelentkezni
Ehhez viszont illene megtanulni az ELF formátumot, amiről szerencsémre ugyanúgy van dokumentáció. Ha összejön, természetesen értesítem a nagyérdeműt. :)
Minek? A legtobb high level fordito ugy dolgozik, hogy assembly-t general, aztan GAS/LD a baratod. Vagy az aktualis platformon elerheto mas assembly fordito/linker. Ugyis kell assembler writert irni a forditohoz, maskepp eleg nehezen tudnad nyomonkovetni hogy mit is general. Akkor meg mar eleg egyszeru olyan assembly outputot generalni amit megesz egy tetszoleges fordito. Ha mar mukodik a fordito, raersz hozza sajat assemblert meg linkert irni.
Szoval imho a fordito irast nem az ELF formatummal kell kezdeni. :) De azert szurkolok neked. :P Egyebkent sajnos tovabbra is igaz, hogy a mai sokadik generacios x86 (es mas tobbghz-s kategoriaju) processzorokra nehany specialis esetet leszamitva nemigazan lehet kezzel gyorsabb kodot irni, mint amit egy atlagos GCC verzio general. Arrol nem is beszelve, hogy a mai meretu feladatoknal sokkal tobbet szamit az algoritmus, minthogy miben van irva. Lattam mar Java kodot, ami szenne gyalazott assemblyben irt kodot, csak mert aki irta, nagyon is tudta hogy mit es miert csinal. De egyebkent a fentiek ellenere en ma is mindenkinek tanitanek legalabb alapszinten assemblyt informatika kapcsan, mert rohadt sok magat programozonak nevezo embernek fingja sincs arrol, hogy mit is csinal a nyamvadt programja a melyben. Nagy reszben ennek is koszonhetok a kulonbozo csakazertis-hakellhanem-OOP bloatwarek es tsaik. Na hagyjuk. Ja es nem allom meg: procedure stuff; assembler; asm end; rulez meg mindig! :D
- A hozzászóláshoz be kell jelentkezni
> procedure stuff; assembler; asm end;
Errol meg dos alatt le kellett szolnom, 16 bit miatt (nasm 32 bites kodot is tudott forditani, mar dos ala is, asszem)
Mellesleg nem linkert/assemblert akarok irni, hanem egy, a dl helyett hasznalhato, objektumok run-time betoltesere alkalmas libet. Ezzel lehetne bonyolultabb dolgokat is csinalni (pl. sqlite tablabol betoltes, stb.). Szoval nem (csak) irni akarok tudni elf-et, hanem olvasni.
> Lattam mar Java kodot, ami szenne gyalazott assemblyben irt kodot, csak mert aki irta, nagyon is tudta hogy mit es miert csinal.
Bogosort ASM-ben vs. QuickSort JAVA-ban? :)
"No boom today. Boom tomorrow. There's always a boom tomorrow. What? Look, somebody's got to have some damn perspective around here. Boom, sooner or later. BOOM!" -- Lt. Cmd. Ivanova
- A hozzászóláshoz be kell jelentkezni
> procedure stuff; assembler; asm end;
Errol meg dos alatt le kellett szolnom, 16 bit miatt
Pedig lehetett 32 bites muveleteket is hasznalni, igaz kezzel kellett prefixelni a muveleteket (db 66h; db 67h; :D) de egy nagy rakas RealFlat modot hasznalo demo csinalta. :) Mondjuk nem tudom mikor szoktal le rola, de mi '98-ban (8+ eve) mar Free Pascaloztunk, es akkor az mar majdnem fullosan nyomta ugyanezt a dolgot 32 biten, DOS alatt (is). :)
(nasm 32 bites kodot is tudott forditani, mar dos ala is, asszem)
Igen, tudott az is.
Bogosort ASM-ben vs. QuickSort JAVA-ban? :)
Nem, komoly cucc. Akkor inkabb ugy mondanam, hogy lattam olyan (szoftverrenderes) 3D enginet Javaban, ami verte a legtobb (ismet: szoftverrenderes) nativ 3D enginet az adott hardveren. Sebessegben is. Megjegyzem, amugy utalom a Java-t, ez csak egy pelda volt. :)
- A hozzászóláshoz be kell jelentkezni
Azért szoktam le a Pascalos assemblyről, mert Windows ABI leírást nem igazán találtam, Linuxosat pedig még nem kerestem. Arra emlékszem, hogy sikerült olyan tárgykódot csinálnom, amit Túróspacallal még tudtam linkelni, de nem volt jellemző.
A prefixelés pedig 18 éves fejjel nem volt nagyon tiszta és világos, más foglalkoztatott akkoriban (főleg szimulációk és játékelmélet :) ).
A FreePascalt pedig amikor már elkezdtem volna használni, a Pascal önmagában már nem volt divatos (bár már akkor tényleg sokat tudott), majdnem minden forráskód C-ben volt. Illetve Delphit használtam még grafikus programokhoz, régebben (jó kis RAD, az biztos).
A BogoSort-os dolog pedig vicc volt. De ha valaki vette volna a fáradtságot, akkor meg tudta volna írni C-ben is jóra. Itt inkább sztem az a lényeg, hogy Javaban gyorsabban lehet megcsinálni valamit, C-ben viszont gyorsabb lett volna (ugyanannak az algoritmusnak az implementációja), de lassabban készült volna el. TANSTAAFL.
"No boom today. Boom tomorrow. There's always a boom tomorrow. What? Look, somebody's got to have some damn perspective around here. Boom, sooner or later. BOOM!" -- Lt. Cmd. Ivanova
- A hozzászóláshoz be kell jelentkezni