Assembly leren nodig?

[SH4D3H]

Nog wakker van de koffie?
Mooi!

Vandaag heb ik het volgende ‘probleem’:
Ik zat vanmiddag te IRC’en met een PSP progger, best leuk enzo, maar toen ik wat vragen stelde over de werken van bepaalde dingen kreeg ik antwoorden waar ik totaal niets mee kon.
Zo werden er allerlei asm(?) instructies in mijn venster gespamt, begon hij over stack/heap dingen en kreeg ik wat output van een hexeditor met een korte uitleg wat de getalletjes voorstelde: “Ja, bij 0xHEX zie je staan 0xHEX 0xHEX 0xHEX 0xHEX, daar gebeurt het!” … Jaja …
Nu zou ik heel graag willen snappen waar het over gaat, wat sommige mensen bijvoorbeeld kunnen vertellen door een programma in een hexeditor te stoppen is ongelofelijk (voor mij dan).
Ik zou dat ook graag willen kunnen, maar heb een duwtje in de goede richting nodig.

Als ik bijvoorbeeld kijk naar de 24C3 presentatie over de PSP hacks snap ik er ook al vrij snel weinig meer van.

Wat is nu mijn volgende stap?
Moet ik ‘gewoon’ asm gaan leren?
Helpt dat me begrijpen hoe het werkt?

* SH4D3H heeft praktijk ervaring met PHP en vooral theorie van C++ & JAVA (omdat ik geen nuttige projecten heb kunnen bedenken nog ).

[Cyphax]

Assembly is verre van ingewikkeld. Als je wilt gaan JAVA'en of PHP'en heb je volgens mij niet zoveel aan kennis van Assembly. Als je met C(++) werkt kan het wel interessant zijn om wat inzicht te krijgen in dat niveau.

Het is trouwens niet alleen kennis van de taal maar ook de werking van het geheugen en je processor. Heaps, stacks, registers, dat soort dingen, daar kun je zat over lezen.

[edit]
Moet je wel de documentatie van het juiste platform lezen, een PSP kan wel heel anders in elkaar zitten dan de gemiddelde PC (x86) en het is allemaal platformspecifiek. Alleen de terminology is vast in sommige of veel gevallen wel hetzelfde.

[ Voor 24% gewijzigd door Cyphax op 03-01-2008 01:01 ]

[Dysmael]

Het is al heel erg gedateerd maar ik heb veel geleerd van Ralph Brown's interrupt list en Ray Duncan's Advanced MS-DOS.

[Nijn]

Misschien niet geheel on-topic, maar wel handig:
Het afgelopen half jaar heb ik een vak gehad over computersystemen. Daarbij werdt gebruik gemaakt van een boek dat vanuit een programeer-standpunt uitlegd hoe computersystemen in elkaar zitten. Daarin werd ook veel uitgelegd over de werking van hogere en lagere programeertalen en bovendien kwam assembly erg vaak langs.

Als je hierin geintreseerd bent, het boek heet "Computer Systems Architecture: a Networking Approach". Hierin vind je overigens geen lessen over assembly zelf. Je leert hoe dingen in elkaar steken en hoe assembly commando's werken, maar je leert niet precies welke commando's er voor bepaalde architecturen zijn, hoe je ze precies gebruikt en wat "bad practice" is. (zou ook niet echt verstandig zijn omdat iedere processor zijn eigen instructies kent)

Stack en heap komen wel voor, al is dat relatief simpel. Wikipedia zal er wel het een en ander over hebben maar het komt erop neer dat een programma 3 soorten geheugen gebruikt:

Instructions Waar de programmacode staat
heap Vooral globare variabelen
stack Deze moet je even opzoeken want er is meer, maar voor nu: Dit is waar de variabelen en statussen van subfuncties worden opgeslagen. roept functie1 functie2 aan, dan wordt er een deel bovenop de stack gereserveerd voor functie2, waar zijn eigen locale variabeles opgeslagen worden en waar informatie te vinden is om weer terug te komen bij functie1. Na de uitvoer van functie2 wordt zijn deel op de stack ook weer eraf getrapt. Vandaar ook de naam stack, het wordt opgestapeld.

//edit: Dit boek is vast wel goedkoop 2e hands op de kop te tikken want er zijn veel 1e jaars IT studenten (universitair) die het gebruiken.

[ Voor 11% gewijzigd door Nijn op 03-01-2008 01:19 ]

[Sentry23]

Assembly.. altijd makkelijk

Ik ben zo'n beetje opgegroeid met Motorola 68000 assembly, en later ook Motorola 56001 DSP assembly, maar voor het lezen van hex code heb ik altijd disassemblers gebruikt.. het voordeel van assembly is dat je code 1 op 1 in instructies wordt omgezet, zodat als je de hex-code kent van de instructie deze ook wel weer kan terugvertalen naar de instructie, maar dat is meer bragging rights dan echt nuttig als je een disassembler bij de hand hebt.

Voor zover ik heb begrepen is het op PSP alleen ook mogelijk om in C te coden. Om het maximale uit je hardware te halen zitten er wel voordelen aan assembly: je weet welke instructies veel en weinig tijd kosten, en je kan daar dus rekening mee houden met het ontwerp van je code.
Het is alleen erg tijdrovend om je code volledig in asm te schrijven, en wat een goed begin kan zijn is door te beginnen met C code, en dan stukjes inline assembly toe te passen voor een simpel algoritme. Zo heb je meer de tijd om langzaam te begrijpen wat er nu precies gebeurt met bepaalde intructies.

Daarnaast heb je dus ook nog eens de kennis nodig om de interne werking van het systeem om de hardware te begrijpen. Assembly is in dit geval maar een begin, wat je nodig hebt om meer inzicht te krijgen in de werking van registers, FIFOs en andere hardware related zaken.
Als je bijvoorbeeld ziet dat een instructie een bit patroon naar een adres schrijft is dat in asm volledig duidelijk (move.l %10010001, adres) , maar als je niet weet dat er een hardware register aan dat adres hangt, en dat het bitpatroon een bepaalde setting is dan zal het nog steeds erg vaag blijven wat er aan de hand is.
Naast assembly boeken (waar er meer dan genoeg voor zijn) zal het dus ook nodig zijn wat van je doelsysteem te leren hoe de architectuur in elkaar zit, wat de register map is , etc etc..

Misschien heb je wat aan deze presentaties om een wat rustiger intro te krijgen in de PSP ?
http://ps2dev.org/psp/Tutorials

[Onbekend]

Voor tijd-kritische programma's gebruik ik assembly. Anders gebruik ik een hogere programmeertaal.

Als je wat grotere programma's gaat maken, dan raad ik je wel aan om wat kennis op te doen over assembly. Niet dat je het gaat gebruiken, maar meer dat je weet hoe bepaalde stukken code werken. (Bijvoorbeeld iets x2 vermenigvuldigen gaat (meestal) trager dan een bitje naar links verschuiven.)
Assembler kost over het algemeen wel meer tijd om te programmeren, maar je weet wel exact wat het programma doet in de stack en geheugen gebruik.

[Bob]

Onbekend schreef op donderdag 03 januari 2008 @ 11:15:
(Bijvoorbeeld iets x2 vermenigvuldigen gaat (meestal) trager dan een bitje naar links verschuiven.)

Da's toch werk werk voor g++? Zulke eenvoudige zaken moet een compiler toch zeker zelf kunnen. Of bedoel je gewoon dat het interessant is om te weten dat bitshiften snel is?

[ Voor 11% gewijzigd door Bob op 03-01-2008 11:20 ]

[Creepy]

Voor "gewoon" PSP proggen ga je met C/C++ een heel eind komen.

De link die je geeft m.b.t. de pandora batterij e.d. beschrijft de werking en de hack hiervan. Dit gebeurt op zo'n nivo dat het bijna noodzakelijk is om het in ASM te doen. De dumps van geheugen e.d. worden in hex weergegeven. Als er in die geheugen dumps instructies staan kan dit vrij simpel worden vertaald naar ASM opcodes zodat je weet wat er gebeurd. Dit soort hacks worden nagenoeg altijd gedaan na bestudering van de firmware en geheugen dumps en dan ontkom je er niet aan om dit soort dumps te leren lezen waarbij ASM kennis een must is.

Maar nogmaals: als je wat homebrew wilt maken voor de PSP is ASM geen noodzaak en kan je prima met C en C++ uit de voeten.

Onbekend schreef op donderdag 03 januari 2008 @ 11:15:
Voor tijd-kritische programma's gebruik ik assembly. Anders gebruik ik een hogere programmeertaal.

Als je wat grotere programma's gaat maken, dan raad ik je wel aan om wat kennis op te doen over assembly. Niet dat je het gaat gebruiken, maar meer dat je weet hoe bepaalde stukken code werken. (Bijvoorbeeld iets x2 vermenigvuldigen gaat (meestal) trager dan een bitje naar links verschuiven.)
Assembler kost over het algemeen wel meer tijd om te programmeren, maar je weet wel exact wat het programma doet in de stack en geheugen gebruik.

Een beetje compiler optimaliseert dit soort zaken echt wel. Ik zou me met dit soort zaken ook echt pas bezig gaan houden nadat ik de boel heb geschreven in C of C++ (voor de PSP dan) en eventueel dit soort zaken gaan aanpassen als je merkt dat het ook daadwerkelijk een performance winst gaat opleveren.

[ Voor 39% gewijzigd door Creepy op 03-01-2008 11:25 ]

[Oguz286]

Ik programmeer zelf voor de PSP en ik heb tot nu toe geen assembly gebruikt. Maar het kan inderdaad makkelijk zijn als je bijvoorbeeld tijdkritische functies moet hebben of de media engine van de PSP wil gebruiken (al is men wel bezig om functies voor de SDK te schrijven).

De processoren in de PSP zijn R4000 mips processoren dus als je assembly wilt leren dan moet je wel assembly voor die processor leren en niet voor de x86. Download gewoon de SDK en kijk naar de voorbeelden en probeer daarvan te leren (het is in C geschreven) en als je het later nodig hebt kun je assembly erbij leren.

[SH4D3H]

Creepy schreef op donderdag 03 januari 2008 @ 11:23:
Voor "gewoon" PSP proggen ga je met C/C++ een heel eind komen.

Ja, dat is het probleem ook niet.
Ik heb al eens een memory spelletje gemaakt voor de PSP in C, dat was best leuk.
Maar:

De link die je geeft m.b.t. de pandora batterij e.d. beschrijft de werking en de hack hiervan. Dit gebeurt op zo'n nivo dat het bijna noodzakelijk is om het in ASM te doen. De dumps van geheugen e.d. worden in hex weergegeven. Als er in die geheugen dumps instructies staan kan dit vrij simpel worden vertaald naar ASM opcodes zodat je weet wat er gebeurd. Dit soort hacks worden nagenoeg altijd gedaan na bestudering van de firmware en geheugen dumps en dan ontkom je er niet aan om dit soort dumps te leren lezen waarbij ASM kennis een must is.

Ik ben juist erg geïnteresseerd in de werken van de firmware en de PSP zelf.
Een PC is echt lastig (vaak veel verschillende onderdelen enzo) terwijl zo'n stukje hardware op een revisie na hetzelfde blijft.
Maar met mijn huidige kennis is dat onmogelijk, helaas

Ik heb dus niets aan een boek over Assembly voor x86?
Zijn er ook boeken die 'algemeen' assembly beschrijven of moet je echt een platform kiezen?
Afgezien van de platformspecifieke registers etc is de taal toch hetzelfde?

[Refro]

Hoe dichter je bij de hardware zit hoe handiger het is om assembler te kennen. Echt moeilijk is het niet je moet wel wat kennis over de cpu hebben maar dan zijn het gewoon allemaal zeer elementaire instructies die niet altijd heel logisch zijn maar sommige dingen moeten gewoon gebeuren omdat de hardware boer dat nodig vindt en je tenslotte met hardware wil praten.

Zelf heb ik vrij uitgebreide assembly kennis (oa 8051, c166, 68000) maar dit gebruik ik dan ook wel vrijwel dagelijks op mijn werk. Assembly om optimalisaties in een programma te maken is mijns inziens vrij nutteloos dat kunnen compiler bouwers over het algemeen beter en tegenwoordig weegt de ontwikkeltijd/onderhoud vaak niet op tegen een net iets snellere cpu gebruiken.

[Onbekend]

Ik ben het niet eens met de stelling dat een snellere cpu beter is dan het gebruik van assembly.
Zelf doe ik op dit moment veel met beeldverwerking en grote datahoeveelheden, en dan is het gebruik van assembly zeker nuttig. Een betaalbare snelle processor weegt niet op (bij mij) tegen het programmeren in assembly.


Ik zie dat je dit wil gebruiken voor de PSP om wat informatie uit binaire data te halen. Ik denk dat het dan toch wel verstandig is om eens wat kennis op te doen over assembly.

[Refro]

Onbekend schreef op donderdag 03 januari 2008 @ 12:07:
Ik ben het niet eens met de stelling dat een snellere cpu beter is dan het gebruik van assembly.
Zelf doe ik op dit moment veel met beeldverwerking en grote datahoeveelheden, en dan is het gebruik van assembly zeker nuttig. Een betaalbare snelle processor weegt niet op (bij mij) tegen het programmeren in assembly.

Deze stelling moet ik dan mischien ook wat nuanceren. In ons geval met 2000 tot 3000 apperaten per jaar is optimalisatie door assembly niet nuttig. Er zijn natuurlijk altijd gebieden waar dit niet voor geldt. Maar om er tegenwoordig mee te beginnen moet je wel alle andere dingen goed hebben afgewogen en zeker weten dat je programma gewoon goed in elkaar zit en je op andere manieren niet meer kan winnen.

[Creepy]

SH4D3H schreef op donderdag 03 januari 2008 @ 11:39:

Ik heb dus niets aan een boek over Assembly voor x86?

Nope..

Zijn er ook boeken die 'algemeen' assembly beschrijven of moet je echt een platform kiezen?
Afgezien van de platformspecifieke registers etc is de taal toch hetzelfde?

Er zijn verschillende assemblers met hun eigen syntax (grofweg zijn dit er maar twee). Maar de syntax is het probleem niet. Je moet het systeem kennen zodat je weet wat de code nu precies doet.

Bij de SDK van de PSP zit volgens mij ook een assembler bij (ik dacht nasm) maar dat is vrij simpel te checken Maar zonder kennis van de PSP zelf ga je ook niet zomaar assambly schrijven of schrijven. Je zult moeten leren waarvoor een bepaald geheugen adres dient, welke bios routines er zijn en hoe die aangeproken worden e.d.

[ Voor 8% gewijzigd door Creepy op 03-01-2008 13:11 ]

[hamsteg]

Als ik de vraag goed lees gaat het eigenlijk helemaal niet over assembly, maar over debuggen van software !!!

Afhankelijk van de (hardware)debugger kun je gewoon in een bepaalde taal meekijken. Vaak zijn embedded systemen in dermate kleine oplages dat het zich niet loont om een debugger naar een hogere programmeertaal om te schrijven en zal men zich beperken tot de assembly code.

Wat jij vraagt is meer een inhoudelijke achtergrond kennis over hoe een programmeertaal in basis werkt (op een specifiek stuk hardware). Wat gebeurt er als ik 33Kb declareer op de stack en er maar 32Kb beschikbaar is? Als je dat wilt weten zul je toch terug moeten naar talen waar je alles zelf moet doen en dingen niet impliciet voor jou worden geregeld ... wat zijn pointers? Hoe manipuleer ik geheugen en wat gebeurt daar precies, wat is een memory dump en wat zie ik, hoe wordt een functie call op de stack gezet??

Je komt dan snel in de C of ASM wereld terecht maar alleen de taal kennis zal je niet verder helpen. Leer van zo'n knakker waar je mee aan het MSN-en bent en vertel hem eerlijk wat je wel en niet snapt. Als je een goede basis in programmeren hebt zul je het relatief snel oppakken. Heel snel zul je de stack dumps / debug info's wel snappen. Daarna gewoon lekker zelf hacken op je device (of met de RalfBrown Interrupt lijst op een MS-Dos machientje). Elke processor, met name die in Embedded Devices, hebben specifieke eigenschappen dus een algemeen gedetaileeerde kennis vergaren kan niet, wel overkoepelende meer generieke kennis.

[SH4D3H]

hamsteg schreef op donderdag 03 januari 2008 @ 14:27:
Wat jij vraagt is meer een inhoudelijke achtergrond kennis over hoe een programmeertaal in basis werkt (op een specifiek stuk hardware). Wat gebeurt er als ik 33Kb declareer op de stack en er maar 32Kb beschikbaar is? Als je dat wilt weten zul je toch terug moeten naar talen waar je alles zelf moet doen en dingen niet impliciet voor jou worden geregeld ... wat zijn pointers? Hoe manipuleer ik geheugen en wat gebeurt daar precies, wat is een memory dump en wat zie ik, hoe wordt een functie call op de stack gezet??

Ja, precies.
Ik weet wat een pointer is/doet, maar hoe het op de achtergrond werkt weet ik niet.
Voor mij is een function-call gewoon een regeltje in mijn sourcecode, maar wat gebeurt er nou echt.
En dan als het kan bijv. een stukje ASM/C injecteren om te kijken wat er gebeurt.
Maar vooral het lezen van de dumps/assembly wil ik kunnen.

Je komt dan snel in de C of ASM wereld terecht maar alleen de taal kennis zal je niet verder helpen. Leer van zo'n knakker waar je mee aan het MSN-en bent en vertel hem eerlijk wat je wel en niet snapt.

Hij heeft niet zoveel tijd(/zin? ) om leraar te spelen.
Ik wil het dus het liefst zelfstandig aanpakken

[hamsteg]

Mmm ...

Dat betekent heel veel zelf leren. Schrijf maar eens een "hello world" in C en plaatst deze print daarna maar eens in een functie. Kijk met een debugger maar eens wat er op stack staat.

http://en.wikipedia.org/wiki/Call_stack

Zo even dit leren kan niet. Het is veel vallen en opstaan. Het kost nogal wat tijd om een basisniveau te krijgen en de snelste weg is nog steeds vragen. Het kost sommigen jaren om een ARM processor of een Intel Processor te doorgronden ... dat kan niet even in een paar uur verteld worden.

Welkom in de embedded wereld!

[SH4D3H]

Maar als ik zie wat er staat weet ik toch nog niet wat wat is?
Of kan dat wel zonder bijv. asm te kennen?

[hamsteg]

Met debugger kun je naast code ook memory dumps opvragen. Die memory dumps zijn vaak interessant. Echt ASM programmeren hoeft niet, in C kun je inline ook ASM implementeren op die manier zou je ook nog kunnen experimenteren.

http://www.jalix.org/ress...sembleur/_asmfaq/GEN3.TXT
http://www.ctyme.com/rbrown.htm

sorry maar je zult veel zelf moeten dus en toch veel vragen ....

[SH4D3H]

Vragen zal niet zo'n probleem zijn (hoop ik).
Hij zei alleen dat hij geen tijd/zin had om alles uit te leggen (en leraartje te spelen).

Ik ga je linkjes eens bekijken en heb van hem 'The Art of Assembly' gekregen
Wellicht dat ik daar ook wat mee kan.

[farlane]

Wat mij veel geholpen heeft bij het debuggen van embedded dingen ( en achteraf bleek soms het debuggen van een compiler ) is de list/map files. Bij de meeste compilers kun je die laten maken, hierin kun je zien hoe de C compiler de code vertaalt in assembly ( list file ) en waar de linker alle variabelen laat in het geheugen ( map file )

[LauPro]

Het schrijven van assembly heb ik mij jaren terug al afgezworen, het kunnen intepreteren en debuggen echter niet. Het verschilt ook niet zoveel van C code als je de language structures goed kan herkennen.

Ligt een beetje aan de definitie van 'leren' dus.

[SH4D3H]

LauPro schreef op vrijdag 04 januari 2008 @ 22:58:
Ligt een beetje aan de definitie van 'leren' dus.

Jah, schrijven is ook niet direct het doel.
Het gaat vooral om het lezen (en begrijpen) van de code

[Onbekend]

SH4D3H schreef op zaterdag 05 januari 2008 @ 13:14:
[...]

Jah, schrijven is ook niet direct het doel.
Het gaat vooral om het lezen (en begrijpen) van de code

Eigenlijk heb je dus alleen maar een decodeerwoordenboek nodig die de hexadecimale getallen omzet in gemakkelijker te lezen taal.

Als je verder weet de standaard eigenschappen van asm (stack, geheugen e.d.) weet, is het voor de rest wel te doen.
In het begin is het lastig, maar hoe langer je er mee werkt, des te makkelijker wordt het.

[SH4D3H]

Ik hoop het
Binnenkort heb ik wat tijd teveel en ga ik eens serieus wat proberen.

[Kwastie]

de PSP maakt gebruik van de MIPS processor, ik gebruik zelf IDA-pro om in de MIPS te kijken. Maar ik weet niet wat je percies wilt maken, maar het is niet 'verplicht' om MIPS te kunnen lezen, het word alleen gebruikt om dingen te reverse engineeren. http://nl.wikipedia.org/wiki/Reverse_engineering

[SKiLLa]

Als je trouwens een x86 debugger zoekt: OllyDBG, de defacto - gratis - debugger van de afgelopen paar jaar. En verder inderdaad veel, veel inlezen

[Kwastie]

maar het installeren van de psp-sdk is ook een kunst opzich(teminste als je het onder windows wilt) je moet namelijk eerst cygwin, installeren vervolgens psp-toolchain, al met al duurt dit een uurtje of 5/6. Er zijn wat alternatieven, pspdev32 bijv.Alleen het probleem met deze tool is dat hij outdated is en niet overweg kan met de nieuwste firmwares.
Edit: Gelukkig heeft de psp een goede SDK. Mocht je hulp nodig hebben met psp-prog. PM me maar, mischien kan ik je wel helpen.

[ Voor 15% gewijzigd door Kwastie op 05-01-2008 19:17 ]

[SH4D3H]

Kwastie schreef op zaterdag 05 januari 2008 @ 19:11:

De toolchain (en/of cygwin als ik niet op linux zit) installeren is het probleem niet, ook de programma's zelf niet. Nouja, de programma's die netjes via de API verlopen dan.
Ik wil dus graag verder kijken dan dat en dat gaat me met al die tips vast wel lukken!

SKiLLa, thanks voor de link