Var är det lämpligt att diskutera .asm kod?

[TomasL]

Det var inget svar, det var en fråga. (som TS ännu inte svarat på).

[sodjan]

> Eller kanske det var när sodjan...

Blanda inte in mig i eran lilla penn-fajt...

[Kaggen]

Varför är det så hemskt att anv 1980 talas kod teknik på tex en PC från ca 2000(mina är inte nya)?

Därför att saker och ting inte fungerar så bra då? Det har ju hänt en del under dessa år. Man använder ju inte t.ex samma verktyg som man skodde arbetshästar med på 30-talet när man mekar med traktorer 2012. Det går säkert om man verkligen vill, men känns lite meningslöst. Vad menar du med att använda koden på en PC? Talade vi inte om att porta den till AVR nyss?

Som sagt man använder oftast inte självmodifierande kod p.g.a av implikationer med cachen. Man måste flusha den i så fall och det tar dyrbar tid. Det finns idag också mycket fler register och andra bättre sätt att lösa de flesta problemen som fanns på äldre processorer.

Jag är dock väldigt osäker på om du förstår skillnaden mellan en ren processor/CPU (sådana som oftast användes på 80-talet för samma uppgifter som dagens microcontrollers) och microcontrollers?

En ren processor som t.ex 6502, Z80, 8080 m.fl. har inget inbyggt minne. Det är bara en cpu-kärna. För att CPUn överhuvudtaget skall kunna exekvera ett program måste dess addressbus och databuss kopplas ihop med någon typ av minne som kan innehålla själva exekverbara programkoden. Det kan vara ROM eller RAM. Oftast är det en kombination av dessa eftersom något måste kunna läsa in program i RAM så lade man oftast ett litet program i ROM som kunde läsa från diskenhet, bandenhet eller hålkort m.m. in i RAM minnet och sedan exekvera detta. Det krävdes då naturligtvis både en CPU-krets en ROM krets och en RAM krets plus diverse logiska kretsar för att koppla ihop dessa. Dessutom kretsar / styrlogik för eventuell diskenhet. Skulle du ha serieport så krävdes separat UART krets.

Som du kan ana blir det ganska många kretsar för att få ihop en dator. Skall du dessutom ha AD-omvandlare m.m. så blir det ännu mer kretsar.

Du kan ju se ungefär hur en sådant bygge kan se ut här.

Men utvecklingen gick framåt och det vart möjligt att lägga CPU, flashminne, RAM och EEPROM i samma krets. Det är detta som oftast benämns microcontroller. Dvs du behöver egentligen inga externa kretsar för att köra programkod på en microcontroller. Iomed att du kan flasha programmet direkt in i kretsen behöver du inget separat ROM för uppstart. Du kan dock inte lägga exekverbar kod i RAM på de microcontrollers jag känner till. Du använder RAM enbart för lagring av variabler/data. Programmet är oftast statiskt i falshminnet och om du vill kan du även bränna data du vill spara medans controllern är strömlös i EEPROM. Dessutom på en microcontroller så har du oftast inbyggd AD-omvandlare, PWM, Timers, UART m.m.

Du kan se en fungerande AVR med ganska få komponenter här. Du kan även få färre komponenter om du använder intern oscillator (då slipper du kristallen).

Så för att summera:

* Microcontroller

Fördelar:
. Enkelt att komma igång
. Få komponenter
. Stor community
. Många I/O funktioner
. Stort utbud av utvecklingsverktyg och miljöer.

Nackdelar enligt 1802:
. Kan inte ladda in exekverbar kod i RAM

* "Riktig" CPU

Fördelar enligt 1802:
. Kan köra självmodifierande kod "dirty style" (OBS! Funkar bara på vissa äldre CPU t.ex 6502, Z80, tidiga 68000...)

Nackdelar:
. Komplicerat att komma igång
. Kräver mycket kringkomponenter
. Kräver större kunskap hur "datorer fungerar"
. Färre bra utvecklingsverktyg och miljöer
. Mindre community (men det finns t.ex http://6502.org )
. Dom äldre 8-bitarna är långsammare än moderna microcontrollers.

Jag skulle gå på Icecaps linje om jag skulle köra något mer avancerat, dvs Rasberry PI. eller möjligtvis en MiniITX eller MicroITX med Linux eller liknande. Dvs om ditt projekt skall kunna ladda in och exekvera program i RAM minne.

[TomasL]

Eller PIC32 , den kan köra kod från RAM, återigen, tämligen meningslöst som sagt.

[sodjan]

> Som sagt man använder oftast inte självmodifierande kod p.g.a av implikationer med cachen.

Det är inte huvudorsaken och cachen går att fixa (cache line invalidate).
Det finns säkershetsproblem med skrivrättigheter till exekverbar kod (buffer overflow).
Och som sagt, det finns applikationer som använder självmodifierande kod idag,
i och för sig i en allokerad del av programminnet för detta, men i alla fall. Och visst,
de får göra lite extra instruktioner för att sätta rellevanta "cache lines" saom ogiltiga
men det är en liten nackdel jämfört med den stora fördel det är att bygga maskinkod
on-the-fly för databas operationerna.

> . Kan köra självmodifierande kod "dirty style" (OBS! Funkar bara på vissa äldre CPU t.ex 6502, Z80, tidiga 68000...)

Stämmer alltså inte. Jag ser inte varför det inte går på alla processorer som
har RAM för programminnet. Om OS'et tillåter det.

> Eller PIC32 , den kan köra kod från RAM, återigen, tämligen meningslöst som sagt.

Det behöver det inte vara...

[TomasL]

Nej, det behöver det naturligtvis inte, men det är förmodligen bättre att använda ramminnet till variabler mm, istället för en massa kod.

[1802]

Om det nu är så bra att inte köra mot ram, varför gör en PC det? Skulle vara en dröm att ha operativet i EEPROM = snabbstart. Och RAM i AVR. Men nu är det inte så och jag får anpassa mig till obekvämligheterna.

Söker en c64dtv. Tror den skulle passa till mig som mikrokontroller.

[stekern]

Eller PIC32 , den kan köra kod från RAM, återigen, tämligen meningslöst som sagt.

Varför skulle det vara meningslöst? Det är ganska brukligt att lägga så kallade "hot paths" (som t.ex. interrupts) i RAM,
eftersom det i regel går snabbare att läsa från än flash.

Man kan naturligtvis använda en stack, om det finns någon för att spara temporära variabler och register vid ett subrutinhopp eller interrupt (vilket är det normala vid dessa tillfällen), man kan också spara undan dessa direkt i RAMet, vilket också kan vara normalt vid andra tillfällen.

Om de är temporära variabler som inte hålls i ett register, så ligger de väl ändå redan på stacken...?

Att spara undan saker i stacken, bara för att man har ont om register är nog ingen bra ide, då stacken främst är tänkt för just subrutinhopp, funktionsanrop och interrupt, dessutom tar det oftast mer tid att hålla på att manipulera stacken fram och tillbaka.

Givetvis är det beroende på arkitektur, men det här är i många fall ett helt fel påstående, speciellt på alla klassiska RISC maskiner.
Eftersom du gärna drar upp PIC32, som är MIPS i grunden, kan vi ju titta lite närmare på den. Stackpekaren på MIPS är bara ett
helt vanligt GPR och load/store instruktionerna kan utföra minnesoperationer med en konstant offset gentemot ett register.
Så stackoperationer på MIPS kan utföras utan att behöva manipulera stackpekaren, dvs de är inte mer annorlunda än vilken
minnesoperation som helst. Så hur tänker du att "det oftast tar mer tid att hålla på att manipulera stacken fram och tillbaka"?

[Icecap]

1802: vad skulle du vinna vid att ha "OS" i EEPROM? Det kan inte vara hastighet, detta då CPU'n först måste ladda in programmet från EEPROM innan det kan exekveras.

Vill du ha hastighet från start är det ROM som gäller, den kör direkt. Detta hindrar dock inte behovet av att ställa in alla perifera funktioner, avkänna status där det behövs, ställa variabler i ett känd läge osv.

Vill du ha ett system som startar snabbt ska allt minne vara t.ex. F-RAM, då kan man skippa minnesinitieringen.

I dina planer och önskemål tycker jag mig se en solid brist på kännedom om hur en "dator"egentligen fungerar varför jag skulle rekommendera dig att ta några steg bakåt och börja med att blinka någon LED och förstå hur allt hänger ihop, sedan kan du expandera komplexiteten som du vill.

[TomasL]

Om det nu är så bra att inte köra mot ram, varför gör en PC det? Skulle vara en dröm att ha operativet i EEPROM = snabbstart. Och RAM i AVR. Men nu är det inte så och jag får anpassa mig till obekvämligheterna.

Jo men PC'n exekverar ju från ROM eller snarare EE nu för tiden, BIOSet ligger ju där.
Att inte övriga program ligger i ROM/EE är ju en ren bekvämlighet, då det skulle bli ett helsike att uppgradera/installera nytt.
Alltså är PC'n konstruerad för att köra från RAM.

Varför skulle det vara meningslöst? Det är ganska brukligt att lägga så kallade "hot paths" (som t.ex. interrupts) i RAM,
eftersom det i regel går snabbare att läsa från än flash.

Visst, det är väl en av de få anledningarna, men då vill jag påstå att man valt fel processor, om det blir långsamt att köra från Flash.

Kod: Markera allt

Om de är temporära variabler som inte hålls i ett register, så ligger de väl ändå redan på stacken...?

Inte nödvändigtvis, de kan också ligga i ett schratchpad.

Så hur tänker du att "det oftast tar mer tid att hålla på att manipulera stacken fram och tillbaka"?

Nu tänker jag på de lite enklare processorer som mer eller mindre saknar funktioner för stackpekare.

[stekern]

> Visst, det är väl en av de få anledningarna, men då vill jag påstå att man valt fel processor, om det blir långsamt att köra från Flash.

Vad menar du med det här?
Jag har inga siffror på PIC32, hur snabbt de snurrar gentemot läshastighet mot flash,
men jag utgår från att latensen för en cacherefill från flash är betydligt större än en cachrefill mot RAM.

> Inte nödvändigtvis, de kan också ligga i ett schratchpad.

Iofs, men det hör väl dock inte till vanligheterna att man sparar up scratchpadden på stacken,
möjligtvis att man använder scratchpadden till stackutrymme.

> Nu tänker jag på de lite enklare processorer som mer eller mindre saknar funktioner för stackpekare.

Det var väl AVR det handlade om i frågeställningen, den har mig veterligen push/pop till stacken.
(Den har å andra sidan rätt gott om register, så att man skulle falla kort med register om man
handknackar asm kanske är osannolikt)

[TomasL]

Cashen arbetar inte mot RAM vad jag vet.
Hastigheten på PIC32 Flash är i nuläget 40 MHz.
Nu menade jag inte att spara upp schratchpaden i stacken, en del C-kompilatorer använder säg 10-20 byte RAM för lokala och temporära variabler, vilka då inte hamnar på stacken.

[stekern]

>>>>> Man kan naturligtvis använda en stack, om det finns någon för att spara temporära variabler och register vid ett subrutinhopp eller interrupt (vilket är det normala vid
>>>>> dessa tillfällen), man kan också spara undan dessa direkt i RAMet, vilket också kan vara normalt vid andra tillfällen.

>>>> Om de är temporära variabler som inte hålls i ett register, så ligger de väl ändå redan på stacken...?

>>> Inte nödvändigtvis, de kan också ligga i ett schratchpad.

>> Iofs, men det hör väl dock inte till vanligheterna att man sparar up scratchpadden på stacken,
>> möjligtvis att man använder scratchpadden till stackutrymme.

> Nu menade jag inte att spara upp schratchpaden i stacken, en del C-kompilatorer använder säg 10-20 byte RAM för lokala och temporära variabler, vilka då inte hamnar på stacken.

Varför tog du upp det när vi diskuterar om att spara saker på stacken då för?
Men strunt samma, det var bara en retsam ordmärkning från min sida från allra första början.

> Cashen arbetar inte mot RAM vad jag vet.

Ja, det låter ju rimligt att on-board RAM'et är tillräckligt snabbt för att inte behöva ett cache.
Men det betyder ju bara att skillnaden i latensen blir större.

> Hastigheten på PIC32 Flash är i nuläget 40 MHz.

Ok, ja det är ju rätt kvickt.
Lite googlande säger mig att man max kan köra PIC32 i 80 MHz,
så du har en helt klart en poäng med att fördelen med att lägga saker
i RAM på de är förmodligen ganska försumbar.

[sodjan]

> Om det nu är så bra att inte köra mot ram, varför gör en PC det?

Därför att det är fullständigt normalt på den typen av "datorer".

> Skulle vara en dröm att ha operativet i EEPROM = snabbstart. Och RAM i AVR.

Finns ingen fördel, på den typen av "datorer".

> Men nu är det inte så och jag får anpassa mig till obekvämligheterna.

Du är fullständigt ute och cyklar! Finns inget som är "obekvämt" här.
I alla fall inte just det som du syftar på...

[1802]

Icecap: Ett snabbt omprogrammerbart EEPROM i PC'n. Efter man stängt av finns all info kvar, till nästa uppstart. Inget nytt behöver laddas. Där ändringar behövs görs de. Varför kan inte EEPROM "köra direkt" ? Och vissa delar i ROM, hindrar virus m.m. Eller kanske i EPROM. Detta om PC.

Icecap: Angående AVR. Vad tror du MemBitBlink skall göra? Det skall blinka den LED(med innehållet i hela minnt) som många mikrokontrollers har inbyggd. Och jag har redan testat en färdigskriven kod och ändrat blinkhastighet. Nästa steg är MemBitBlink i AVR assembler.

sodjan: Jag är kanske bara före min tid, när det gäller PC. Och jag är inte ensam om att vilja ha en PC som inte tappar minnet vid avstängning. Min bilradio tappar minnet, för jag har minneskablen urkopplad. Men det finns ju prylar där minnet inte ändras om man inte tvingar dem. Gissa om jag vill ha det i bilradion.

Bios kräver nog nästan ROM i någon form(kanske därför jag gillar MS-dos). Varför inte några steg till? Tex DOS eller linux i (e(e)p)ROM.

Ett annat projekt är att anv OBS "gamla moder kort" som mikrokontroller. Trodde jag behövde modda bios. Men bios autostartar diskett eller hdd. Det löser många av nackdelarna. Jag har en minneskortläsare till IDE, hoppas den kan vara bootbar. Nackdelar: storleken och omständiga nätdelen. Detta behöver nog en egen tråd.