Normalt att det blir bugg om man anropar funktion i funktion

[TomasL]

Makron och vilkorsstyrd assemblering är inte assembler, utan verktyg som assemblatorn ger dig, för att underlätta livet.
Ja du kan översätta till exempelvis C till assembler, men aldrig assembler till C, du får inte tillbaka det ursprungliga programmet.
I assembler får du alltid det ursprungliga programmet, i alla lägen.
Naturligtvis inte makron som du skriver in till din assemblator, dessutom är makrona specifika för just den assemblatorn du använder.

[SeniorLemuren]

Suck.

[sodjan]

Kan bara instämma med Lemuren...

[TomasL]

Hmm, ni båda kanske skall läsa på lite:

Assembler eller assemblyspråk är ett sätt att uttrycka maskinkoden för en dators processor på ett sätt som människor kan läsa och skriva. Programmet som översätter assemblyspråk till maskinkod (binärkod) kallas en assemblator. Maskinkod består av mönster av ettor och nollor och är i allmänhet svår för programmerare att använda. Assembler tillåter att bitmönstren istället skrivs med bokstäver och siffror, så kallade mnemnotekniska symboler, vilket väsentligt underlättar programmerarens arbete.

ASM är och förblir maskinspråk enär de Mneonics som används i assembler har en direkt motsvarighet och är fullständigt utbytbar mot maskininstruktionerna.
C/Cobol/FORTRAN osv kan inte direkt översättas till maskininstruktion.

[svanted]

här jämförs äpplen och päron...
assembler i den enklaste formen är bara lättbegripliga förkortningar istf hexkoden, binärkoden, eller vad man nu ämnar att kalla den.
och orden(menmonics) v.s. hexkoden är reversibla...
sen är det väl självklart att maskinkoden inte kan återskapa de finesser en avacerad assembler är baskaffad med, typ alla de exempel sodjan
gav.
typ maskinkoden vet ju inte att programmeraren har använt makron för avsnitt som är identiska...
eller vad han kallat sina variabler för...
vart nu denna diskussion vill ta oss....?...

[TomasL]

Men skillnaden är att detta är funktioner inbyggda i utveklingsverktyget, inte i assemblern, följaktligen tillhör det inte assemblern som sådan.

[danei]

För en gångs skulle håller jag helt med Tomas.
Alla verkar ju veta hur det funkar, men kallar samma sak för lite olika saker. Men jag håller med Tomas syn på saken. Men det viktiga är ju att fatta hur det funkar.

[sodjan]

> C/Cobol/FORTRAN osv kan inte direkt översättas till maskininstruktion.

Det beror på. Det finns/fanns plattformar där mycket av Cobol koden
hade en direkt motsvarighet i maskinarkitekturen. Men sen tillkommer så
klart en hel del i alla språk som ligger utöver den rena maskinkoden (inkl
de allra flesta assemblers idag) som inte har något direkt motsvarighet i
hårdvaran. Jag har redan räknat upp en del och behöver inte ta det igen.

Att man inte kan konvertera tillbaka till C/Cobol/FORTRAN är sant, på samma sätt
som man *inte* kan få tillbaka samma assembler källkod som man startade med.

> vart nu denna diskussion vill ta oss....?...

Nej, jag fattar ärligt talat inte varför vi har denna diskussion över huvudtaget.

> de finesser en avancerad assembler är baskaffad med,

Avancerad och avancerad. Jag skulle säga vilken assembler som helst från de
senaste 10-15 åren. Eller för den delen Macro-32, likadant i över 35 år.
Example: http://labs.hoffmanlabs.com/node/1435
Om man kör det på en Alpha eller Itanium så *kompileras* det dessutom.

> Men skillnaden är att detta är funktioner inbyggda i utveklingsverktyget, inte i assemblern,

Vilket komplett snömos!
Allt det jag gav som exempel ligger i och utförs av assemblern.
T.ex för PIC processorer MPASM. Det finns dokumenterat och
det är bara att läsa på för den intresserade.

[TomasL]

Var hittar du Makrona i listningen över de Mneonics som listas för respektive processor, ingenstans, de finns enbart i IDE'n och har inget med assembler att göra.
Följande är de assemblerinstruktioner som existerar för en PIC18F8722

Kod: Markera allt

ADDWF, ADDWFC, ANDWF, CLRF, COMF, CPFSEQ, CPFSGT, CPFSLT, DECF, DECFSZ, DCFSNZ, INCF, INCFSZ, 
INFSNZ, IORWF, MOVF, MOVFF, MOVWF, MULWF, NEGF, RLCF, RLNCF, RRCF, RRNCF, SETF, SUBFWB, 
SUBWF, SUBWFB, SWAPF, TSTFSZ, XORWF, BCF, BSF, BTFSC, BTFSS, BTG, BC, BN, BNC, BNN, BNOV, 
BNZ, BOV, BRA, BZ, CALL, CLRWDT, DAW, GOTO, NOP, NOP, POP, PUSH, RCALL, RESET, RETFIE, RETLW, 
RETURN, SLEEP, ADDLW, ANDLW, IORLW, LFSR, MOVLB, MOVLW, MULLW, RETLW, SUBLW, XORLW, TBLRD*, 
TBLRD*+, TBLRD*-, TBLRD+*, TBLWT*, TBLWT*+, TBLWT*-, TBLWT+*

Inga andra instruktioner kan användas, att sedan IDE'n kan hitta på saker har liksom inget med Assembler att göra.
Det finns assemblatorer som inte stöder någon form av makron/variabelsubstuitution eller liknande och det finns IDE'n som stöder väldigt mycket.
Att det finns Hårdvaruplattformar som direkt stöder en del instruktioner i COBOL har heller inte något med detta att göra, då plattformen i det läget är utvecklad för att stödja COBOL så effektivt som möjligt.
Dessutom är ASM inget språk, då det saknar allt som ett riktigt språk har.
ASM är och förblir ren maskinkod.

[sodjan]

Processorn hårdvarumanual (datablad) visar självklart enbart det som har med hårdvaran
att göra, inklusive de maskinkods instruktioner som den aktuella akitekturen förstår.

Assembler för PIC är som sagt betydligt mer än enbart det, och det har sin manual:
http://ww1.microchip.com/downloads/en/D ... 33014h.pdf
Där har du if-else-endif, while-endw och andra delar av assemblern som inte direkt har
något med maskinkoden att göra.

Du borde känna till allt detta mycket väl och du har anklagat andra för "trolling",
det här börjar lika något sådant nu. Du vet mycket bättre än vad du skriver.

För övrigt så motsäger du ju dig själv här. *OM* assemblerkoden enbart var en direkt
motsvarighet till maskinkoden, så hade den sannolikt funnits beskriven i databladet.
Att det finns en egen manual talar ju mer för att PIC-assembler är så mycket mer.

[TomasL]

Nej, det du hänvisar till är Microchips IDE och dess funktioner, där assembler är en del av IDE'ts funktioner, preprocessorn är en annan del av dess funktioner, och har inget med ASM att göra. I andra IDE'er kan det se helt annorlunda ut, och till och med saknas. (Den första PIC-ASM-IDE't jag använde saknade detta med makron, fanns enbart variabelsubstitution).

[sodjan]

> Nej, det du hänvisar till är Microchips IDE och dess funktioner, där assembler är en del av IDE'ts funktioner,

Inte alls!
Du kan skriva källkoden i Notepad och köra MPASM.EXE "för hand", om man nu vill det.
Man behöver *inte* använda "Microchips IDE" (MPLAB).

Och jag hänvisade (med länken till MPASM manualen) inte alls till "Microchips IDE",
det är en separata manualer för MPLAB8 och MPLABX.

Eller menar du att en C-kompilator också enbart "är en del av IDE'ts funktioner" ?
Frågan är hur många som håller med om *den* saken.

> preprocessorn är en annan del av dess funktioner, och har inget med ASM att göra.

Och #include har alltså inget med C att göra, det är en del av IDE't?
Hur många köper den definitionen?

Det här blir bara märkligare och märkligare... Är du inte nykter?

[TomasL]

Och #include har alltså inget med C att göra, det är en del av IDE't?

Skillnaden är att Pre-Processorn och dess direktiv finns definierat i C-standarden, och ingår följaktligen i språket.

[sodjan]

På samma sätt som att det ingår i PIC-assembler.
Nä, nu får det vara med dessa idiotier...

[xxargs]

Jag är också inne på Tomas resonemang - en hardcore assembler översätter mnemonics till maskinkod och man kan göra omvänt tillbaka till exakt samma kod som en gång matades in. Det var så man började - först skrev för hand mnemonics och också för hand överfördes till hexadecimal kod via hexadecimalt tangentbord (tidigare så var det oktalt när processorena räknade BCD som en del miniräknar-processorer gjorde).

Det där var förstås tröstlöst arbete och man suktade efter program som kunde automatisera processen och det gjordes försök att skriva program i basic på ABC80 som hjälpte till med detta - tänk på att det var långt före Internettiden eller olika BBS och innan Atari/Amigatiden och spelhackningen med tillbehör (dvs. musik och demo) blev en folksport bland dåtidens nördar och utbytet av kodsnipptes mellan lokalt intresserade var närmast obefintlig i alla fall där jag gick i skolan.

senare så stötte man på macroassemler som var nivån högre - då började man kunna sätta variabler, labels etc. och man kunde börja peta in redan skriven kod utan att behöva räkna om alla hoppadresser igen (för femtioelfte gången) och så småningom även lite smarta preprocessinstruktioner och intruktionssubstition där nyckeord lyfte in hela kodstycken, macro etc. men medförde också att information försvann vid kompileringen som inte kunde fås fram igen genom att köra baklänges på den genererade koden.

Skulle tom. säga lite hårddraget att språket 'C' är egentligen en väldigt avancerad macroassembler där man har dolt de egentliga mnemonics så djupt att man får anstränga sig för att få fram dessa igen via inline-instruktioner etc. men har också macroassemblerns 'farlighet' att man kan göra stora blunder och skriva data på fel ställe utan att kompilatorn varnade om man inte håller tungan rätt i munnen, precis som när man skriver mnemonics i en macroassebler.

För mig är assembler och macroassembler inte samma sak - och jag misstänker att dom flesta som skriver lite slarvigt 'assembler' egentligen menar macroassembler och därför har ordklyveriet när man egentligen pratar om olika 'produkter'


---

folk som idag tänker bli programmerare börjar inte med tomma händer utan väldigt mycket är serverat, när jag började så var det ungefär som om man skulle bli smed så skulle man förts bygga sin hammare, städ, tång och ässja innan man kunde gå vidare med mer avancerade saker... dock får man en ganska bra förståelse hur en microprocessor fungera när man börjar från börja på riktigt och inte blir framcurlad med en komplett utvecklingsmiljö där det fysiska processorns är närmast en tillbehör om man ids göra något utanför den simulerade världen...