[ASM] Tutorials
 

Wie weet hier een paar, liefst nederlandse, asm tutorials???

wat is ASM?

'assembler' geloof ik

zoja, dan ff met google zoeken en op http://programmeer.pagina.nl staan ook een aantal links

The Art Of Assembly. Engels en 1536 A4-kantjes :)
*heeft thuis de beta draft uitgeprint in de kast liggen*

Ik had trouwens een heel mooi programmaatje, dat heette TechHelp! 4, en daar stond precies in wat je in welk register moet zetten bij welke interrupt.
Dus bijv (weet niet meer precies...):
Om iets naar het (DOS)scherm te schrijven heb je interrupt 13h nodig.

Zoek je in dat programma INT 13 op, staat er iets als:
ah - foreground color (see color section for details)
al - backgrounground color (see color section for details)
cx - counter/repeat count
bx - pointer to data

Weet iemand nog zo'n soort programma?

Proggie ziet er idd handig uit :)

Met interrupts klooien heeft weinig met ASM te maken. Bovendien mag je onder windows geen interrupts gebruiken, compleet outdated dus.

Waarom zou je dan met assembler aan de slag gaan?

Ik zelf om te leren. Hoe alles werkt. Wat de compiler allemaal moet doen. Etc.

Misschien oooooooit nog eens zelf een OS'je d'ruit gooien (hoewel ik die kans zeeeeeer klein acht :))

je kunt ook instructies voor (eenvoudige) processoren schrijven in machinetaal

bv. een processor in een lopende band ofzow

jah, da's waar.
Productieautomatisering. :)

Daarvoor heb je geen assembly nodig. C(++) is genoeg. Alleen om dingen te optimaliseren is het handig assembly te kennen.

Hoe wil je met C/C++ dan een bootsector en bootproces enzow maken???? en hoe kan je anders de A20 line opengooien? hmm en wat dacht je van bootstrapping?

YOOOOOOOOOOHOOOOOOOOOOOOOO

Mn bootprocess (ASM) en mijn kernel (ASM/C++) werken nu :D

je mag niet alle interrupts aanroepen onder windows, direct screen IO idd niet, maar de meeste wel hoor

21h 4Ch bijvoorbeeld werkt ook niet, evenals een hoop andere interrupts die veel gebruikt werden onder dos.

In C kun je dergelijk dingen ook prima doen, je hebt nauwelijks assembly nodig. Poorten en DMA benaderen kan ook zonder assembly.

Granted, als je het wiel opnieuw uit wil vinden, kun je nauwelijks zonder assembly. Maar er zijn tegenwoordig niet veel mensen meer die zelf een compleet OS schrijven :)

*heeft aspiratie* :)

Ik ontwikkel liever nuttige dingen :)

OS == nuttig :)

En ik vind het gewoon :cool: om ASM te kunnen :)

cmp
je
jne
mov
pop

Rince-repeat.

Assembly is simpel, en saai. Wat het 'moeilijk' maakt is dat je zo t*phusveel moet typen. Bovendien is elk stukje assembly 1 jaar nadat je het geschreven hebt voor jou niet meer leesbaar. Da's de hele reden dat men hogere programmeertalen heeft uitgevonden.

Bovendien: Dat iemand zegt assembly te kunnen bewijst niks, het is erg simpel een stukje C naar assembly om te laten zetten i.p.v. een .obj.

Assembly is net zo 'cool' als XHTML, maar aagezien je ook een XHTML fanboy bent...

nee maar waarom zou je dat willen? als je windows af wil sluiten ofzo?

21h 4Ch werd gebruikt om het programma af te sluiten. Om een programma netjes af te sluiten onder Windows heb je sowieso API-calls nodig.

nee hoor :) 't is juist makkelijker: ret

Trouwens, als je je eigen os maakt (waar ik nu dus mee bezig ben ;) kernel en bootstrap doen het al :D) kan je wel interrupts aanvragen, mits je opstart in real mode. Mijn bootstrap zet ik gelijk om naar Protected mode, dus dan kan ik geen iterrupts meer aanroepen, dat betekend dat ik het mezelf vrij moeilijk maak :S

Ik kan nu ook al kleuren op mn kernel plaatsen ^_^ 0x00 tot 0x09...:D en heb al wat eigen C++ functies geschreven voor mn os:

Clear_screen
printf
printclrstr (print een gekleurde stream)...

[edit]
ik zoek trouwens nog assemblers/c++ ers die mee willen helpen ;)[/edit]

Ah... en heb je ook al een eigen filesystem? ;) :D :p

Het bedenken van ene filesystem is imho (een van) de moeilijkste ta(a)k(en)

Heb nog geen filesystem nee...moet ik idd ook nog bedenken. Ik ben eerst nog wat aan de kernel aan het klummelen enzo, wat mooier maken, kleur ondersteuning (werkt al met maar liefst 9 (!) kleuren :P).

moeilijk?? :confused: volgens mij is dat echt een eitje.. serieus
om het een beetje efficient te maken is natuurlijk wel iets moeilijker maar toch... het ontwikkelen van de API en het porten van de ansi C libraries enzo lijkt me een stuk lastiger

Oh, en hou dacht jij het indexeren en het fregmenteren precies te doen? Of heeft elke file bij jou een maximum grootte?

Ben op dit moment nl. bezig met een Virtual Filesystem in Java, en ik kan je wel vertellen dat dat alles behalve simpel is.

Yeh voor de filesystem rek ik ook een tijdje uit. En ik moet ook nog zelf C++ header files etc schrijven....

Ik ben nu nog bezig met de Interrupt geval, zou wel handig zijn als ik toetsenbord iig kan gebruiken :D

ow.. tja ik heb het nooit geprobeerd hoor maar ik denk dat het relatief gezien toch wel makkelijk is... per directory een tabel met verwijzingen naar de file-data.. of inodes ofzo en zo ook bij subdirectories in de file-data weer een nieuwe tabel ofzo

'Interrupt geval'?

Interrupts handler? Zorg eerst maar eens dat je memory allocatie werkend krijgt :D

Jajajaja...ik doe eerst interrupt handler zodat ik tenminste ctrl + alt + del kan gebruiken enzow :D MA komt ook wel allemaal goed :D

ow je gaat de BIOS interrupts opnieuw implementeren, nu begrijp ik het

'inodes ofzo' :rolleyes: :p

Een inode bindt een bestandsnaam aan de werkelijke data-segmenten op een schijf.

Elke directory is zelf een bestand, met verwijzingen naar andere bestanden.

Bij POSIX-compliant systemen krijg je dan het volgende:

Je hebt de root-directory, wat zelf een bestand is. In deze staat een lijst met verwijzingen naar andere directories met hun inode nummer.

Als je de root traversed, lees je dus directory-bestanden met bijbehorende inodes in. Uit de inode blijkt ook dat het bestand een directory, of zelf een logisch bestand is. Zodoende kunnen we naar behoefte verder traversen :)

Maar goed, het lijkt mij alles behalve simpel. Vooral het reserveren van data-segmenten en het terugdringen van fragmentatie lijkt me een hels karwei.

Zeg dus niet dat iets relatief gezien simpel is als je er geen verstand van hebt.

Inderdaad. Een schoolopdracht was het maken van een programma dat een dergelijk filesysteem kon lezen. Er werd je een file gegeven met dezelfde inhoud als een (pre-)POSIX bestandssysteem.

Een dergelijk systeem is opgebouwd uit blokken met een vaste grootte. Een block inodes bevat verwijzingen naar datablokken. Dit kunnen files (gewoon data), directories (bestandsnamen met hun inodeblokken) of indexblokken zijn. Omdat bestanden vaak groter zijn dan een blok, heb je een index met verwijzingen naar de verschillende datablokken verspreid over de schijf. Een dergelijk index kan verwijzen naar een datablock, maar ook weer naar een nieuwe index. Zo'n indexboom kan wel 3 lagen diep zijn.

Simpel? Allesbehalve. Wij hoefden alleen te lezen, en dan hoef je zelf geen rekening te houden met blockallocatie, om nog maar niet te spreken over fragmentatie. Bovendien was het een virtueel FS, gewoon een file in het filesysteem dus. Als je zelf een FS gebruikt moet je rechtstreeks de disk benaderen.

En McMotion: Een paar tabelletjes verzinnen met verwijzingen naar files is geen groot probleem. Maar hoe ga jij een file laten 'groeien' als er een datablock van een andere file achter staat?

Het grootste probleem voor een FS is blocks alloceren. Hoe je dingen als bestandsnamen opslaat is wel je laatste probleem.

weet ik.. behalve dan dat een inode helemaal NIKS koppelt.. het is gewoon een verwijzing naar een blok data op je hd

mjah ok je hebt ook wel gelijk.. alleen al die andere dingen voor een OS lijken me zoveel moeilijker! :eek:

Een direntry heeft een naam (bestandsnaam) en een inode nummer. Een inode wordt geidentificeerd door zijn nummer, en geeft aan waar de datablokken op schijf staan.

Een inode is dus inderdaad de koppeling tussen een bestandsnaam en de fysieke data.

Je hebt geen flauw idee waar die kleper uithangt kerel.

GELUL

een inode is geen koppeling tussen bestandsnaam en fysieke data

Ach, meneer weet het beter.

Mag ik je d'r ff aan herinneren, dat ik ZELF een implementatie heb moeten maken?

Een directorylijst ziet er als volgt uit:

INODE NAME
INODE NAME
INODE NAME
INODE NAME
INODE NAME

Etc.

Een inodelijst ziet er als volgt uit
NUMBER RIGHTS FLAGS INDEX
NUMBER RIGHTS FLAGS INDEX
NUMBER RIGHTS FLAGS INDEX
NUMBER RIGHTS FLAGS INDEX

Een inode is absoluut de koppeling tussen de data en de bestandsnaam. De bestandsnaam staat namelijk NIET in de inode, maar in de DATA van een directory. Om van bestandsnaam naar data te komen moet je dus via het nummer en de inode de locatie van de data opzoeken.

Vind je het zelf ook niet een beetje absurd dat je ons de les zit te lezen, terwijl je zelf toegeeft geen flauw idee te hebben hoe een POSIX FS werkt?

ik geloof wel dat je er verstand van hebt maar je verwoording klopt volgens mij gewoon niet... als je 2 hardlinks hebt naar 1 bestand, bla1 en bla2, dan gaat het maar om 1 inode... maar je hebt twee koppelingen nodig, want de bestandsnaam bla1 is gekoppeld aan die data, en de bestandsnaam bla2 ook... de koppeling noem ik dus de direntry.. welke bestandsnaam bij welke inode hoort
je zegt zelf al dat een bestandsnaam niet in een inode staat... hoe kan het dan in godsnaam een koppeling zijn tussen de bestandsnaam en het datablok!

verder denk ik niet dat ik het beter weet, maar ik sta er gewoon van te kijken hoe iemand als jij dag in dag uit iedereen loopt te flamen (22 was het toch?) en overal op loopt af te kraken omdat ze iets niet goed begrijpen of verkeerd verwoorden, terwijl je later helemaal dol wordt (hap) als iemand jou eens een keer probeert te verbeteren

Flamen? Het is gewoon een 'beetje' irritant om om te moeten gaan met betweters, that's all.

Dus nogmaals: Een direntry verwijst naar een inode, een inode verwijst naar de data. Hoe kan een inode dan geen koppeling zijn tussen naam en data? Zonder inode is de data onbereikbaar.

Waarom is het een koppeling? Startsituatie is dat je alleen een bestandsnaam hebt. Hoe kom je aan de data? Precies, door eerst de bijbehorende inode op te zoeken, zodat je een pointer naar de data krijgt.

Een bestandsnaam is geen koppeling, het is gewoon een naam.

En verder: Wees blij dat iemand je de moeite neemt dit uit te leggen. Anders zou je voor de rest van je leven clueless blijven.

ik had ook niet verwacht dat je je ongelijk zou toegeven hoor ;) laat deze thread eens lezen aan een taaldeskundige ofzo.. maargoed ik was mijn docent inderdaad dankbaar toen hij het onderwerp behandelde

Wat heeft taal te maken met het onderwerp van de discussie?

Beetje zwak dat je er zo uit probeert te lullen. Er zijn twee mensen die weten waarover ze praten die je dit zaakje uitleggen, en jij blijft volhouden dat je het beter weet. Prima. Verwacht geen hulp als die nog eens nodig hebt.

Ik wil fouten bovendien best toegeven, geen enkel probleem. Maar in dit geval heb ik gewoon gelijk. Punt uit. Als jij het er niet mee eens bent, prima, maar kom dan eens eindelijk een keer met argumenten.

pff die argumenten staan hier boven... en wat het met taal te maken heeft? jij weet niet wat een koppeling is

http://wks.uts.ohio-state.edu/unix_c...tml#HEADING6-0

Inode is per file. Bij meerdere hardlinks krijg je dus waarschijnlijk ook meerdere inodes.

Yup. Bij een harde link wordt een kopie van de inode gemaakt. Bij een softlink wordt gewoon een direntry gemaakt die verwijst naar dezelfde inode.

Nog een hoop gedoe voor het systeem trouwens. Zie maar eens bij te houden wie allemaal naar een file linkt. Zelfde systeem als het garbage collection van bijvoorbeeld Java, references tellen :)

:confused: maar als de inode gekopieerd zou worden zouden beide hardlinks toch een ander inodenummer krijgen?

en bijvoorbeeld die referencecount moet worden bijgehouden op een centraal punt... de inode.. dan klopt er toch niets meer van als daar kopieen van worden gemaakt?

Yup, krijgen ze ook. Beide direntries wijzen elk naar een andere inode, en beide inodes wijzen naar dezelfde data blokken.

Dit weet ik overigens niet zeker, en ik ben te lui om het op te zoeken.