· Text 750 · w8 · inlagg
VARFÖR har man både -----.OBJ och -----.ABS format
på filerna - varför får man inte -----.ABS direkt från
ASMZ.ABS?
Kan man manuellt editera ----.OBJ - filer och göra dem
till -----.ABS eller tvärt om?
Retro Preservation Workspace
Monitorn
Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.
ASSEMBLER800
35 posts in thread
-
-
· Text 751 · w8 · kommentarOm du har ett väldigt stort program bestående av ett flertal källkodsfiler kan du assemblera en i taget av dessa till en .OBJ-fil. För att sedan få programmet "körklart" slår du ihop dessa .OBJ-filer till EN .ABS-fil. Det är nog inte det lättaste att editera .OBJ-filer manuellt till .ABS eller tvärt om. Men ingenting är omöjligt (nästan)... M.v.h Stefan
-
· Text 754 · w8 · kommentarMan kan ställa sig frågan: -Varför i Jesse namn framställs en objektfil som sedan måste länkas till en exekverbar laddmodul när man t ex kompilerar COBOL-pgm? När det gäller COBOL och andra högnivåspråk (även assembler på större maskiner) så är det på det viset att man kanske vill skriva olika delar i ett programpaket i olika programspråk. Genom att alla kompilatorer och assemblatorer framställer en standardiserad objektkod kan man sedan pussla (länka) ihop dessa objektfiler till en enda jättefil med exekverbar kod i. Varför vill man smälla ihop allt till en jättefil då? Jo, det går mycket fortare. Men får den plats i minnet då? Jo, minnet räcker! Dessutom kan ju knappast ett BASIC-program göra CHAIN till ett COBOL-program. Varför man gjort så här på en ABC800-maskin kan man dock fundera på. Jag vet det inte.
-
· Text 758 · w8 · kommentarVarför man använder tekniken med .OBJ-filer är kanske lite svårt att förstå för gemene man. Det är helt enkelt så att när man programmerar så händer det (ofta!) att man måste göra någon rutin som man har gjort förut. Om man nu har skapat sig ett modulbibliotek så finns den rutinen där, fix och färdig, och bara för länkaren att suga tag i. Ett annat exempel är om man har mycket stora program, och gör en modifiering, så behöver man inte kompilera/assemblera om hela programmet, utan bara den modul ändringen befinner sig i, och sedan länka om det. Mycket smidigt. Kontentan är att vad man förlorar i smidighet när man gör små snuttar tar man igen med råge när man gör större program.
-
· Text 759 · w8 · kommentarJo, det kan vara praktiskt att snabbt kunna länka om ett program så att en "del" av ett större komplex förändras. Men då bör man också kunna länka med DET FÄRDIGA PROGRAMMET och den NYA OBJEKTMODULEN som indata. Man ska alltså inte behöva samla på sig massor av objektfiler. Det är bara fråga om dubbel- lagring av data. I större system kan man ta en laddmodul och länka in en ny version av en "delmodul" som ingår i den stora. Man behöver inte assemblera om hela paketet utan det räcker att assemblera den lilla snutten samt länka in den då framställda lilla objekt- modulen in i den stora laddmodulen. Nu kan man väl inte göra så på en ABC800 så man tvingas samla på sig en massa objektfiler. Om man nu tycker det är effektivare. Men ABC800 är väl inte en sådan dator som man utvecklar större system på.
-
· Text 760 · w8 · kommentarDu får hålla isär den färdiga binärkoden och objektmodulerna! Tänk på att ABS-formatet inte är relokerbart, vilket är ett krav för att man ska kunna göra som du säger. Jag förstår att du inte riktigt inser fördelarna med att använda den här metodiken, jag kan livligt föreställa mig att det är svårt att tänka modulariserat i ABC80-miljö. Stirra dig inte blind på dubbellagring, disketter är billiga.
-
· Text 763 · w8 · kommentarNä, jag befinner mig inte i ABC80-miljö. Jo, det gör jag ju i och för sig men när jag kommenterade dig befann jag mig i en värld med relokerbar kod. Ok, det kan väl kanske vara bra med dubbellagringen då om man bara har en ABC800. På en ABC80 behövs inte det för assembleringen går så snabbt att tiden är försumbar jämfört med lagringsutrymmet. Leve ABC80!
-
· Text 764 · w8 · kommentarASMZ assemblerar också VÄLDIGT snabbt, så det är i sig inget problem, men man törs ju knappt tänka på att editera/assemblera/debugga ett 5000 raders assemblerprogram som var gjort i en klump! Bara editeringen borde ju få datorn att storkna!
-
· Text 765 · w8 · kommentarJo, stora källkodsfiler är svårhanterliga. Jag undviker alltid stora filer. Det är mycket praktiskt att dela upp det hela i mindre källkodsfiler. Tyvärr klarar inte alla assemblatorer att läsa flera infiler i en följd och tolka det som en enda jättefil.
-
· Text 766 · w8 · kommentarPoletten har fortfarande inte trillat ner, hör jag! Det är mer eller mindre vansinnigt att låta assemblern assemblera 5000 rader, oavsett om det är en eller 50 infiler! Det är därför man skapar objektfiler, för att man bara ska behöva assemblera om kanske 100 av dessa rader, om man ändrar något!
-
· Text 767 · w8 · kommentarJo, jag förstår vad du menar. Om jag säger så här då: Synd att man måste samla på sig en massa objektfiler. Datat i dessa finns ju också i källkoden, dvs dubbellagring av data. Men eftersom man inte kan länka om färdiga laddmoduler (exekverbara program, t ex BAC eller ABS) så får man väl stå ut med en massa extrafiler. ABC80 assemblerar snabbt, särskilt om man kan göra det i ett pass. Det funkar på inte allt för stora program. Större filer går också fort. Det som bromsar är tiden det tar att läsa från skiva. Jämför man tiden att tolka en rad med den tid det tar att läsa in en rad från skivan (egentligen den tid det tar att läsa in ett helt block men det görs ju inte för varje rad) så finner man att datorn är snabb och skivmanicken är långsam. Men det vet väl alla redan. På större maskiner är assemblerings- tiden nästan helt försumbar. I stället för att krångla med objektfiler hit och dit offrar man gärna någon minut extra.
-
· Text 768 · w8 · kommentarVitsen med ett bibliotek är att du inte behöver tänka på var och hur respektive 'recept' är skrivet du bara skriver 'punch+ärtsoppa+pannkaka' och så får du en hel middag serverad utan att behöva bekymra dig. Som att gå på resturang Du samlar på dig alla olika recept och stoppar i biblioteket MVH Stefan Gartz
-
· Text 769 · w8 · kommentarVisst, men varför ska man skriva av alla recepten på grekiska och spara både orginalet och kopian? I ABC-världen måste man kanske det för att spara tid. Det går i denna värld fortare att läsa grekiskan än vad det gör att läsa svenskan.
-
· Text 770 · w8 · kommentarDet måste väl bero på om man kan grekiska eller ej?
-
· Text 772 · w8 · kommentarJag skulle väl snarare säga att det som för dig är grekiska för datorn är svenska, vilket förklarar VARFÖR datorn läser grekiska snabbare (med andra ord: den är grek!), och dessutom VARFÖR man bör översätta så mycket som möjligt till grekiska (läs objektkod) för att minska den totala tids- åtgången.
-
· Text 774 · w8 · kommentarJo, maskinen är kanske grek. Men då tiden det tar att översätta svenska till grekiska är försumbar jämfört med den tid det tar att läsa från skiva är inte tidsvinsten så stor. Det är skillnad inuti en CPU, ta t ex språket BASIC. Där kan man tjäna dyrbar tid om man översätter källprogrammet till internspråk i stället för att tolka varje sats vid exekveringen (som den usla PC-BASICen GWBASIC t ex). Ponera att vi har tillgång till obegränsat stort yttre lagringsmedium med en åtkomsttid till datat som är jämförbar med en läsning i datorns RAM (någon sorts framtida superdisk). Skulle det då vara motiverat att spara objektkoden? NEJ! Det finns alltså inget logiskt skäl till att dubbellagra datat. Möjligen ett praktiskt skäl därför att det inte finns några sådana superdiskar. Kanske tänker jag för mycket framåt? Om man bara har en ABC800 (bara och bara, det är inte så lite) så ok då, vill man hålla på med objektkodssamling så får man väl göra det. Jag skulle aldrig göra det!
-
· Text 782 · w8 · kommentarNej, du skulle aldrig göra det, för du är en hempulare som hela tiden vet vad du gör, ponera att du är en av kanske ett par dussin programmerare som håller på med samma projekt. Att inte modularisera i det läget vore helt omöjligt!
-
· Text 783 · w8 · kommentarEn annan sak, du skriver att tiden för själva översättningen är försumbar, då har du aldrig kompilerat ett C-program på kanske tiotusen rader! Jag lovar dig, har man möjlighet att arbeta med objektkod så GÖR man det, av ren självbevarelsedrift!!!
-
-
-
· Text 775 · w8 · kommentarGlöm inte heller bort att det tar tid att skapa en objektkodsfil. Det krävs att denna fil öppnas på skivan, att data skrivs och slutligen att filen stängs. Sedan skall ett länkningssteg återigen öppna filen läsa den samt stänga den. Egentligen var det jag skrev ett dumt argument. Orsaken till att man använder objektkodsfiler överhuvudtaget är ju att man ska kunna skriva ett stort program i olika smådelar med olika programspråk. Så det är bra med objektkodsfiler. Men sådana skall vara temporära tycker jag, så det så!
-
· Text 776 · w8 · kommentarDebatten mellan Benny och Anders om objektkodsfiler vid assemblering synes mig vara ganska tjatig! Om inte andra finner mera intresse i den så föreslår jag att ni fortsätter i brev eller avslutar debatten nu!
-
· Text 779 · w8 · kommentarSkicka den till 'dev/null' alt. 'NUL:'
-
· Text 785 · w8 · kommentarOK, jag avslutar gärna debatten, Anders får gärna hålla på som han vill, det lägger jag mig inte i! Har man aldrig provat på något så saknar man det heller inte.
-
· Text 788 · w8 · kommentarJo, det är kanske dags att avsluta debatten nu. Vi kommer inte längre, vi sitter fast i våra egna små världar. Huvudsaken är ändå att det är kul. Kul att höra andra åsikter och samtidigt veta att man har rätt! Leve ABC80!
-
-
-
-
· Text 780 · w8 · kommentarDum fråga. Hur var det, har vi fått den eller ??
-
· Text 786 · w8 · kommentarNej inte än, men det är inte omöjligt att den kommer, tillsammans med Pascal 800.
-
-
-
-
-
· Text 771 · w8 · kommentarJo, men om du tänker efter så är det en praktiskt dubbellagring! Om du har en eller flera objektmoduler så behöver du ju för den delen inte ha källkodsfilen på samma diskett! En diskett är inte dyr, så kosta på dig att ha källkoderna separat. De behöver du bara ha på en skiva, objekt- filerna (som dessutom är avsevärt mycket mindre än respektive källkodsfil) kan du sprida på hur många du vill. Jag håller med dig om att assembleringstiden relativt sett är mycket kort jämfört med inläsningstiden, men det är ju egentligen bara ytterligare ett argument för att man ska stycka sitt program i mindre snuttar som följdaktligen går fortare att läsa! Jag är nog själv ganska bortskämd som har tillgång till snabba floppys och winchestrar, men jag använde ASMZ redan på den tiden då jag bara hade en DataDisc 82:a!
-
· Text 773 · w8 · kommentarNja, praktisk i den bemärkelsen att man slipper assemblera om en massa kod som redan är assemblerat bara för att ändra en ynka byte. Jag tycker nog ändå att man skall undvika dubbellagring. Om man glömmer uppdatera båda versionerna (dvs både källkod och objektkod) kan man ligga risigt till. Men ok, jag förstår att många tycker att "spara-objektfils-metoden" är bra på en ABC800. På snabbare maskiner bör man nog inte jobba så tycker jag.
-
· Text 777 · w8 · kommentarKan någon förklara vad objektkoder är för något! Jag känner till källkodsfiler till assemblern,pokesatsprogram och lagring av maskinkod i strängar eller i "CHAIN"-rader till ABC80. Hur fungerar objektkoderna,måste man inte assemblera om hela källkoden när man gör någon ändring? Hur fungerar det annars med adressreferenser o.d. när man ändrat något? H/Kjell
-
· Text 784 · w8 · kommentarObjektkoder fungerar olika på olika system, men principen är oftast den- samma överallt. Vad man gör när man har kompilerat/assemblerat sitt program är att man får en objektfil med slutresultatet PLUS en del information som relokeringsdata, globala variabler osv. Sedan tar man och matar en så kallad LÄNKARE eller LADDARE med en eller flera av dessa objektmoduler, länkaren löser sedan ut alla relokerbara referenser och skapar en utfil, som kan vara direkt exekverbar, prombar eller användbar på annat sätt. Om man sedan ändrar en del av sitt program behöver man bara asemblera/ kompilera om den delen, och köra länkarpasset igen. Eftersom objektformatet innehåller relokeringsinformation så klarar länkaren själv av att knyta ihop alla lösa trådar och lägga modulen där den ska vara.
-
· Text 787 · w8 · kommentarHär ser jag en principiell skillnad i våra åsikter. Du anser att objektkodsfiler är till för att man snabbt ska kunna förändra endast en liten del av ett större paket. Jag påstår att objektkodsfiler är påhittade för att man ska kunna skriva olika delar, moduler, i ett stort paket i olika programspråk. Vi är båda överens om att modulprogrammering, uppdelning av programvara i väl definierade mindre enheter med in- och utdata noggrant specifiserade, är det enda raka.
-
· Text 790 · w8 · kommentarUtan att ha följt diskussionen ordentligt dristar jag mig att påstå att objektkodsfiler är något man inte slipper undan men mera sällan har anled- ning att jobba med, det kan vara möjligen tillfälliga prov med någon "modify memory" - funktion i den exekverande datorn, hittar man då något bättre så blir det att assemblera och länka om. På så sätt kan man slippa assemblera och länka ett nytt prov i onödan. Modulprogrammering tycks inte ha med detta att göra alls. Det är lätt att blanda ihop de olika nivåerna.
-
· Text 792 · w8 · kommentarDet är helt riktigt att modulprogrammering egentligen inte alls har med objektfiler/moduler att göra, men man använder ofta det ena för att uppnå det andra, då man får en naturlig uppdelning i moduler i och med att man delar källkoden på flera filer.
-
-
-
· Text 789 · w8 · kommentarOch ofta har datorn som ska exekvera en hel del "biblioteksrutiner" i sin monitor som man anropar med resp. namn vilka omvandlas till resp. startadress av länkaren. (Rutinerna avslutas med return) Det kan vara rutiner för utskrift på skärmen av datasatser i källkoden eller inväntande av tecken från tangentbordet osv. Ja, allt det där blir "objektkod"; helt klart för exekvering.
-
-
-
· Text 781 · w8 · kommentarDet är just på snabbare maskiner man har störst behållning av att arbeta objektorienterat! Om du t ex har kört på något UNIX-system så har du säkert funnit ett program som heter 'make'. Det är ett program som är till för att på ett enkelt och smidigt sätt underhålla källkods- och objektkodsfiler, baserat på vilken av filerna som är den nyaste. Har man make räcker det med ett enda kommando ('make program', t ex) för att få ett helt programsystem, oavsett storlek och komplexitet, up-to-date.
-
-
· Text 778 · w8 · kommentarOm man tycker sig ha nyttat av objketmoduler eller inte, beror snarast på vad som kostar på aktuell maskin: lagringsmedia eller CPU-användning. Läs: OM man har en maskin med slö CPU (som ABC-maskinerna) och billigt lagringsmedia (floppies, band, disk) har man ju ingen anledning att göra om en massa kompileringar i onödan. Det är särskilt tråkigt att behöva kompilera om runtimen *varje* gång man vill testa nåt litet program :-( Skulle man däremot ha en snabb maskin (Cray-X/MP) med slött media (hålkort av platina) kan man ev. vilja minimera sekundärminnesanvändningen.. (fast jag kan då inte komma på någon som skulle vara i *DEN* situationen :->) Alltså: dubbellagring, användning av objekts-filer och -bibliotek är en *nödvändig* och *trevlig* ingrediens i riktig programmering.
-
-
-
-
-
-
-
-
-
-
-