bankad PIC

[Ulf]

>"Applies to all intermodule callable interfaces in the native software system.
Specifically, the standard considers the requirements of important compiled
languages including Ada, BASIC, Bliss, C, C++, COBOL, Fortran, Pascal,
LISP, PL/I, and calls to the operating system and library procedures."

Eftersom LISP är lite småperverst, så kom jag att även tänka på Prolog, bara för att... !

Visst vore det kul att kunna koda PIC eller AVR i något av dessa språk!

Men kanske inte så nyttigt eller effektivt... .

[sodjan]

OK.
Jag vet inte riktigt var citatet kommer från eller vad kopplingen är
till något jag skrev i tråden. Skit samma...

[Ulf]

Det är ett citat som du har i ditt inlägg 13.36 2007-10-28... . Iofs ett tag sedan... .

[sodjan]

Jahaja, ja tråden gjore visst ett upphåll på nästan 2 månader, inte fasen
kommer man ihåg vad man skrev då !

Och jag tyckte väl att det kom från manualen till "Calling standard" för OpenVMS...

[TomasL]

Men det måste väl ändå vara en "jäkla" skillnad att skriva program för ett OS som OpenVMS Jämfört med hårdvara utan OS.

Finns det ett OS så "Måste" man följa den standarden som OS-Konstruktören bestämt, annars går det åt h-e.

Samma gäller om man skall implementera assembler i C-Kod, då måste man ta reda på vad C-Kompilatorn hittar på, gäller iofs alla språk där minne allokeras per automatik.

Skriver man i ren assembler och inte har tänkt sig att blanda in något programspråk, så har det överhuvudtaget ingen som helst betydelse, MEN, det underlättar nog om man försöker använda/skapa nån form av standard hur minne skall allokeras.

Men åter till ursprungliga frågan.
Bankningen i PIC är väl både pga rent historiskt konstruktion samt att man sparar OPkodkisel då instruktionerna blir kortare (färre bitar per instruktion).

Sedan vet jag inte om andra rykten spelar in, läste nånstans (kommer inte ihåg var) om att PICarnas OP-Koder egenteligen inte är maskin-kod utan istället microkod som i sig av kodas till maskinkod (typ nuvarnade X86, som egenteligen är RISCare med x86 Microkod), därav orsaken till att det tar 4 Tcy för att exekvera en instruktion, till skillnad från en processor med maskinkod, där det typiskt tar 1-2 Tcy per instruktion.

[sodjan]

Självklart, ingen har sagt något annat. Jag tror att samanhanget framgår
om man kollar hela tråden kring mitt inlägg.

Visst har "bankningen" historiska orsaker. Dels för att spara instruktionslängd,
men även p.g.a av tidiga PICs inte hade banker alls. Titta t.ex på 12F508
som hör till de äldsta modellena i dag, så har den alla register och allt RAM
i enbart *1* bank. När sedan senare modeller fick utökat minne så var väl
banker och bank-switch-bitar en naturlig "lösning" på det.

Så instruktionslägden var sannolikt "lagom" från början, men blev "för kort"
med tiden. Därav utvecklingen från 12-bitar över 14-bitar till 16-bitar i PIC18.

Sen tror jag inte att det är rellevant att tala om "maskinkod" v.s "mikrokod"
på processorer av denna storlek, det behöver sannolikt vara lite mer
komplext för att det ska vara någon mening med det (och för att det ska
finnas någon praktiskt skillnad).

Om en instruktion kör på 1, 2, eller 4 Tosc (inte Tcy, vilket = 4 Tosc) har
nog mer med den faktiska designen att göra.

> Skriver man i ren assembler och inte har tänkt sig att blanda in något programspråk,

Assembler *ÄR* ett av möjliga "programspråk".

[TomasL]

Assembler *ÄR* ett av möjliga "programspråk".

Enligt de flesta definitioner

A programming language is an artificial language that can be used to control the behavior of a machine, particularly a computer. Programming languages, like human languages, are defined through the use of syntactic and semantic rules, to determine structure and meaning respectively.

Assembler uppfyller inga definitioner av ett språk, då det saknar syntax, semantiska regler osv.
Assemembler är en direkt översättning av maskinspråket enbart för att det är lättare att läsa mneonics än Hex/bin instuktioner och lättare att skriva än hela namnet på instructionen (dvs en förkortning av instruktionens namn).
En assemblator kör ingen koll på att en kodrad är någorlunda korrekt, enbart att den är "rättstavad", dvs mneonicen finns.

[sodjan]

> ...då det saknar syntax, semantiska regler osv.

Men,... Äh, skit samma...

[Icecap]

TomasL: "En assemblator kör ingen koll på att en kodrad är någorlunda korrekt, enbart att den är "rättstavad"..."

Och det gör t.ex. C???

C gör precis som ASM: vad den får besked på att göra och man kan klanta sig lika mycket i C som i ASM utan att kompilern gnäller.