[ASM] hoe wel goed

[Verwijderd]

Ik ben een beginnende Assembler coder en ik probeer telkens kleine progjes te maken. Ik heb nu het onderstaande gemaakt maar er zitten een paar dingen in die mijn naswm compiler niet slikt. Kan iemand mijn code zo maken dat hij het wel gaat slikken maar dan wel zoveel mogelijk moet het lijken op mijn orginele code.

code:

[org 0x0100]

xmode db 0x01
Pixelcolor db "1"

.code
jmp @start

@putpixel: ;pop1=X->BX,pop2=Y->CX
  mov ax,0x0A000
  mov es,ax
  pop bx
  pop cx
  mov si,xmode
  lodsb
  mov ax,di
  mov dx,0x01
  or dx,al
  jz gui1
  mov dx,0x02
  or dx,al
  jz gui2
  gui1
  xor ax,ax
  mul cx,0x0140
  add bx
  mov si,pixcol
  lodsb
  mov cx,di
 
 
  mov es:ax,cx
  jmp exit
  gui2
  
  jmp exit
  exit:
 ret

@start:
mov ax,0x13
int 0x10
mov ax,0x012
push ax
mov ax,0x012
push ax
jmp @putpixel
mov ah, 0x00
int 0x16

[Verwijderd]

zie nu ff nog een foutje. Dat pixcol en pixelcolor moet natuurlijk wel overeenkomen

[whoami]

[nohtml]

Verwijderd schreef op 27 oktober 2002 @ 14:22:
Ik ben een beginnende Assembler coder en ik probeer telkens kleine progjes te maken. Ik heb nu het onderstaande gemaakt maar er zitten een paar dingen in die mijn naswm compiler niet slikt. Kan iemand mijn code zo maken dat hij het wel gaat slikken maar dan wel zoveel mogelijk moet het lijken op mijn orginele code.

Neen, je zult het zelf moeten doen, maar men zal je daar wel bij willen helpen.

Maar dan moet jij wel wat specifiekere informatie geven dan enkel de code hier te posten. Zeg eens wat die code moet doen, wat er niet lukt, wat er wel lukt, waarom je dingen precies op die manier doet etc....

Lees misschien even de P&W Quickstart door.

[whoami]

Welkom in P&W -> Quickstart (update 2/10/2002)

[Soultaker]

Oh ja - als grote uitzondering op de andere programmeertalen, is 't met assembly wel gebruikelijk om commentaar bij je code te zetten. Hier is geen touw aan vast te knopen.

Zelf ben ik trouwens ook groot voorstander van aparte kolommen voor opcode en argumenten (dus alle eerste argumenten beginnen op dezelfde positie op de regel), dat vergroot de leesbaarheid ook aanzienlijk.

[matthijsln]

code:

or dx,al

"invalid combination of opcode and operands": bij een OR instructie kan je niet deze twee operands gebruiken. dx is een 16 bits register en al 8 bits dus dat is al niet logisch en als je dan in de Intel manual kijkt zie je dat deze instructie dus zo ook niet kan (zie http://developer.intel.com/design/Pentium4/manuals/ voor de manuals, http://developer.intel.co...ntium4/manuals/245471.htm voor beschrijvingen van alle instructies).

code:

mul cx,0x0140

mul heeft maar één operand, dat is de waarde waarmee AX, DX:AX of EDX:EAX mee moet worden vermenigvuldigd. Dat is nogal een lompe restrictie, maar imul (signed multiply) kan wel met deze twee operands worden gebruikt.

code:

  add bx

Hier hoort een tweede operand bij, namelijk wat je bij bx op wilt tellen.

[Verwijderd]

jasperh17 schreef op 27 oktober 2002 @ 14:22 iets over een compiler:

Heet zoiets geen assembler
En misschien even je code opdelen in kolommen, en voorzien van commentaar, zoals eerder gepost.

[Juicy]

Soultaker schreef op 27 oktober 2002 @ 14:41:
Oh ja - als grote uitzondering op de andere programmeertalen, is 't met assembly wel gebruikelijk om commentaar bij je code te zetten. Hier is geen touw aan vast te knopen.

Ik weet niet waar je deze wijsheid vandaan hebt, maar als je geen commentaar gebruikt in welke programmeertaal dan ook dan ben je toch echt een spaghetti-programmeur. Op deze manier kun je ten minste code genereren die absoluut niet meer te onderhouden is.

[Soultaker]

Juicy schreef op 27 oktober 2002 @ 15:36:
Ik weet niet waar je deze wijsheid vandaan hebt, maar als je geen commentaar gebruikt in welke programmeertaal dan ook dan ben je toch echt een spaghetti-programmeur. Op deze manier kun je ten minste code genereren die absoluut niet meer te onderhouden is.

Dat is onzin. Als je je code goed structureert en geschikte identifiers gebruikt (patterns!) is in een conventionele programmeertaal commentaar grotendeels overbodig. Assembly is een uitzondering, omdat je, zo mogelijk, registers gebruikt als variabelen (niet overal natuurlijk, maar juist wel in cruciale delen van je algoritmen). Hierdoor is commentaar, wat de verschillende variabelen doen, noodzakelijk.

Er zijn trouwens wel meer dingen in assembly, die becommentariseerd moeten worden, zoals de scope waarbinnen gewerkt wordt, de registers en variabelen die gewijzigd worden door een procedure, enzovoorts, die in een conventionele programmeertaal impliciet duidelijk zijn.

Let wel, ik maak verschil tussen documentatie op project-nivo (van de interfaces van de verschillende onderdelen) en commentaar in de code, om uit te leggen wat specifieke regels doen.

[Primal]

Soultaker schreef op 27 oktober 2002 @ 16:02:
[...]

Dat is onzin. Als je je code goed structureert en geschikte identifiers gebruikt (patterns!) is in een conventionele programmeertaal commentaar grotendeels overbodig. Assembly is een uitzondering, omdat je, zo mogelijk, registers gebruikt als variabelen (niet overal natuurlijk, maar juist wel in cruciale delen van je algoritmen). Hierdoor is commentaar, wat de verschillende variabelen doen, noodzakelijk.

Hier ben ik het dus ook niet mee eens. Als je een groot programma (bijv. ter grootte van Windows 9x of zo) hebt geschreven, dan wil je over een jaar of 2 toch nog wel weten wat bepaalde specifieke (moeilijke stukken) code/algoritmen ook al weer deed?! Of denk jij dat je wel onthoudt waarom je methode X moest gebruiken in geval Y?! Sterker nog, als je in het geval van Windows 9x in een projectgroep werkt (van laten we zeggen een man of 50 of zo), dan is er veel code die je zelf niet hebt geschreven.
Ik ben het wel met je eens dat als je de juiste variabele/functie/constante/etc namen kiest, dat dat al een hoop kan schelen. Verder ben ik het ook met je eens dat als je je code duidelijk opzet (dus bijv. niet 10 statements op dezelfde regel), dan scheelt dat ook een hoop. En wat ik helemaal met je eens ben is dat je in Assembler absoluut niet zonder commentaar kunt gaan programmeren (en dan heb ik het natuurlijk over grote, moeilijke stukken code/algoritmen. Geen "Hello world" of zo). Maar je gaat toch echt wel keihard onderuit als je je vergist in de mate van belangrijkheid van commentaar of documentatie in welke andere vorm dan ook! En je zal niet de eerste zijn. Het verleden heeft uitgewezen dat bepaalde "vooruitstrevende" projecten, na het opleveringsproces, gedurende het onderhoud volledig de soep zijn ingelopen, omdat:
-de code grotendeels niet meer te lezen was
-bepaalde code/algoritmen niet meer te begrijpen was ("waarom hadden we ook al weer daar voor een mutex gekozen?!")
-etc

Wat was het programmeer-gezegde ook al weer? Oh ja: "De documentatie is de code zelf" ......... Yeah right.

[ Voor 0% gewijzigd door Primal op 27-10-2002 16:23 . Reden: Toevoegingen ]

[Soultaker]

Jullie mogen wel documenteren van mij hoor. Ik zeg alleen dat 't bij assembly een vereiste is en bij de meeste andere programmeertalen wat mij betreft niet, omdat de belangrijke zaken, die je zou willen specificeren, al uit de code duidelijk worden. En met alle respect, als ik een goed gestructureerde functie onder ogen krijg, met daarbij de informatie wat de functie precies doet, dan kan ik wel weer achterhalen hoe het werkte.

[Primal]

Soultaker schreef op 27 oktober 2002 @ 16:18:
Jullie mogen wel documenteren van mij hoor.

Ik zeg alleen dat 't bij assembly een vereiste is en bij de meeste andere programmeertalen wat mij betreft niet, omdat de belangrijke zaken, die je zou willen specificeren, al uit de code duidelijk worden.

Hmmmmmmmm.....

En met alle respect, als ik een goed gestructureerde functie onder ogen krijg, met daarbij de informatie

welke informatie dan?

wat de functie precies doet, dan kan ik wel weer achterhalen hoe het werkte.

Ja, dat lukt mij in de meeste gevallen ook nog wel. Maar dat ligt toch echt wel sterk aan de situatie, bijv. om wat voor soort applicatie gaat het. En ik heb het dan dus over algoritmen of andere soort toepassingen (dat je niet alledaags onder je neus krijgt) he, laten we wel even duidelijk zijn.

Tot zover mijn off-topic inbreng

[Apollo_Futurae]

Primal schreef op 27 oktober 2002 @ 16:36:
En ik heb het dan dus over algoritmen of andere soort toepassingen (dat je niet alledaags onder je neus krijgt) he, laten we wel even duidelijk zijn.

ja kom, laten we even duidelijk zijn

[JayTaph]

code:

  mov ax,0x0A000        
  mov es,ax

Dit zou ik uit de putpixel routine halen. Stel je wilt gaan plotten in een backbuffer oid, dan gaat dat niet omdat je putpixel dat niet ondersteund. Verder is het onzinnig om ELKE keer dat je een pixel plot, je segmenten goed te zetten. Dus voor je plot-functie je segment goedzetten (hetzij video-buffer, hetzij backbuffer) en daarna plotten.

code:

  pop bx
  pop cx

Hetzelfde hier, waarom ga je elke keer dat je een pixel plot (320x200videomode is dat al 64000 keer), 2 variabele op de stack zetten, om hem 2 instructies later weer eraf te halen. Laad ze dan direct in de registers voor aanroep van je functie.

code:

  mov si,xmode
  lodsb

Laad ES:SI (dus eigenlijk hardcoded: A000:0001) in AL, you're point beeing?

code:

  mov ax,di
  mov dx,0x01
  or dx,al
  jz gui1
  mov dx,0x02
  or dx,al
  jz gui2
gui1:

Wat staat er in DI? Waarschijnlijk je offset op A000. Daar ga ik dan maar vanuit. Waarom je de bitjes gaat testen snapt niemand vrees ik, maar goed: een even AX (dus bitje 0 = 0), ga je naar gui2, bij een AX deelbaar door 4, ga je naar gui2.

code:

  xor ax,ax
  mul cx,0x0140

Nu gaan we cx imullen met 320 (dit is dus de Y variabele die we willen vermenigvuldigen, om zo de offset te bepalen: X = 1, Y = 2 == offset = 1 + (2 * 320) = 641

Voor de snelheid is het misschien handig om te weten dat 320 bestaat uit 256 + 64. Als je dat nog niks zegt, dan laat maar, dat komt later wel eens een keertje.

code:

  add bx

Add bx bij "iets", dit moet dus AX zijn, aangezien DX:AX de vermenigvuldiging bevat.

code:

  mov si,pixcol 
  lodsb
  mov cx,di
  mov es:ax,cx          ; segment override op AX, kan dat :?
  jmp exit
gui2:
  jmp exit
  exit:
 ret

Dit stukje code gaat nergens over...

code:

@start:
mov ax,0x13         ; Dit is standaard 320x200 (linear, dus geen chain4 of modex, iets wat je param in het begin niet helemaal duidelijk maakt dus 
int 0x10
mov ax,0x012            ; plot op pixel 18
push ax
mov ax,0x012            ; rij 18
push ax
jmp @putpixel

Je gaat *NEVER* naar een subroutine jumpen, tenzij je een goede reden hebt en *NEE* die heb je niet.... CALL @putpixel dus

code:

mov ah, 0x00            ; Wacht op een key
int 0x16

Nou ok... vraag je eerst eens af: WAT wil ik precies, en ga daarna het probleem opdelen.

Jij wilt dus pixels kunnen plotten, daarvoor heb je een buffer nodig waarin je dat wilt, een x coordinaat, een y coordinaat en eventueel een kleur.

code:

; in:  bx = X coordinaat
;      cx = Y coordinaat
;      al = kleur
;      es = segment van buffer
putpixel:
   ; vermenigvuldig cx met 320
   ; tel bx erbij op
   ; sla op in di
   ; plot al in es:di (stosb)
   ret

main:
  mov ax,0x13
  int 0x10      ; set 320x200x256 vga mode
  mov ax, 0xA000    ; plot naar vga buffer
  mov es, ax
  mov bx, 0x10  
  mov cx, 0x10
  mov al, 15        ; witte kleur
  call putpixel
  xor ax,ax
  int 0x16

Met je huidige kennis, neem ik aan dat je de putpixel routine zelf best kunt maken, als je het commentaar volgt die ik je in die routine heb gegeven.