Assembly: Assembly fremfor C++?

[Tr1llobite]

assembler ER vanskelig, men da det kommer til bruk av biblioteker (f.eks. windows programmering) er kallene de samme. Er bare litt mer tunvtvint å bruke dem.

LITT?

Med MASM er det kanskje aktuelt, men hvis du skal unngå macro-dritet i FASM og NASM, så blir det vanskelig.

[GeirGrusom]

Saken er den at C++ compilere legger til ting i begynnelsen av koden. Noen mener det er viktig, men det gjør ikke jeg.

Gud vet hva alt sammen er.

 

Eksempel:

 

Et enkelt hello world med printf i Microsoft Visual C++ (assembly kode)

 

; Listing generated by Microsoft (R) Optimizing Compiler Version 13.10.3077 

TITLE	.\test_write.cpp
.386P
include listing.inc
if @Version gt 510
.model FLAT
else
_TEXT	SEGMENT PARA USE32 PUBLIC 'CODE'
_TEXT	ENDS
_DATA	SEGMENT DWORD USE32 PUBLIC 'DATA'
_DATA	ENDS
CONST	SEGMENT DWORD USE32 PUBLIC 'CONST'
CONST	ENDS
_BSS	SEGMENT DWORD USE32 PUBLIC 'BSS'
_BSS	ENDS
$$SYMBOLS	SEGMENT BYTE USE32 'DEBSYM'
$$SYMBOLS	ENDS
$$TYPES	SEGMENT BYTE USE32 'DEBTYP'
$$TYPES	ENDS
_TLS	SEGMENT DWORD USE32 PUBLIC 'TLS'
_TLS	ENDS
;	COMDAT ??_C@_0BF@CJFBIMLN@Hallo?5p?e?5deg?5verden?$CB?$AA@
CONST	SEGMENT DWORD USE32 PUBLIC 'CONST'
CONST	ENDS
xdata$x	SEGMENT DWORD USE32 PUBLIC 'CONST'
xdata$x	ENDS
;	COMDAT _main
_TEXT	SEGMENT PARA USE32 PUBLIC 'CODE'
_TEXT	ENDS
;	COMDAT ?_Psave@?$_Facetptr@V?$ctype@G@std@@@std@@2PBVfacet@locale@2@B
_DATA	SEGMENT DWORD USE32 PUBLIC 'DATA'
_DATA	ENDS
;	COMDAT ?_Psave@?$_Facetptr@V?$ctype@D@std@@@std@@2PBVfacet@locale@2@B
_DATA	SEGMENT DWORD USE32 PUBLIC 'DATA'
_DATA	ENDS
sxdata	SEGMENT DWORD USE32 'SXDATA'
sxdata	ENDS
FLAT	GROUP _DATA, CONST, _BSS
ASSUME	CS: FLAT, DS: FLAT, SS: FLAT
endif

INCLUDELIB LIBCD
INCLUDELIB OLDNAMES

PUBLIC	_main
PUBLIC	??_C@_0BF@CJFBIMLN@Hallo?5p?e?5deg?5verden?$CB?$AA@; `string'
EXTRN	__RTC_InitBase:NEAR
EXTRN	__RTC_Shutdown:NEAR
EXTRN	__RTC_CheckEsp:NEAR
EXTRN	_printf:NEAR
;	COMDAT rtc$IMZ
; File d:\dev\projects\test_write\test_write.cpp
rtc$IMZ	SEGMENT
__RTC_InitBase.rtc$IMZ DD FLAT:__RTC_InitBase
rtc$IMZ	ENDS
;	COMDAT rtc$TMZ
rtc$TMZ	SEGMENT
__RTC_Shutdown.rtc$TMZ DD FLAT:__RTC_Shutdown
rtc$TMZ	ENDS
;	COMDAT ??_C@_0BF@CJFBIMLN@Hallo?5p?e?5deg?5verden?$CB?$AA@
CONST	SEGMENT
??_C@_0BF@CJFBIMLN@Hallo?5p?e?5deg?5verden?$CB?$AA@ DB 'Hallo p', 0e5H, ' '
DB	'deg verden!', 00H  	; `string'
; Function compile flags: /Odt /RTCsu /ZI
CONST	ENDS
;	COMDAT _main
_TEXT	SEGMENT
_argc$ = 8    	; size = 4
_argv$ = 12    	; size = 4
_main	PROC NEAR    ; COMDAT
; Line 7
push	ebp
mov	ebp, esp
sub	esp, 192  	; 000000c0H
push	ebx
push	esi
push	edi
lea	edi, DWORD PTR [ebp-192]
mov	ecx, 48    ; 00000030H
mov	eax, -858993460  	; ccccccccH
rep stosd
; Line 8
push	OFFSET FLAT:??_C@_0BF@CJFBIMLN@Hallo?5p?e?5deg?5verden?$CB?$AA@
call	_printf
add	esp, 4
; Line 9
xor	eax, eax
; Line 10
pop	edi
pop	esi
pop	ebx
add	esp, 192  	; 000000c0H
cmp	ebp, esp
call	__RTC_CheckEsp
mov	esp, ebp
pop	ebp
ret	0
_main	ENDP
_TEXT	ENDS
END

 

Nå er ikke jeg verdensmester i hverken C++ eller Assembly, men hva er alt det på begynnelsen? jeg har bare et data felt, og det er "Hallo på deg verden!"

[Tr1llobite]

Se her, skrevet av den store Kristoffzor, et hello program i asm:

[ORG 100h]
[BITS 16]

; Hello world example

jmp Start

hellostr: db "Hello, World!", 13, 10, 24h; ASCII, not ASCIIZ...

Start:

mov ah, 9h      ; We want to print text!
mov dx, hellostr; Set dx to the pointer to our string
int 21h          ; Call the default dos interrupt

mov ah, 4Ch      ; We want to exit!
int 21h          ; Call the default dos interrupt

 

Assembly er ikke SÅ vanskelig som mangen tror det er, men det er lett å stå fast innimellom.

Endret 27. juli 2004 av kr1570ffz0r

[GeirGrusom]

Og jeg vil gjerne vite hva .NET runtimen gjør med MSIL som en JVM ikke klarer å gjøre med bytecode, GG.

 

Bytecode må fremdeles bli oversatt til native code, mens .NET allerede er kompilert til native code, og er klar for prosessoren, med mindre programmet blir kjørt på en annen prosessor en det det var kompilert for oprinnelig, for da må .NET kompilere på nytt, men det må JVM også, faktisk må JVM det uansett.

[Frank2004]

Og jeg vil gjerne vite hva .NET runtimen gjør med MSIL som en JVM ikke klarer å gjøre med bytecode, GG.

 

Bytecode må fremdeles bli oversatt til native code, mens .NET allerede er kompilert til native code, og er klar for prosessoren, med mindre programmet blir kjørt på en annen prosessor en det det var kompilert for oprinnelig, for da må .NET kompilere på nytt, men det må JVM også, faktisk må JVM det uansett.

Hmm.. Og hvorfor kan ikke en JVM cache native kode, mener du? Du får sende Sun et brev og forklare, så trekker de kanskje tilbake 1.5..

[GeirGrusom]

JVM kan cache så mye den vil, programmet må bli kompilert første gang den kjøres uansett, hver gang cachen blir flusha.

 

Jeg fatter ikke hvorfor det finnes så mange Java tilhengere

Bare jeg nevner hva som er bra med .NET så kommer hundre Java fundamentalister og maser...

 

Dette er fryktelig off topic...

 

Assembly er bra det, det er bare mye å huske på, og mye å vite om prosessor og operativsystem nåt en bruker det.

Endret 30. juli 2004 av GeirGrusom

[Frank2004]

JVM kan cache så mye den vil, programmet må bli kompilert første gang den kjøres uansett, hver gang cachen blir flusha.

 

Umm.. Så det du mener her:

Det kalles CLR, og er slik fordi det skal la seg kompilere på alle prosessorer (med .NET Framework installert selvsagt)

Ganske lurt egentlig, litt bedre(raskere) en Java Virtual Machine, siden programmet til slutt blir kompilert til native code.

er altså at windows installer kan settes opp til å automatisk pre-jit'e .net-programmer under installasjonen? Og det er jo uendelig mye bedre enn å miste noen sekunder i oppstarten til optimalisering basert på ekte run-time data..

 

Jeg fatter ikke hvorfor det finnes så mange Java tilhengere

Bare jeg nevner hva som er bra med .NET så kommer hundre Java fundamentalister og maser...

Vel, det er ikke jeg som ser meg nødt til å komme med meningsløse/feilaktige påstander for å rakke ned på et språk/miljø jeg ikke vet en dritt om.

 

 

Men dette blir for OT, ja. Får runde av med å si at asm kanskje er 99% meningsløst, men kan være veldig, veldig gøy.

 

Edit: dårlig språk, byttet ut to bokstaver.

 

Og det er nok ikke så veldig mye asm i doom3, tror jeg, selv om id har massevis av kompetanse på området.

Grafikken gjøres vel i for det meste i hardware, men de har kanskje brukt litt simd til fysikk og kollisjonshåndtering..? Også shaders da, som sikkert er skrevet i 'shader-asm'.

Endret 13. august 2004 av Frank2004

[GeirGrusom]

hehe, uff...

Jeg kommer med mye dritt ja...

 

men uansett:

Men dette blir for OT, ja. Får runde av med å si at asm kanskje er 99% meningsløst, men kan være veldig, veldig gøy.

nei nei nei...store deler av Quake er skrevet i MASM, dette gjelder helt sikkert Doom3 også, vet du hvorfor? fordi det du skriver i Assembly er mange ganger raskere en det en robot kan klare klippe og lime sammen.

 

så det så!

der fikk du den!

[Tr1llobite]

hehe, uff...

Jeg kommer med mye dritt ja...

 

men uansett:

Men dette blir for OT, ja. Får runde av med å si at asm kanskje er 99% meningsløst, men kan være veldig, veldig gøy.

nei nei nei...store deler av Quake er skrevet i MASM, dette gjelder helt sikkert Doom3 også, vet du hvorfor? fordi det du skriver i Assembly er mange ganger raskere en det en robot kan klare klippe og lime sammen.

 

så det så!

der fikk du den!

hehe, MASM er jo ikke akkurat det beste da, det ligger i navnet "Microsoft _MACRO_ assembler"

 

Og assembly er 100% nødvendig i denne verden. Trengs til enkelte ting som ikke lar seg gjøre i andre språk... Pluss bootloaders og drivere...

Og ja, det ER gøy med assembly...

[Manuel]

Assembly er ikkr et vanskelig programmeringsspråk tatt i betrakting at instruksjonene vanligvis er svært enkle (det MÅ de være), men det er vanskelig å bruke det fordi man ser koden slik maskinen ser den. Altså ingen fancy IF-setninger (må nøye seg med cmpl og jmp-instruksjoner)

[A_N_K]

Nå må det jo sies at x86 ikke akkurat er en takknemlig plattform å programmere assembly for. Nå har jeg ikke skrevet mye assembly, men det begrensede antallet registeret er ganske kjipt.

[Tr1llobite]

Nå må det jo sies at x86 ikke akkurat er en takknemlig plattform å programmere assembly for. Nå har jeg ikke skrevet mye assembly, men det begrensede antallet registeret er ganske kjipt.

Men det backes opp av 437 instrukser (jeg har laget en liste ovar alle i nasm hjelpefilen), pluss at du må huske at du kan lagre registerene i minnet også.

NASM klarer fint local labels, bare du prefixer labelsene dine med et punktum, blir de lokale, og da kan du lagre registerene i dem. Du kan jo også bruke pusha og popa til å lagre dem.

[A_N_K]

Klart du kan lagre registre i minnet, det er noe av en nødvendighet (spesielt med tanke på at noen instruksjoner fyller visse registre). Er det noen som ser et massivt instruksjonssett som en fordel nå for tiden? Trenden har så vidt jeg vet vært RISC en stund, f.eks PowerPC er kjent som en mer elegant arkitektur enn x86.

[Manuel]

Klart du kan lagre registre i minnet, det er noe av en nødvendighet (spesielt med tanke på at noen instruksjoner fyller visse registre). Er det noen som ser et massivt instruksjonssett som en fordel nå for tiden? Trenden har så vidt jeg vet vært RISC en stund, f.eks PowerPC er kjent som en mer elegant arkitektur enn x86.

Du kan iallfall ikke kalle PowerPC RISC. Faktisk så strider SSE, branch prediction og cache med alt RISC står for. Hovedsaken er at man implementerer det som ØKER ytelsen - ikke fordi det er "RISC", mens det er "CISC".

[A_N_K]

The PowerPC is designed along RISC principles. Jeg ser ikke helt hva SSE (fins ikke i PPC), branch prediction og cache har med Reduced Instruction Set Computing å gjøre sant å si. Javisst betyr en vektorenhet ekstra instruksjoner, men det kommer man knapt utenom.

[Manuel]

The PowerPC is designed along RISC principles. Jeg ser ikke helt hva SSE (fins ikke i PPC), branch prediction og cache har med Reduced Instruction Set Computing å gjøre sant å si. Javisst betyr en vektorenhet ekstra instruksjoner, men det kommer man knapt utenom.

RISC er et misbrukt uttrykk. Hvis PowerPC er RISC, er hverken p4, athlon eller noen andre x86-implementeringer CISC.

 

I grunn sier RISC deg at brikken skal være så enkel som mulig. Ergo: Branch prediction øker antallet transistorer betraktelig. Det samme gjør SIMD (ikke SSE som" jeg kom til å skade å skrive). Det hele koker ned til hva man velger å kalle "redusert", og ikke en fast standard (og da er iallfall PowerPC mer CISC enn noengang. For meg er PowerPC like lite RISC, som x86 er CISC.

 

edit: Da er K7 RISC!

Endret 26. august 2004 av Manuel

[A_N_K]

Jeg foreslår at du leser wikipedias forklaring av RISC også. Det er mulig at du har din faste oppfatning av hva RISC er og hva som ikke er det, men jeg mener wikipedia stemmer bra med hva jeg har hørt/lært.

 

RISC er ikke en arkitektur, men en designfilosofi. Kjennetegnet så vidt jeg kan se, er forenklede instruksjoner som er ment å utføre én operasjon i motsetning til tidligere arkitekturer hvor man implementerte en rekke komplekse instruksjoner for bedre ytelse. Ifølge wikipedia fører nettopp den forenklede kjernelogikken til at det blir mer plass til superskalare enheter (SIMD) osv. Jeg ser virkelig ikke hva det totale antallet transistorer har med RISC å gjøre:

uniform instruction encoding (e.g. the op-code is always in the same bit positions in each instruction, which is always one word long), which allows faster decoding;

a homogenous register set, allowing any register to be used in any context and simplifying compiler design (although there are almost always separate integer and floating point register files);

simple addressing modes (complex addressing modes are replaced by sequences of simple arithmetic instructions);

few data types supported in hardware (for example, some CISC machines had instructions for dealing with byte strings. Others had support for polynomials and complex numbers. Such instructions are unlikely to be found on a RISC machine).

.

X86-prosessorer dekoder jo også det opprinnelige instruksjonssettet til et RISC-sett nå for tiden, finner vi noe slikt i PPC? Det er sikkert mulig du har rett i at RISC/CISC er misvisende, men det som har noe å si er den betydningen disse betegnelsene har historisk sett.

 

Edit: Kanskje du kan forklare rent konkret hvorfor PPC (eller POWER for den del) ikke er RISC?

Endret 26. august 2004 av A_N_K

[GeirGrusom]

Det er egentlig ganske irriterende i I386 at instruksjonene kan ta alt fra 1-4 bytes, istedet for bare et WORD.

 

FNOP(D9D0) tar faktisk to bytes, mens NOP(90) tar en, men begge "instruksjonene" gjør akkurat det samme... dette er ekte CISC designfilosofi.

[Manuel]

Jeg foreslår at du leser wikipedias forklaring av RISC også. Det er mulig at du har din faste oppfatning av hva RISC er og hva som ikke er det, men jeg mener wikipedia stemmer bra med hva jeg har hørt/lært.

Jeg trenger virkelig ikke å lese noen annen sin mening på hva det svært så relative begrepet "reduced" betyr. Det eneste objektive man får ut av det er hvordan instruksjonene tradisjonelt sett "faller" gjennom pipelinen til CPU'en på tradisjonelle (*helt* rene) CISC og RISC-designede prosessorer.

 

RISC er ikke en arkitektur, men en designfilosofi. Kjennetegnet så vidt jeg kan se, er forenklede instruksjoner som er ment å utføre én operasjon i motsetning til tidligere arkitekturer hvor man implementerte en rekke komplekse instruksjoner for bedre ytelse.

Takk for den. Det er det jeg har prøvd å fortelle. Man kan ikke lese en bok, for å så vite hva som er RISC på samme måte som man kan med f.eks x86 og IA-64.

RISC vs- CISC er etter min mening upassende å diskutere i 2004, da ingen av dagens mainstream CPU'er bruker elementer KUN etter den ène designifilosofien.

 

Derimot, i tradisjonen hadde CISC som formål å spare minne. Ved å bruke komplekse instruksjoner sparte man på kostbart minne, såvel som sparte programmereren for kjedelig skriving. Ulempen er som skrevet, at man med CISC-instruksjoner i mye mindre grad kan drive effektiv Out-of-order fòring av akskeveringsenhetene/back-end'en. RISC er det stikk motsatte: Flere "små" instruksjoner (man oppdaget f.eks at nesten alle instruksjonene var mov og add) gjør kretsene enklere å produsere og (i fremtiden) enklere å "stokke om" på instruksjonene i sanntid (CPU'en har jo som kjent bare et lite "kikkehull" ut mot koden, hvis vi ser bort i fra EPIC-design som Itanium). Isolert sett, samt sett at ingen av designfilosofiene får lov til å "låne" idèer fra hverandre vil nok RISC, sett med dagens øyne og minnepriser, komme best ut ytelsesmessig.

 

Ifølge wikipedia fører nettopp den forenklede kjernelogikken til at det blir mer plass til superskalare enheter (SIMD) osv.

Det der er egentlig en selvmotsigelse...

 

Jeg ser virkelig ikke hva det totale antallet transistorer har med RISC å gjøre

Vel. x86-CPU'er er kjent for å ha svært mange transistorer, men ingen av dem er like jævlige som den "RISCeste av de RISCeste": G5! Makan til beist skal man lete lenge etter.

 

uniform instruction encoding (e.g. the op-code is always in the same bit positions in each instruction, which is always one word long), which allows faster decoding;

Greit nok. Skal ikke nekte for det. x86-CPU'er bruker et par steg på "instructuion decoding" til mikroinstruksjoner.

 

a homogenous register set, allowing any register to be used in any context and simplifying compiler design (although there are almost always separate integer and floating point register files)

x86 sine registre har blitt mye, mye mer "generel purpose" enn de var på 80-tallet. Kompleksiteten som lå i kompilatoren blir dyttet over på programmereren.

 

simple addressing modes (complex addressing modes are replaced by sequences of simple arithmetic instructions);

powerpc har vel støtte for tre operatorer i mov-instruksjoner?

 

few data types supported in hardware (for example, some CISC machines had instructions for dealing with byte strings. Others had support for polynomials and complex numbers. Such instructions are unlikely to be found on a RISC machine).

Nå har jeg ikke studert hva slags kode kompilatoren genererer, men det er nok ikke uten grunn at raskere kode ofte er synonymt med større kode (flere instruksjoner). Jeg har inntrykk av at endel x86-instruksjoner bare er med på lasset av "legacy-purposes", selv om de brukes sjelden.

 

X86-prosessorer dekoder jo også det opprinnelige instruksjonssettet til et RISC-sett nå for tiden, finner vi noe slikt i PPC?

Jepp. Man har funnet ut at det lønner seg mht. ytelsen på samme måte som det kan lønne seg å komplisere en prosessordesign.

 

Det er sikkert mulig du har rett i at RISC/CISC er misvisende, men det som har noe å si er den betydningen disse betegnelsene har historisk sett.

Som sagt

 

Edit: Kanskje du kan forklare rent konkret hvorfor PPC (eller POWER for den del) ikke er RISC?

Skal gjerne ta en kikk på pipelinen engang jeg får tid (sliter med "brukervennligheten" i Windows). Imens kan du se sammenhengen mellom dette sitatet og det du skrev rett ovenfor.

[A_N_K]

Jeg er ikke så interessert i å trekke denne diskusjonen ut i langdrag ... dette får bli mitt endelige svar.

Jeg trenger virkelig ikke å lese noen annen sin mening på hva det svært så relative begrepet "reduced" betyr.

Poenget er at RISC er en historisk betegnelse knyttet til en viss designfilosifi. No if's or but's about it. F.eks står R'en i IBM POWER (PPC er basert på denne) for RISC. Hvis du er uenig i den gjengse oppfatningen, er det din sak.

RISC vs- CISC er etter min mening upassende å diskutere i 2004, da ingen av dagens mainstream CPU'er bruker elementer KUN etter den ène designifilosofien.

X86 er en legacy-arkitektur som har kjennetegn som forbindes med CISC (igjen, bare en betegnelse).

Vel. x86-CPU'er er kjent for å ha svært mange transistorer, men ingen av dem er like jævlige som den "RISCeste av de RISCeste": G5! Makan til beist skal man lete lenge etter.

Mitt poeng var at, meg bekjent, går ikke RISC ut på mange transistorer en CPU har. Men en bonus med forenklede instruksjoner er gjerne at antallet transistorer reduseres:

The long and short of it is that for any given level of general performance, a RISC chip will typically have many fewer transistors dedicated to the core logic.

Den ekstra plassen kan man så benytte til f.eks superskalare enheter.

Nå har jeg ikke studert hva slags kode kompilatoren genererer, men det er nok ikke uten grunn at raskere kode ofte er synonymt med større kode (flere instruksjoner). Jeg har inntrykk av at endel x86-instruksjoner bare er med på lasset av "legacy-purposes", selv om de brukes sjelden.

De er likefullt del av X86-designen.

X86-prosessorer dekoder jo også det opprinnelige instruksjonssettet til et RISC-sett nå for tiden, finner vi noe slikt i PPC?

Jepp. Man har funnet ut at det lønner seg mht. ytelsen på samme måte som det kan lønne seg å komplisere en prosessordesign.

Men finner du dette i PPC, dette virker definitivt som en konsekvens av at den opprinnelige (CISC) designen kunne vært bedre.

Edit: Kanskje du kan forklare rent konkret hvorfor PPC (eller POWER for den del) ikke er RISC?

Skal gjerne ta en kikk på pipelinen engang jeg får tid (sliter med "brukervennligheten" i Windows). Imens kan du se sammenhengen mellom dette sitatet og det du skrev rett ovenfor.

Jeg gikk ut ifra at du hadde et visst grunnlag (utover antall transistorer) da du la fram den opprinnelige påstanden (PPC er ikke RISC).

 

Edit: Fra IBMs beskrivelse av POWER:

POWER is RISC in that most instructions execute in a single cycle and typically perform a single operation (such as loading storage to a register, or storing a register to memory)

Endret 29. august 2004 av A_N_K