De olika MOVF/FW/FF blir helt enkelt olika adresseringssätt, precis som de oftast är. LOD A,DATA / LOD A,#CONST / LOD DEST,/SOURCE .
Angående relokering och länkning så görs motsvarande genom att .ORginate sätts till startadressen, sedan hanterar de symboliska referenserna alla absoluta adresser. Istället för att länka så kan man .INsert källfile och på det sättet få in et rutinbibliotek. Det som inte används får kommenteras ut manuellt, så en liten nackdel finns där nog.
12-bit tror jag nog får vara, den verkar vara stökig. Bl.a. det som nämndes att subrutiner och hopp intekan ha den övre halvan av en "page" som destination. Det hade varit aaaaaaaaa aaaaaaaaaapa neeeeeeeee till SFR än att använda bitar i statusregistret för de höga adressbitarna.
Det är trist att PIC har tagit den väg de har. En helt ny CPU med riktiga indexerbara adressregister och en vettig stack hade varit ett mycket bättre alternativ. Det som var tänkt som något enkelt och litet har växt bortom den gräns där alla utökningar med femtioelva SFR's o.dyl. har gjort den till ett oöverskådligt och ineffektivt lapptäcke av patchar.
Harwardarkitekturens begränsnngar blir allt mera märkbara och alla speciallösningar för att hantera långa adresser allt mera irriterande. Bredare instruktioner hade nog kunnat göra nytta, men knappast kostnadseffektivt med många don¨t care bits om det nu är antalet minnesceller som är en avgörande kostnadsfaktor.
PIC Disassembler?
Inte för att jag är någon hejare på tidigare nämnda processor-arkitekturer, men är inte anledningen att PIC gör som dom gör, att hålla ner antalet transistorer i kretsarna?
Men det är väl kanske som med x86 proccessorerna? På 80-talet började ju motorolas 680xx processorer komma ut, som internt hade en ren 32-bitars arkitektur (68000) fast 16/24-bitars databuss/adressbuss. Ändå envisades de flesta att programmera för PC och intels usla 16-bits segmentering. Skulle du läsa in mer än 64kB i minnet var du tvungen att dela upp datan i segment om 64kB stycket.
Det verkar ofta som de mest tillgänliga och utbredda arkitekturerna vinner, inte de tekniskt mest kompetenta.
Men det är väl kanske som med x86 proccessorerna? På 80-talet började ju motorolas 680xx processorer komma ut, som internt hade en ren 32-bitars arkitektur (68000) fast 16/24-bitars databuss/adressbuss. Ändå envisades de flesta att programmera för PC och intels usla 16-bits segmentering. Skulle du läsa in mer än 64kB i minnet var du tvungen att dela upp datan i segment om 64kB stycket.
Det verkar ofta som de mest tillgänliga och utbredda arkitekturerna vinner, inte de tekniskt mest kompetenta.
8086/88 är inget svagt instruktionsset. Det är tvärt om väldigt välbalanserat tycker jag och en processor som det är lätt att skriva för. Hårdvaran är lite stökig med muxad adress/data och det finns ingen vettig parallellport utan någon annan får användas med anpassningslogik. 8255 är nog den uslaste preiferikrets som nåonsin har gjorts där man inte ens kan konfigurera riktningen på pinnarna individuellt, långt mindre interruptflaggor/enable.
Segmenteringen är inget stort problem, den kan till och med vara en fördel. T.ex. har jag skrivit en länkad texteditor där allokeringsenheten är just ett segemt. En dubellänkad lista slukar då bara 4 byte istället för 8. Vill man göra något med linjär adressering är det ingen stor sak att normalisera adressen. Det är verkligen inte många applikationer som är aktuella för nämnda processor som hanterar data i block större än 64K.
Motorolas processor har jag bara tittat på lite grand, men det förefaller vara ett mera minneslukande instruktionsset.
Segmenteringen är inget stort problem, den kan till och med vara en fördel. T.ex. har jag skrivit en länkad texteditor där allokeringsenheten är just ett segemt. En dubellänkad lista slukar då bara 4 byte istället för 8. Vill man göra något med linjär adressering är det ingen stor sak att normalisera adressen. Det är verkligen inte många applikationer som är aktuella för nämnda processor som hanterar data i block större än 64K.
Motorolas processor har jag bara tittat på lite grand, men det förefaller vara ett mera minneslukande instruktionsset.
Jag menar inte att 8086 var direkt dålig på nåt vis. Den kom ju trots allt före 68k familjen då förutsättningarna var annorlunda. Sedan kom ju "protected mode" med 386 (eller var det redan 286?), däremot tog det ju tid innan all kod renodlades till 32-bit.
Bildbehandling blir lite krånglig med 64k segment. Å andra sidan fanns det ju smärre brister med 68000 också. Som du sa, större instruktioner, dessutom var man tvungen att aligna 16 och 32 bitars minnesåtkomster på jämna ord, annars fick man adress fel vill jag minnas. Däremot hade du 8 dataregister D0-D7 och adressregister A0-A7 som alla hade likvärdig funktionallitet, och en uppsjö med varianter av indirekt addressering.
Nåväl, den igentliga anledningen till att jag skrev nu var att jag var lite nyfiken på vad du skriver din assembler i för språk och på vilken plattform (Windows antar jag) och om den kommer att gå att ladda ner? Isåfall, kan man även ladda ner källkoden? Jag försöker nämligen smälla ihop en egen liten assemblator i C, dock mest för att lära mig lite.
Annars kanske du har några fina länkar om assemblerkonstruktion?
mvh Mats
Bildbehandling blir lite krånglig med 64k segment. Å andra sidan fanns det ju smärre brister med 68000 också. Som du sa, större instruktioner, dessutom var man tvungen att aligna 16 och 32 bitars minnesåtkomster på jämna ord, annars fick man adress fel vill jag minnas. Däremot hade du 8 dataregister D0-D7 och adressregister A0-A7 som alla hade likvärdig funktionallitet, och en uppsjö med varianter av indirekt addressering.
Nåväl, den igentliga anledningen till att jag skrev nu var att jag var lite nyfiken på vad du skriver din assembler i för språk och på vilken plattform (Windows antar jag) och om den kommer att gå att ladda ner? Isåfall, kan man även ladda ner källkoden? Jag försöker nämligen smälla ihop en egen liten assemblator i C, dock mest för att lära mig lite.
Annars kanske du har några fina länkar om assemblerkonstruktion?
mvh Mats
> Nåväl, den igentliga anledningen till att jag skrev nu var att jag var lite nyfiken på vad du skriver din assembler i för språk och på vilken plattform (Windows antar jag)
Den är skriven i assebler givetvis, vad annars?
Första versionen var i TP3, därefter assemblerar den sig själv. Den är skriven för DOS, men fungerar fint i DOS-fönster.
> och om den kommer att gå att ladda ner?
Det är inga hemligheter i den, så det skall väl kunna ordnas.
> Isåfall, kan man även ladda ner källkoden?
Kanske, den är mycket speciell, men om Du kan 6502-assembler så kommer Du att känna igen Dig. Det är den som stått som modell för upplägget.
> Jag försöker nämligen smälla ihop en egen liten assemblator i C, dock mest för att lära mig lite.
Lycka till! Tyvärr har jag inga råd att ge när det gäller C, det är ett språk som jag behärskar ungefär lika bra som kinesiska...
> Annars kanske du har några fina länkar om assemblerkonstruktion?
Känner inte till några, det är helt en egen konstruktion.
Sättet jag har gjort på bygger på att det är ett hanterbart antal adresseringssätt. Till Intel 32-bit skulle det t.ex. inte fungera. Varje adresstyp avkodas till ett nummer och sedan bygger det mesta på tabellmatriser.
Jag har just blivit preliminärt klar med 14-bit PIC och programstorleken är c:a 11.5K Då ingår utöver PIC 65C02 och 8088+V20.
Nu skall den kontrollras manuellt mot databladet, hoppas att det är korrekt. Sedan skall det programmeras en loader och så är det dags att testa på riktigt.
Den är skriven i assebler givetvis, vad annars?
Första versionen var i TP3, därefter assemblerar den sig själv. Den är skriven för DOS, men fungerar fint i DOS-fönster.> och om den kommer att gå att ladda ner?
Det är inga hemligheter i den, så det skall väl kunna ordnas.
> Isåfall, kan man även ladda ner källkoden?
Kanske, den är mycket speciell, men om Du kan 6502-assembler så kommer Du att känna igen Dig. Det är den som stått som modell för upplägget.
> Jag försöker nämligen smälla ihop en egen liten assemblator i C, dock mest för att lära mig lite.
Lycka till! Tyvärr har jag inga råd att ge när det gäller C, det är ett språk som jag behärskar ungefär lika bra som kinesiska...
> Annars kanske du har några fina länkar om assemblerkonstruktion?
Känner inte till några, det är helt en egen konstruktion.
Sättet jag har gjort på bygger på att det är ett hanterbart antal adresseringssätt. Till Intel 32-bit skulle det t.ex. inte fungera. Varje adresstyp avkodas till ett nummer och sedan bygger det mesta på tabellmatriser.
Jag har just blivit preliminärt klar med 14-bit PIC och programstorleken är c:a 11.5K Då ingår utöver PIC 65C02 och 8088+V20.
Nu skall den kontrollras manuellt mot databladet, hoppas att det är korrekt. Sedan skall det programmeras en loader och så är det dags att testa på riktigt.
