Anders lagar en gammal dator (-relaterad pryl)

[HUGGBÄVERN]

Intressant sidospår, MiaM.

Det har någon gång nämnts Signetics processor 2650 som skiljer sig lite, men jag stannar vid att nämna den igen utan att fundera över varför den var så bra/annorlunda.

[MiaM]

Ett sidospår på detta sidospår, som faktiskt kan vara relevant för tråden, är att i 26xx-serien förekom det också UARTs som inte behöver initialiseras av processor. Dessa är lämpliga för att t.ex. bygga omvandlare mellan parallellt och seriellt direkt i hårdvara utan att behöva någon processor. Reservation för att jag blandar ihop beteckningarna.

[bqt]

Detta påminner mig också att flera processorer har i mitt tycke helt onödiga instruktioner avsedda för att underlätta för hjärndöda kompilatorer. Tänker på detta med "baspekare" i Intel x86, som är ett sätt för kompilatorn att använda stacken utan att behöva ha koll på hur stackpekaren påverkas av de instruktioner som kompilatorn själv genererar. Jag undrar lite hur Intel tänkte när de la till denna funktionalitet, för även om man kör ett system med en eller två trötta floppydrives och ganska begränsat med minne (men mer än de knappt 64k man kan köra på äldre 8-bit-system utan bankswitchning - annars är det ju ingen mening att köra x86) så lär väl kompileringen inte bli nämnvärt plågsammare om kompilatorn måste hålla reda på stackpekaren mer noga.

Motorola har om jag minns rätt nån slags snarlika instruktioner i 68k och/eller 6809.

Skulle vilja påstå att instruktioner som enbart används av kompilatorer och för assemblerkod som ska köras ihop med kod från kompilatorer är en eftergift för dåliga kompilatorer.
Givetvis undantag för dagens processorer med olika former av optimeringar (pipeline osv) som är svår att hålla reda på för den som skriver assembler för hand.

Sidospår på detta sidospår: Kan det vara så att dessa instruktioner för "baspekare" osv är framtagna av "kommittéer"?

Hmm. Menar du med baspekare samma sak som på engelska kallas för frame pointer? Isåfall håller jag inte riktigt med. Visst kan kompilatorn hålla reda på vart stackpekaren pekar, och veta vad offseten är vid varje tillfälle för att referera till lokala variabler, osv. Men sitter man och knackar assembler för hand vill man inte hålla reda på sådant, så en frame pointer är väldigt skönt att ha. Så det är mer något som gagnade folk som skrev assembler. Jag är inte ens säker på att nyare arkitekturer har en FP. Folk skriver inte mycket assembler för hand nuförtiden. PDP-11 har det inte, och det kan ibland saknas. Ibland tar jag ett register och använder för det i alla fall. VAX har det, men VAX har ju nästan allt...
Men FP används då även för att kunna göra backtrace och hantera saker vid fel, eftersom du därmed kan poppa av rätt mängd från stacken i din generella felhanterare, som inte har någon aning alls om hur mycket stack en godtycklig funktion använt.

[petertub]

Det är väl ingen hemlighet att t.ex. vax instruktionsset är en kommitteprodukt där allt inklusive köksbänken är inkastad.

T.ex. de s.k. descriptorerna som beskrev parameter antal och typ, vad jag minns läggs de inte ut av
vare sig fortran eller C ( och skulle saktat ned programmen ordentligt om de använts). Det finns en "byte copy"
instruktion som inte användes av C istället en helt vanlig loop lades ut. Vi hade ett speciellt behöv
och gjorde en subrutin som använde denna instruktion och fick en ordentlig uppsnabbnig.

( Vax debugger / performance tracer eller vad det kallades var en utmärkt källa till att hitta flaskhalsar)

Alfa processorn togs fram med vetskap om vad som var viktigt och vad som används.

[bqt]

Jag tror inte VAX var en kommite-produkt (men visst, det var några personer som jobbade fram definitionen ja). Men ja, dom slängde in i princip allt man kan tänka sig.
FORTRAN, liksom i princip alla språk utom C, använder deskriptorer normalt, vad jag vet. Men just det är ju inget som kommer från instruktionssetet, utan från det standardiserade ABI som upprättades med VAX och VMS. Vilket definitivt hade sina poänger med.

Men det finns ett par saker som alltid fövånar mig med VAX, och orsaken till att saker normalt inte använder t.ex. MOVC för att kopiera en array med bytes. Av någon underlig anledning satte man en gräns på 64K för alla sträng-operationer. Ingen aning om varför, då värdena ligger i 32-bitarsregister, och instruktionerna kan interruptas i vilket fall som helst.
Det finns några till sådana där godtyckliga begränsningar som bara stör, och som jag inte kan se alls varför.

Men det finns ju mycket som väldigt sällan används. Ingen orkar göra en kompilator som är komplex nog att verkligen utnyttja allt, och sedan visade det sig att det faktiskt blev snabbare att göra diverse saker med enkla instruktioner än den tid den komplexa instruktionen tog på sig. Så så småningom definierades ju ett subset av instruktionerna som måste vara i själva processorn, och resten är ok att emulera i mjukvara. Och på så vis fick man ned det hela till mer hanterbara storlekar, och kunde snabba upp processorn mer.

Nåja. Allt historia nu. Ingen bygger VAXar sedan många år...

[MiaM]

Den heter base pointer på engelska på x86, och använder (default) stacksegmentet, så avsedd att peka på saker på stacken). BP på 8088/80286 och EBP i 386-läge och högre.

68000's "eftergift till kompilatorer" heter LINK, se t.e.x pdf-sid 28-29 för exempel, och verkar användas för att ett av adressregistren ska kunna agera "baspekare". Den verkar allokera utrymme på stacken, stacka ett registers innehåll och sen ladda det registret med var det utrymme man allokerade börjar. Säkert praktiskt i vissa lägen, men ändå rätt tveksamt.

P.S. allmänt om man skriver assemblerkod så år det väl ofta kod som körs i RAM och som inte behöver gå att köras rekursivt, och då är det smidigast att lagra data invid instruktionerna istället för på stacken, och då bortfaller hela detta med stacken.

Sidospår: Noterbart är också att t.ex. kompilatorn SAS/C för Amiga/68000 (den fanns/finns även för helt andra arkitekturer) kan skicka alla parametrar i register istället för på stacken, givetvis förutsatt att allt ryms i register, och detta ger såklart avsevärt snabbare funktionsanrop. Detta kan också (miss)brukas genom att deklarera en gammal assemblerkod som en funktion som tar parametrar i alla register, så stackar kompilatorn allt som behöver sparas. Perfekt om man t.ex. vill köra gamla demos från en loader skriven i C, för att kunna köra "megademo"-diskar fast från hårddisk istället för megademots hårdkodade diskettladdare

[bqt]

Ok. Då är det frame pointer vi pratar om. På 68000 så är det explicit kallat frame pointer i beskrivningen av LINK-instruktionen.

Som sagt var, det är absolut vital information för att kunna göra en traceback genom en call-stack om man vill se hur man hamnade där man är. Så det är användbart mer än bara som ett enkelt sätt att referera till lokala variabler i en funktion (som du har i din frame). Det gör maskinkod mer läsbar också, men som påpekats - en kompilator kan ju lätt hålla reda på vart saker ligger relativt SP hela tiden med, så det är mer användbart för folk som programmerar i assembler själva.

Vad gäller frågan om att spara på stacken, eller statiskt allokera minne för det som behövs i funktionen - tja. Även utan rekursion kan det ibland kännas bättre att bara stoppa upp sakerna på stacken. Beror ju på flera faktorer. Det kan ju lätt bli mer kostsamt i mängden minne som används om man statiskt allokerar allt. Och även om man inte ha rekursion så kan man ju ha multitrådade saker, och då har du samma problem igen om du inte använder stacken.

I slutändan så beror det på många faktorer, men jag skulle definitivt säga att det finns tillfällen då det verkligen är det vettiga sättet att göra saker på, så det vore ju synd om det inte gick...

[anders_bzn]

Nu är allt som kom med daton i helt och fungerande skick, med ett undantag: remsläsaren. Jag har den inte hemma, så nästa tur till förrådet bilr för att plocka upp den. Men det finns lite mer att göra, jag kommer att skruva i bakplan nummer 2 och bygga en kabelstam för power till det. Jag ska också bygga ett 32K statiskt RAM minne som kommer få sitta i field 1-7 tills jag eventuellt får tag på mer kärnminne. Field 0 är kärnminnet som kom med datorn. Man kunde struntat i det helt, men jag vill ha det i datorn.

IMG_2788.JPG

[Mickecarlsson]

Snyggt

[sommarlov]

Alltså den fronten är en av de snyggaste frontar jag vet. Jag har aldrig ägt eller sett den i person, och jag är inte sugen på att ha hela datorn heller. MEN jag skulle supergärna ha fronten med leds + knappar/brytare. Jag skulle tänka mig att ha den som en dörr/lucka till typ ett skåp/hylla, och sen sätta dit en arduino/esp8266 för att läsa av/styra och sen koppla till mitt home automation. **drömma**

[anders_bzn]

Det går sakta nu. Jag fick satt ihop ett minneslkort till. Det fungerade inte, jag hade klantat mig. Jag hade fått dit en 74LS240 istället för en 74LS540, några 74LS540 har jag såklart inte hemma.

IMG_2801.JPG

Sen byggde jag ihop två mycket korta BC08H kablar. Dessa ska koppla ihop de två bakplanen i 8E. Egentligen ska man ha M935 för att koppla ihop dem, men dessa har jag tyvärr inte. Jag väntar fortfarande på kabeln för att kunna bygga power-kablaget. Jag har kontakterna men jag vill ha rätt färger på kabeln.

IMG_2794.JPG

Jag skulle hellre haft orginalbitarna, men i väntan på att jag kommer över dem (om någonsin) så får jag snällt använda moderna bitar.

[MiaM]

Trams-sidospår: Om man vill feature-creep:a minneskortet så skulle man kunna ha en komplicerad paritetskrets för att "ha nytta av" de annars bortkastade fyra bitarna (det är väl 12-bitars databuss om jag minns rätt?)

Förekommer det andra nytillverkade kort till dessa PDP-burkar? I så fall vore väl ett bättre feature-creep att ha plats för dem på samma kort.

Också: PDP-8 har väl såpass låg klockfrekvens att det skulle gå att göra minnet "dubbelportat", alltså växelvis låta PDP:n och "annat" få tillgång till SRAM-kretsarna. Speciellt med bussbuffertar för alla signaler så är detta nog inte jättekrångligt att lägga till. Vet inte vad som skulle vara lämpligt att lägga till, men kanske nån modern mikrokontroller som kan prata med en modern dator och också läsa/skriva i det delade minnet. Lite som ROMulator för Z80 och 6502, fast för PDP.

Antar att "marknaden" för detta är extremt liten, men om det finns nån som knåpar egna cykelexakta program som gör roliga saker och vill vara säker på att det inte är skillnader mellan riktig hårdvara och emulering så kanske detta kan vara intressant. Eller inte

[anders_bzn]

Jo, det förekommer en del andra nytillverkade kort. De flesta är kopior av befintliga kort.

Det finns en ny implementation av boot-kortet. Bootkortet till 8/E togglar in ett litet program i minnet och startar det. Programmet är definerat i en diodmatris. Den nya versionen har en MCU och inne håller alla kända bootloaders och har en serieport som gör att man kan skicka in vad man vill i minnet. Detta kortet skulle jag vilja feature-crepa så att det kan allt som den riktiga konsolen kan fast över en serieport.

Sen har någon bakat ihop minneskortet med det nya bootkortet, jag hade byggt ett sådant om jag inte hade haft ett tomt PCB till minneskortet. https://so-much-stuff.com/pdp8/32KOmnib ... mnibus.php

Nu kommer inte min maskin kunna boota själv utan jag kommer tillsvidare få knappa in bootloadern varje gång. Tur att den till RK05 bara är två instruktioner...

Sen tror jag att man kan starta om OS/8 om man startar från rätt adress i minnet, men BQT vet!

[anders_bzn]

Idag kom kabeln, men stiften ville inte gå i kontaktblocket. Jag hade beställt fel stift (övre bilden). Man får glädja sig med att crimpningen blev bra.

IMG_2804.JPG

IMG_2805.JPG

[bqt]

Nu kommer inte min maskin kunna boota själv utan jag kommer tillsvidare få knappa in bootloadern varje gång. Tur att den till RK05 bara är två instruktioner...

Sen tror jag att man kan starta om OS/8 om man startar från rätt adress i minnet, men BQT vet!

RK05 bootloader:

30: 6743
31: 5031

Starta på address 30.

För att starta om OS/8: starta på adress 7600. Vilket är en väldigt bekväm adress, eftersom det också råkar vara en op-kod för CLA, vilket är någon som förekommer ganska ofta i program, så den konstanten kan du lätt hitta i existerande kod.
Det är för övrigt dit du hoppar i ditt program när det avslutar med. Ett alternativ är att starta på 7605, om du inte bryr dig om att bevara innehållet i minnet du har just nu. Men detta förutsätter att adress 7600-7777 och 17600-17777 inte har skrivits över.