Regnecentralens RC-702 Piccolo 40 års jubilæum

Spændende er det at p-code fik en renaissance med Java ... heldigvis fandt man hurtigt ud af at JVM også ville være ukonkurrencedygtig uden JIT compiling til machinecode og løste det problem

P-kode fik faktisk en renæssance allerede i 1991 med Visual Basic. Java kom først i 1995.

Ja, det blev ændret i senere udgaver, og, som du siger, var det nok specifikt Z80-udgaven, der brugte den nemme løsning. Men så vidt jeg husker havde 8086-versionen den begrænsning, at en frame maksimalt kunne være 64kB stor, da der brugtes 16-bit offsets.

Ja, x86 versionen kunne håndtere et kodesegment på 64K, et datasegment på 64K og et stacksegment på 64K. Herudover kunne man allokere på heapen for få adgang til resten. Kode kunne lægges i "overlay" funktioner som under runtime kunne swappes ind fra (floppy) disken sådan at man kunne have mere end 64K kode.

Mht. til UCSD pascal, så var det primært brugen af fortolket p-code der gjorde systemet uendeligt langsomt. Spændende er det at p-code fik en renaissance med Java ... heldigvis fandt man hurtigt ud af at JVM også ville være ukonkurrencedygtig uden JIT compiling til machinecode og løste det problem.

Jeg skal ikke kunne sige hvad Z80 versionen gjorde, men x86 versionen allokerede variable på stakken og alle referencer til lokale variable var relativt til SP (eller nærmere BP). Men ok, Z80 mangler også de effektive stack-relative memory instruktioner der findes på moderne processorer så det giver fin mening der.

Ja, det blev ændret i senere udgaver, og, som du siger, var det nok specifikt Z80-udgaven, der brugte den nemme løsning. Men så vidt jeg husker havde 8086-versionen den begrænsning, at en frame maksimalt kunne være 64kB stor, da der brugtes 16-bit offsets.

Specifikt brugte Compas Pascal shallow binding i stedet for deep binding (som Wirth foreskrev), hvilket gjorde, at programmer, der brugte referenceoverførte parametre ikke altid opførte sig, som de skulle.

Jeg skal ikke kunne sige hvad Z80 versionen gjorde, men x86 versionen allokerede variable på stakken og alle referencer til lokale variable var relativt til SP (eller nærmere BP). Men ok, Z80 mangler også de effektive stack-relative memory instruktioner der findes på moderne processorer så det giver fin mening der.

Deep binding er selvsagt mere effektivt

Rettelse: Shallow binding er mere effektivt.

De tidlige 8" disketter (single sided, single density) havde kun 100kB per disk, og det havde de tidlige 5¼" disketter også.

1.2 MB (600 kB/side) på en 8"

De tidlige 8" disketter (single sided, single density) havde kun 100kB per disk, og det havde de tidlige 5¼" disketter også. Heldigvis steg datatætheden og begge sider blev taget i brug. Jeg fik et 5¼" drev til min BBC Micro, og med DDDS kunne jeg have ca. 400kB, og da jeg fik min Archimedes med 3½" drev, kunne jeg have 1,3MB på en disk. Acorn brugte deres eget filsystem og diskformat, som kunne lagre lidt mere data på en disk end CPM og DOS.

Compas Pascal (aka Poly Pascal aka Blue Label Pascal aka Turbo Pascal) blev udviklet af Anders Hejlsberg og kørte rigtigt fint på Piccoloen.

Den satte dog underviserne på DIKU grå hår i hovedet, for Compas Pascal opførte sig ikke helt som lærebøgerne foreskrev. Specifikt brugte Compas Pascal shallow binding i stedet for deep binding (som Wirth foreskrev), hvilket gjorde, at programmer, der brugte referenceoverførte parametre ikke altid opførte sig, som de skulle. Men shallow binding er mere effektiv end deep binding, så blandt andet derfor kørte Compas Pascal en del hurtigere end f.eks. UCSD Pascal. En anden årsag er, at UCSD Pascal oversatte til P-kode (en stakbaseret virtuel maskine), som blev fortolket.

Shallow binding betyder, at hver variabel har en fast plads i lageret, og når en ny lokal variabel med samme navn erklæres, gemmes den gamles værdi på stakken, og hentes ind igen, når den lokale variabel nedlægges. Ved deep binding lægges alle nye variable øverst på en stak og refereres relativt til staktoppen eller en frame pointer, og ikke-lokale variable skal tilgås via statiske links, som kan betyde to eller flere lagerhentninger. Deep binding er selvsagt mere effektivt (når man ikke har registerallokering, og det har man sjældent på 8-bit processorer), men hvis man har en reference til en variabel, risikerer man, at den, inden man følger referencen, er udskiftet med en anden variabel. Det er specielt et problem i forbindelse med rekursion.

Så vidt jeg husker var der en UCSD Pascal til Piccolo'en. Er ret sikker på at det var den første Pascal compiler jeg brugte i gymnasiet.

Det er skønt, at I arbejder på at holde den regionale computer- og softwarehistorie i hævd, og jeg kan kun opfordre til, at man får sig et virksomhedsmedlemskab.

Vi har som virksomhed meldt os ind, da vi er flere kolleger, der tydeligt kunne huske nogle af de gamle maskiner og softwarepakker fra vores barndom og anerkender, hvordan de har været med til at forme vores interesser og, senere, vores professionelle virke.

Fx var vi nogle, der hygge-hackede på Piccoliner i folkeskolen, imens andre senere var så heldige at få fingrene i en kopi af Turbo Pascal og fik lov at kode en DOS-applikationslauncher til skolens PC'er (store sager). Dertil kommer selvfølgelig utallige andre maskiner og softwarepakker af dansk oprindelse, man har haft fingrene i igennem tiden.

Et shout-out går også til Rolf Ask Clausen, som i 1980'erne skrev en skøn bog om Commodore 64'eren og dens brugerport, hvilken var medvirkende til, at to knejter fra udfordrede familier, en C64 og vores forsøg på at lave en "smart home"-styring kunne vinde en præmie ved Ingeniørens Unge Forskere-konkurrence i slut-90'erne. Dette konsoliderede knejternes oplevelse af, at de kunne blive til noget indenfor feltet - og siden også blev det.

Vi har en rigtig spændende computerhistorie her i landet, som fortjener at blive udforsket og fortalt, så lad os bakke op om Dansk Datahistorisk Forening og hjælpe med at skabe geek-cred til de mænd, kvinder og virksomheder, som hjalp os med at gøre Danmark til en lilleput-stormagt på IT-området, og som har inspireret så mange. ?

Poly Pascal blev markedsført af danske Polydata, som var naive nok til at sælge koden til USAnske Borland, som så markedsførte det under navnet Turbo Pascal.

Men Compas Pascal (aka Poly Pascal aka Blue Label Pascal aka Turbo Pascal) blev udviklet af Anders Hejlsberg og kørte rigtigt fint på Piccoloen.

Udviklingsrækken var så vidt jeg husker Blue Label Pascal -> Compas Pascal 2 -> Compas Pascal 3 -> Poly Pascal 3. Her skifter rækken så fordi PolyPascal 3 og Turbo Pascal 3 levede side om side indtil Poly Pascal blev udkonkurreret af Turbo Pascal 4 og 5.

Poly Pascal blev markedsført af danske Polydata, som var naive nok til at sælge koden til USAnske Borland, som så markedsførte det under navnet Turbo Pascal.

https://en.wikipedia.org/wiki/Turbo_Pascal

Jeg husker at Piccoloen havde 5 1/4" diskettedrev (jeg fandt for nyligt min første diskette der netop blev brugt på Piccoloen). Det er også det der er på maskinen på billedet til artiklen. Var der også en 8" version

Piccoloerne på DIKU havde ganske rigtigt 8" drev. de havde også 64K RAM.

I øvrigt brugte man 8" disketter med en kapacitet omkring 100 kB !

Pascal
er da et schweizisk udviklet programmeringssprog af Niklaus Wirth

Men Compas Pascal (aka Poly Pascal aka Blue Label Pascal aka Turbo Pascal) blev udviklet af Anders Hejlsberg og kørte rigtigt fint på Piccoloen.

er da et schweizisk udviklet programmeringssprog af Niklaus Wirth

I øvrigt brugte man 8" disketter med en kapacitet omkring 100 kB !

Jeg husker at Piccoloen havde 5 1/4" diskettedrev (jeg fandt for nyligt min første diskette der netop blev brugt på Piccoloen). Det er også det der er på maskinen på billedet til artiklen. Var der også en 8" version?

Har præcis sådan en skærm stående og har tit undret mig over hvad den havde været brugt til. Den så så gammel ud at jeg ikke ville smide den ud. Skal da lige se om jeg kan finde piccoloen også

Det var netop derfor jeg skrev "bliver opsagt" og tænkte at folk kunne læse detaljerne i dit blogindlæg, jeg kan godt rette det hvis du stadig ikke syntes det fremgår klart nok?

Vi er ikke blevet formelt opsagt af Ballerup Kommune endnu, men vi har fået et meget kraftigt vink med en vognstang om at det vil ske inden længe (med 12mdr. opsigelse).

Uanset dette, var vi dog allerede løbet tør for plads og har måtte ty til meget lidt ideelle opbevaring af de mindst vigtige dele af vores samling, bla. i en nedlagt stald.

Ja jeg husker det som 160 kbytes på de 8" jeg havde på min North Star fra 1978. Disse Schugart drev voksede dog også til 320 kiobytes og siden til tosidig læsning. Jeg smed dem ud i 1992 inden jeg rejste til Kouroru for at arbejde med Ariane 4. Det var uheldigt et af systemerne vi havde leveret fra Rovsing ca. 1981 blev stadig brugt, så de kunne virkelig have brugt en backup, De store hardiske den gang var typisk CDC med 80 megabytes og evet med en 10 Megabytes udskiftelig - de var naturligvis 14" g krævede et mindre elværk for at starte.

Det var ikke Piccoliner men derimod Piccoloer som blev brugt på Dat0 til programmering i COMPAS Pascal. I øvrigt brugte man 8" disketter med en kapacitet omkring 100 kB !

Jeg var selv sidste årgang der anvendte dem (88/89) - året efter blev de udskiftet med PC'ere....

Undskyld mig, jeg fandt dem selv:

Piccolo: http://www.jbox.dk/rc702/emulator.shtmPiccoline: https://rc700.dk/

Jeg mener DIKU brugte Piccoliner på Dat0 i 1981/1982, men da Piccolinen først kom i 1984, må det vel have været Piccolo-systemer dengang på DIKU?

@Mike: jeg kan ikke finde det i videoen lovede link til rc702 emulatoren; ej heller på mikjaer.com/retro, det er nok bare mig, der er fatsvag;-)

Det er at tankevækkende, at DEC blev startet for $70.000 i 1957 og overlevede, som selvstændigt frem til 1998. Mens RC kostede $120.000 i 1955 og lukkede i 1993.