Assembly: Jul med assembler

[efikkan]

Det er moro å se hva du har fått til i assembler, for assembler er noe som sitter mitt hjerte nært. Jeg hadde min periode da jeg skrev mest assembler, jeg laget blant annet en enkel bootloader og en svært enkel kernel som byttet til 32-bit pmode og gav et enkelt tekstbasert menysystem mens jeg gikk på videregående. Flere år senere tok jeg kompilatorteknikk ved NTNU men var dessverre syk mesteparten av semesteret, men klarte å stå alene på hukommelsen fra det jeg gjorde i assembler flere år i forveien Kunnskapen og innsikten jeg har fått fra å lære såpass om prosessorer og minnestrukturer er det viktigste jeg har lært som programmerer, selv om det går mest i C om dagen. Kombinert med det jeg har lært om maskinvarearkitekturer gir det innsikt til å forstå hvordan koden blir utført av CPUen, og f.eks. hvorfor if-else-statements og lignende kan skape unødvendig branching som gjør at prefetcheren til CPUen sliter. Mange er ikke klar over at det er viktig at løkker er enklest mulig slik at CPUen kan pipeline den mer effektivt. Dette ser jeg at utviklere i språk av høyere nivå kan dra stor nytte av, f.eks. ved behandling av teksturer der løkker itererer over hver piksel. Om bare 1% av koden som er mest ytelsekritisk optimaliseres med assembler så kan det gi store ytelsesgevinster.

[LonelyMan]

Ja de som jobber i høyere språk har stor nytte av å forstå lavt nivå. Når de jobber med et prosjekt så tenker de primært kompilatorflagg. Når jeg jobber i høyere språk så tenker jeg layout i programmet, deretter kompilatorflagg, for jeg vet hva som skaper problemer og ikke. Jeg lager en bit kode, så ser jeg på debugvinduet i ide'en, så omstrukturerer jeg koden for å se om den blir bedre osv.

 

Dette med branching er utrolig viktig også og det fins mange måter å eliminere branches på. Jeg har som regel at jeg alltid har den mest brukte branches innerst i loopen og unngå en 50-50 fordeling, om koden hopper 50% til X og 50% til Y så vil ikke branch prediction virke optimalt, da koden din hopper 50-50 til to plasser. Så jeg forsøker å holde de mest brukte hoppene innerst i loopen så forsøker jeg å eliminere alle andre, om det ikke er mulig så kan det hende jeg deler opp loopen i to deler slik at den første delen blir forutsigbar og andre delen også blir forutsigbar, istedet for å ha en stor loop hvor begge er uforutsigbar. Men det avhenger hvor stor loopen er og om det lønner seg. Du har også mange instruksjoner for å eliminere branches, slik som cmov.

Endret 9. januar 2013 av LonelyMan

[LonelyMan]

Vet ikke om noen husker transport tycoon deluxe fra dos dagene, det skal visst være skrevet i assembler.

[efikkan]

Ja det stemmer, Chris Sawyer skrev det aller meste i assembler, en av mine største forbilder. BTW: du må prøve remaken OpenTTD

 

Hvis du er i en situasjon der du må branche (altså tilsvarende if-else if-else if... i C), så har du sikkert oppdaget at rekkefølgen bør ordnes etter sannsynlighet.

[snippsat]

Vet ikke om noen husker transport tycoon deluxe fra dos dagene, det skal visst være skrevet i assembler.

Ja husker transport tycoon godt,det var et veldig bra spill.

 

Det som er litt gøy er spillet lever videre igjennom OpenTTD som nevnt av @efikkan

Ludde som startet OpenTTD gjorde reverse engineer av spillet for og skrive assembly koden over til C.

 

A great problem during 1996 was that TTD had been written in assembly language and was not especially portable.

Ludde contacted Owen Rudge, owner of TT-Forums, in 2003, and explained he was going to reverse engineer the game and convert TTD to C.

A year later Ludde surprisingly presented Owen Rudge with the first release.

Forums were created where people discussed the new incarnation of the game.

Response was positive, and other developers joined Ludde in the project.

Work continues on OpenTTD to this day.

Endret 10. januar 2013 av SNIPPSAT

[efikkan]

Det mest imponerende tekniske aspektet er hvor god ytelsen i TTD var på de gamle maskinene, og det er ingen tvil om dette er knyttet til hvor god assemblykoden var. Selv med mange vinduer oppe fungerte interfacet smertefritt.

[LonelyMan]

Ja og det er jo et ganske detaljrikt spill, i dos dagene var det viktig å utnytte ressursene. Nå som mange deler er hardware aksellerert og maskinene er blitt kraftige kan man fint porte det i et høyere språk og bevare god ytelse men i dos dagene tror jeg det hadde blitt merkbart redusert ytelse om det ikke var skrevet i assembler for der var lite med hardware layers å benytte i dos.

 

EDIT: Jeg er kjent med openTTD, har spilt det i to perioder for et par år tilbake

Endret 10. januar 2013 av LonelyMan

[efikkan]

Ideelt sett burde vel det meste av programvare vært skrevet i assembler, men en mer realistisk løsning vil være å vurdere ytelsegevinst mot utviklingstid og optimalisere de viktigste kodesnuttene, for det er typisk store delere av koden der ytelsen ikke er kritisk.

[Gjest Slettet+9871234]

Det mest imponerende tekniske aspektet er hvor god ytelsen i TTD var på de gamle maskinene, og det er ingen tvil om dette er knyttet til hvor god assemblykoden var. Selv med mange vinduer oppe fungerte interfacet smertefritt.

 

Jeg husker at jeg i midten av 90 årene lekte med med OS II Presentation Manager og kjørte 16 C programmer samtidig uten problemer på en 386 IBM PS II.

 

For øvrig gjorde jeg en jobb for Simula, der jeg fikk Simula for OS II til å kjøre under Presentation Manager.

 

Jeg har kjøpt følgende to bøker:

 

Making Games with Python & Pygame

 

Game Programming With Python

 

hvor den siste har informasjon om hvordan grensesnittet skrives i Python og spillmotoren i C / C++.

 

Noen som vet hvor enkelt det er å kombnere Python og assembly?

Endret 10. januar 2013 av Slettet+9871234

[LonelyMan]

Du kan i det minste importere dll som er skrevet i asm til python, det er det nærmeste jeg vet.

[LonelyMan]

kgun, hva slags spillmotor skal du lage?

[Gjest Slettet+9871234]

Ingen foreløpig.

 

Dette er perifert i forhold til det jeg drvier med. Jeg tar ofte slike bøker med meg på ferie og leser dem der, slik at jeg er oppdatert på nye teknologier.

[LonelyMan]

Jeg synes du er flink på teknologier, du er en teoretiker uten tvil, du skulle egentlig jobbet som prosjektleder av noe slag.

[LonelyMan]

Laget et eksempel på selvpåført cache pollution, kodet med hensikt dog for å se hvor enkelt det er å ødelegge flyten i programmet sitt, det er enda enklere i høynivåspråk. Venstre side viser tiden målt med påført cache pollution, høyre side viser uten cache pollution. Nesten 20% av kjøretiden er mistet. Kjøretid mistet er stabil over flere tester, så om man ikke er obs på hva man gjør er det fort gjort å miste tiden.

 

format PE GUI 4.0
entry start
include "win32a.inc"
macro align value,addr=$
{
 local base,size
 if addr>$
base = addr-size
size = ((base+value-1)/value*value-base)
db size dup 90h
 else
db ((addr+value-1)/value*value-addr) dup 90h
 end if
}
M=1000000
section '.text' code readable executable
;----------------------------------------------------------
align 64,swap.loop
 swap:
	push ebx esi edi
	mov ecx,100*M
	mov edi,[buf]
 .loop:
	mov eax,[edi]
	mov ebx,[edi+4096*1]
	mov esi,[edi+4096*2]
	mov edx,[edi+4096*3]
	mov eax,[edi+4096*4]
	mov ebx,[edi+4096*5]
	mov esi,[edi+4096*6]
	mov edx,[edi+4096*7]
	mov eax,[edi+4096*8]
	sub ecx,1
	jnz .loop
	pop edi esi ebx
	ret
align 64,swap2.loop
 swap2:
	push ebx esi edi
	mov ecx,100*M
	mov edi,[buf]
 .loop:
	mov eax,[edi]
	mov ebx,[edi+4096*1]
	mov esi,[edi+4096*2]
	mov edx,[edi+4096*3]
	mov eax,[edi+4096*4]
	mov ebx,[edi+4096*5]
	mov esi,[edi+4096*6]
	mov edx,[edi+4096*7]
	mov eax,[edi+4096+512*8]
	sub ecx,1
	jnz .loop
	pop edi esi ebx
	ret
 start:
	invoke GlobalAlloc,GMEM_FIXED,M
	mov [buf],eax
	rept 10 {call swap}
	invoke start_timing,0
	call swap
	invoke stop_milli,TRUE
	rept 10 {call swap2}
	invoke start_timing,0
	call swap2
	invoke stop_milli,TRUE
	invoke GlobalFree,[buf]
	invoke  ExitProcess,0
;----------------------------------------------------------
section '.data' data readable writeable
	buf rd 1
;----------------------------------------------------------
section '.idata' import data readable writeable
	library kernel32,'KERNEL32.DLL',\
			user32,'USER32.DLL',\
			timing,'timing.dll'
	include 'api\kernel32.inc'
	include 'api\user32.inc'
	include 'timing.inc'
;----------------------------------------------------------

 

 

[LonelyMan]

Hvorfor det å kunne maskinspråk alltid vil være viktig:

 

1. Kritiske deler av operativsystem skrives fortsatt i ren assembler, inkludert microsoft windows.

 

2. Drivere optimaliseres ved hjelp av assembler.

 

3: Utviklere skriver fortsatt kritiske deler av program i separate dll'er.

 

4: De som utvikler kompilatorer er nødt til å forstå prosessorer, instruksjoner og maskinspråk.

 

5: Anti Virus utviklere er nødt til å forstå maskinspråk.

 

6: Utviklere av debuggere og disassembler verktøy er nødt til å forstå maskinspråk, og debuggere vil vi alltid ha bruk for.

 

7: Utvikling av bootloadere skrives i assembly for de behøver å være veldig kompakte.

 

Så litt om hvorfor assembler alltid vil være nyttig for programmerere.

 

Datamaskinen blir raskere og raskere og raskere hele tiden, og flere og flere sier at vi ikke behøver assembler lengre, og det er jo selvfølgelig feil for hva skjer når maskinvaren blir teknisk bedre og raskere, jo da konkurrerer utviklere om å lage de beste spillene, og hvilke spill blir best, jo det er spill som utnytter hardwaren til fulle. Så dette skjer når hardwaren blir bedre og bedre:

 

1: Hardwaren blir bedre

2: Utviklere utnytter hardwaren til fulle, slik at maskinvaren alltid yter på sitt ytterste, uansett hvor avansert hardwaren blir så lager utviklere software som utnytter alle ressursene til fulle.

3: Utviklere utnytter hardwaren til fulle fordi de konkurrerer om å lage de beste spillene.

4: Å lage et bedre spill krever mer features i spillet, som igjen presser bruken av ressurser til det ytterste.

 

Så uansett hvor avansert og rask hardwaren utvikler seg til å bli, så vil utviklere alltid utnytte alle ressursene ved å lage mer avanserte og intensive spill og programmer på maskinen.

 

Om hardware industrien lager en supermaskin som yter X, la oss si X er 1 trilliard. Javel, så vil software industrien lage programmer som raskt utnytter X (1 trilliard) og maskinen er igjen fullpakket og ingen ressurser er fri.

 

Når nå høynivåspråk presser maskinvaren til fulle og kanskje programmet yter Y=5, så vil det å ta i bruk assembler alltid gjøre at du kan yte Y=5+3 eksempelsvis. Du kan alltid hente X mer ved å bruke assembler.

 

Så lenge maskinvaren alltid ligger under fullt press, vil assembler alltid være nyttig. Og selv om den ikke vil ligge under fullt press, så vil den likevel være nyttig så lenge ikke maskinvaren er på et ekstremt lavt press, hvilket aldri har vært tilfelle i hele datamaskinens historie, så har den alltid vært under full press.

 

-> Maskinvare gir 50 i potensiale.

-> Spill industrien konkurrerer om de beste spillene

-> Spill industrien utnytter 49 av potensialet

-> Maskinvare utvikler og får 90 i potensiale

-> Spill industrien konkurrerer om de beste spillene

-> Spill industrien utnytter 88 av potensialet.

-> Maskinvare utvikler og får 150 i potensiale

-> Spill industrien utnytter 149 av potensialet.

 

Software industrien har aldri nok med ressurser, og da er det alltid mer gevinst å hente ved å bruke assembler.

 

Om software utviklet i høynivå språk ikke klarer å utnytte mer av hardwaren fordi den har nådd peak top av potensialet, så vil assembler for evig og alltid lønne seg.

 

Endret 14. januar 2013 av LonelyMan

[LonelyMan]

Jeg ser både lyst og mørkt på fremtiden ang assembler og andre språk. Det er lyse og mørke sider for begge delene. Det ene problemet for assembler er at det blir bare flere og flere instruksjonssett tilgjengelige, og antall instruksjoner vil en dag bli for mye for en assembler programmerer å håndtere. Det vil ikke bli praktisk lengre, men dette behøver ikke skje om utviklingen gjør at gamlere instruksjoner forsvinner, noe som det gjorde med implementering av x64 så forsvant noen eldre instruksjoner for å gjøre plass for nye. Det andre er om prosessorer blir mer risc like i fremtiden, om det er tilfellet blir jobben for kompilatorer enklere å finne en optimal løsning, og det gjør at behovet for assembler blir mindre. Men om det fortsetter i retningen vi går nå, som er mer cisc like, hvor vi får flere og flere instruksjoner tilgjengelige, så vil kompilatorer slite veldig med å finne den optimale løsningen, hvilket gjør at assembler går motsatt vei, blir mer og mer nyttig.

 

Asm er nisje for programmering, det er sånn det er. Det er en grunn til at IBM ikke orket å programmere mer i asm i gamle dagene, de var dritt lei av det.

 

Et område jeg ser asm som potensiell er i utvikling av programmeringsspråk, modul baserte programmeringsspråk, noe slik som python. Å kode alle deler av et programmeringsspråk i assembler, portabelt på alle major plattformer, og lage store general purpose biblioteker i høyt optimalisert assembler, det kunne gjort opp et spennende nytt programmeringsspråk, hvor alle modulene er assembler. Med alle de raske biblioteker som fins allerede i assembler, og mer enn nok av asm programmerere å plukke fra, så hadde det vært et spennende prosjekt å lage et nytt programmeringsspråk, basert på asm moduler. Kanskje til og med noe basic liknende. Hva kunne vært mer interessant enn å ha et språk som er så enkelt som basic og som er raskere enn c++ og som er portabelt og hvor det ferdige programmet er så lite som et assembler program, 1 KB på det minste. Senere kunne språket bli supplementert med spill moduler, ferdige assembler moduler for AI programmering, pathfinding etc. Super rask basic-style koding med assembler hastighet.

Endret 16. januar 2013 av LonelyMan

[LonelyMan]

Holder for tiden på å lage et pathfinding bibliotek i assembler. Jeg har studert mange algoritmer, noen av disse ser jeg muligheter for høy optimalisering. Jeg har studert A star, Dijkstra, best first search, hpa og jump point search.

 

Jeg har bestemt meg for å gå for en kombinasjon av A* og JPS, da det er en kombinasjon som jeg har stor mulighet for optimalisering. Jeg har allerede utviklet en funksjon for å beregne heuristic kostnad for rette og diagonale bevegelser og optimalisert den til det ytterste. Jeg fikk den på 13 linjer med instruksjoner. Jeg brukte 3 dager på å utvikle disse 13 linjene, men da var jeg varm i hodet (raskt nok iallefall)

 

Om jeg får dette så raskt som jeg har lyst til, så vil det ikke bli noe problem å få solgt det senere, jeg ser at de fleste pathfinding prosjekter der ute er ekstremt trege og det krever endel ressurser i spill.

 

Planen er, når biblioteket er ferdig, skal jeg duplisere modulene til å støtte forskjellige prosessorer og ha en hoved modul som detekterer hvilken modul som bør kjøre på maskinen som bruker i øyeblikket. Så lage en hjelpefil, og så lage en funksjon som automatisk detekterer forskjellige tekniske ting som gjør at den kan kjøre optimalt på alle maskiner.

Endret 18. juli 2013 av LonelyMan

[Gjest Slettet+9871234]

Hvorfor det å kunne maskinspråk alltid vil være viktig:

 

1. Kritiske deler av operativsystem skrives fortsatt i ren assembler, inkludert microsoft windows.

 

2. Drivere optimaliseres ved hjelp av assembler.

 

3: Utviklere skriver fortsatt kritiske deler av program i separate dll'er.

 

4: De som utvikler kompilatorer er nødt til å forstå prosessorer, instruksjoner og maskinspråk.

 

5: Anti Virus utviklere er nødt til å forstå maskinspråk.

 

6: Utviklere av debuggere og disassembler verktøy er nødt til å forstå maskinspråk, og debuggere vil vi alltid ha bruk for.

 

7: Utvikling av bootloadere skrives i assembly for de behøver å være veldig kompakte.

 

Veldig interessant liste. Selv driver jeg for tiden med å optimalisere native videoer for nettet. Der er komprimering uten å tape kvalitet ("lossless compression") svært viktig. Jeg er sikker på at dersom et firma finner en mye bedre komprimerings algorime enn de konkurrentene har, så vil det ha et stort potensiale. Ikke minst på mobile plattformer er minimale video filer viktig. Der har vært liten utvikling på "lossless compression" siden begynnelsen av årtusenskiftet:

 

http://www.webproworld.com/webmaster-forum/threads/129234-Video-software-for-different-needs-conversion-undelete-etc/page2?p=667268&viewfull=1#post667268

 

Og komprimering av store video filer tar tid, så her er der sikkert et marked for gode assembler programmerere.

 

Anti Virus utviklere er nødt til å forstå maskinspråk.

 

Helt enig.

 

Så lenge maskinvaren alltid ligger under fullt press, vil assembler alltid være nyttig. Og selv om den ikke vil ligge under fullt press, så vil den likevel være nyttig så lenge ikke maskinvaren er på et ekstremt lavt press, hvilket aldri har vært tilfelle i hele datamaskinens historie, så har den alltid vært under full press.

Maskinvaren vil alltid ligge under fullt press ettersom en datamaskin har endelig tilstand. Spør dem som arbeider med å finne store primtall. Programmene deres kjøres i uker. Jeg har selv skrevet hovedoppgave i matematisk kaos og fraktal teori. Der får de som ligger i fronten aldri nok datakraft. Man kunne ha titusen prosessorer i paralell og allikevel ville ting gå for sakte. Det samme gjelder dem som tar bilder av universet og lagrer og bearbeider denne informasjonen. De som undersøker hva som skjer med isen på sydpolen har samme problem. Modellene er så komplekse at de har problemer med å finne ut hva som skjer og ikke minst er datakraften en begrensende faktor.

 

Software industrien har aldri nok med ressurser, og da er det alltid mer gevinst å hente ved å bruke assembler.

 

Det vil software industrien som nevnt aldri få.

 

Om software utviklet i høynivå språk ikke klarer å utnytte mer av hardwaren fordi den har nådd peak top av potensialet, så vil assembler for evig og alltid lønne seg.

 

 

Bra argument.

 

Jeg ser både lyst og mørkt på fremtiden ang assembler og andre språk. Det er lyse og mørke sider for begge delene. Det ene problemet for assembler er at det blir bare flere og flere instruksjonssett tilgjengelige, og antall instruksjoner vil en dag bli for mye for en assembler programmerer å håndtere. Det vil ikke bli praktisk lengre, men dette behøver ikke skje om utviklingen gjør at gamlere instruksjoner forsvinner, noe som det gjorde med implementering av x64 så forsvant noen eldre instruksjoner for å gjøre plass for nye. Det andre er om prosessorer blir mer risc like i fremtiden, om det er tilfellet blir jobben for kompilatorer enklere å finne en optimal løsning, og det gjør at behovet for assembler blir mindre. Men om det fortsetter i retningen vi går nå, som er mer cisc like, hvor vi får flere og flere instruksjoner tilgjengelige, så vil kompilatorer slite veldig med å finne den optimale løsningen, hvilket gjør at assembler går motsatt vei, blir mer og mer nyttig.

 

Da jeg drev med dette for en tid tilbake snakket man om en Very Large Instruction Set Computer (VLISC), altså det motsatte av risc. Jeg vet ikke hvordan det gikk med den utviklingen. Som programmerer kjenner du nok til lenkede lister av ulike slag. Skip Lists har vel (uten at jeg kjenner dette i detalj) noe av det samme som VLISC i seg.

 

Asm er nisje for programmering, det er sånn det er. Det er en grunn til at IBM ikke orket å programmere mer i asm i gamle dagene, de var dritt lei av det.

Som økonom vet jeg at der er flere nisjer som er svært så lønnsomme.

 

Et område jeg ser asm som potensiell er i utvikling av programmeringsspråk, modul baserte programmeringsspråk, noe slik som python. Å kode alle deler av et programmeringsspråk i assembler, portabelt på alle major plattformer, og lage store general purpose biblioteker i høyt optimalisert assembler, det kunne gjort opp et spennende nytt programmeringsspråk, hvor alle modulene er assembler. Med alle de raske biblioteker som fins allerede i assembler, og mer enn nok av asm programmerere å plukke fra, så hadde det vært et spennende prosjekt å lage et nytt programmeringsspråk, basert på asm moduler. Kanskje til og med noe basic liknende. Hva kunne vært mer interessant enn å ha et språk som er så enkelt som basic og som er raskere enn c++ og som er portabelt og hvor det ferdige programmet er så lite som et assembler program, 1 KB på det minste. Senere kunne språket bli supplementert med spill moduler, ferdige assembler moduler for AI programmering, pathfinding etc. Super rask basic-style koding med assembler hastighet.

 

Lager du mange nok funksjoner i assembler for kjente prosessorer, så vil nok det gjøre appene som kjører på den prosessoren mer interessante for mange.

 

Glimrende at du følger opp og fortsetter å poste. Det skulle forundre meg om ikke assembly blir viktigere nå med så mange mobile plattformer. Man trenger ikke kode for alle, men for de viktigste prosessorene.

 

Noen lytter til musikk, andre spiller den, atter andre diriger og en liten nisje komponerer musikk. Det siste er definitivt ikke for alle og verden hadde vært mye fattigere uten denne nisjen.

[LonelyMan]

Asm fungerer også utmerket til å utvikle server programvare, da behøver ikke programmet ditt være portabelt, klientene har ingen visshet om hva serveren gjør uansett, så på en server kan du pakke den full med asm programmer uten negative konsekvenser.

 

Jeg fatter og begriper ikke hvordan de klarer å bruke 6 millisekunder på 13 operasjoner i java med jump point search pathfinding. Jeg klarer å registrere 3000 noder på 1.4 mikrosekunder foreløpig. Det er 2,1 millioner noder per millisekund. he-he, helt latterlig hvor tregt ting kan skje i Java. Det er ikke bare latterlig, det er krapylsk latterlig.

 

Men når biblioteket mitt er ferdig, vil tiden gå opp en hel del, for det er mange operasjoner som gjenstår. Målet mitt er å kunne generere 10 tusen paths på under 8 millisekunder da vil prosessoren konsumere omtrent 50% av cpu'en på 60 fps, men normalt itererer man over sektorer, ikke hele bunten i et stort jafs.

Endret 20. juli 2013 av LonelyMan

[LonelyMan]

Jeg har brukt hele dagen på å skrive ned ideer om hvordan jeg kan optimalisere pathfinding koden min. Jeg tror jeg har nærmere 20 ideer foreløpig. En av ideene er at i A star pathfinding så looper man gjennom listen av åpne noder for hver gang man betrakter en ny node for å finne laveste F kostnad. En simpel optimalisering her er å dedikere et 32 bit register til å alltid holde laveste F verdi, slik at jeg slipper å iterere gjennom 200 noder hver gang jeg evaluerer en ny node, for det som er flott med A star pathfinding er at den alltid kjører den mest sannsynlige beste path'en. Om Mappet ikke er altfor komplekst (labyrintaktig, noe som de fleste maps ikke er heller) så er sjansen stor for at jeg får meget stor gevinst ved å dedikere et register til det. (Bare en simpel optimalisering jeg kan bruke)