Software "Das Transputer-Buch" von Uwe Gerlach

nanapa wrote:=20

*Irgendwo* m=FC=DFte ich Buch und Diskette noch haben -- ob die Diskette=20 noch geht, wei=DF ich aber nicht.=20

Gib mir mal eine g=FCltige e-Mail-Adresse, an die man auch gr=F6=DFere=20 Attachments schicken kann. *Wenn* ich sie finde, und *wenn* sie noch=20 geht, und *wenn* der alte 486er mit dem 5.25"-LW ebenfalls noch=20 funktioniert, m=FC=DFte ich dir die Daten davon irgendwann in den n=E4chste= n 2=20 Wochen zumailen k=F6nnen.=20

Gru=DF Michael

nanapa schrieb:

Jetzt bin ich Platt! Da macht wirklich noch jemand aktiv mit den Transputern herum. Die Hardware hat doch durchaus schon Seltenheitswert und ist an Moderne PCs auch noch schwer dranzubekommen.

Aber sorry, das Buch mit der Disk habe ich leider auch nicht.

Marcel

Hallo Marcel,

Bin auch platt. Ich hatte einen der Entwickler der Transputer Chips auf einem Camp Ground in einem Nationalpark hier in USA getroffen und einige Bierchen mit ihm geleert. Das war aber schon 20 Jahre oder so her. Schon damals schienen diese Dinger eher Boutique Bauteile zu sein, die ausser von Uni-Wissenschaftlern offenbar kaum eingesetzt wurden.

--
Gruesse, Joerg

http://www.analogconsultants.com

=20

Warst du schonmal auf de.alt.folklore.computer...?

"Marcel Müller" schrieb...

Hallo Marcel,

ich habe hier noch 2 Stück IMST805-G25 Baujahr Oktober 93. So lange ist das noch nicht her ... oder doch ?

Wenn du aktuelle Transputer Hardware an einem PC haben willst musst du dir nur ein Spektrometer der Firma Zeiss kaufen. Auf der PC Interface Karte sind noch Transputer Links in einem Xilinx Chip verpackt drauf ;-)

Gruß

Hans-Georg

"nanapa" schrieb:

Hi!

Hab noch einen alten Dos-Rechner mit beiden Laufwerken auf dem Speicher stehen. Könnte Dir die Diskette umkopieren.

Gruß Jürgen

--
Mailadress: klein AT technik-klein DOT de
Advertisement to this mail address is prohibited!
MyEbay: http://members.ebay.de/aboutme/do1pjk/

Aber die Dinger waren durchaus an den Unis begehrt, leider war oft kein Geld da, da sehr lange EDV (heute "IT" oder so) auch an Unis monopolisiert war. Zum Teil musste Rechen- leistung sogar zwangsweise bei bestimmten staatlichen oder halbstaatlichen Monopolbetrieben gekauft werden. An der Uni Bern hat Prof. Schumacher persönlich eine Isotopentrennanlage gebaut und betrieben. Die gewonnenen Argonisotope wurden für IIRC CHF2000 die Ampulle an Geologen verkauft. Mit dem Geld kauften dann die Chemie- studenten (!) INMOS-transputerkarten und bauten einen ziemlich leistungsfähigen Rechner, in Occam (?) programmiert. Damit wurden quantenchemische Rechnungen durchgeführt, die ich allerdings nicht verstehe...

--
mfg Rolf Bombach

"Rolf_Bombach" schrieb im Newsbeitrag news:4518141b$1 snipped-for-privacy@news.bluewin.ch...

Die Dinger waren allerdings fuerchterlich langsam, selbst wenn man sie in Assembler programmierte (die FPU des T800er war recht schnell), und das Versprechen: Nimm 1000, dann geht es 100(0) mal schneller, scheiterte bei Unis staendig am Budget. Mit einem PC (80286) ging also dasselbe schneller und billiger und viiiieeell einfacher. Nun, die Welt hat gelernt, Transputer sind ausgestorben, ebenso wie DEC Alphas, die auch mehr Hype als handfest waren.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Kein DRAM-Cache eben. Und das OnChip-RAM war viel zu klein.

Naja, so 486-er Niveau.

... und ab 80387 hat es auch Spaß gemacht.

Also einige DSP-Architekturen, die ich viel später gesehen habe, waren den Dingern schon verblüffend ähnlich gestrickt. Natürlich ohne das kranke, linkerunfreundliche Instructionset. Und vor allem ohne Occam, das außer der zur Compilezeit bekannten Stackgröße in der Praxis wohl keine Vorteile hatte. Aber es gab ja zum Glück auch noch ANSI-C - war auch schneller.

Die Idee, massiv mit Threads zu arbeiten erfährt heute dank Multicores sogar wieder einen Renaissance. Ich würde sogar subjektiv sagen, dass wenn man Anwendungsfälle immer bis auf einen Thread pro logischen Aufgabenblock strukturiert und dieses Konzept konsequent umsetzt, gehören etliche subtile Programmfehler der Vergangenheit an. Gerade, wenn es um verschiedene assynchrone Ereignisquellen geht (Steuerung). Die Channelkommunikation war da auch durchaus hilfreich - ganz im Gegensatz zu den klassischen Modellen mit Semaphoren, die bekannt für ihre Fehleranfälligkeit sind.

Auch die damals schellen Punkt zu Punkt Verbindungen sind in heutigen Systemarchitekturen vom Prinzip her wieder zu finden.

Also ich würde sagen, die Transputer sind zwar tot, aber aus den Ideen von damals hat man durchaus gelernt und einiges weiterentwickelt.

Die waren seinerzeit aber zumindest wirklich schnell (FPU-technisch). Dumm nur, dass die ganzen Numerical-Recipies-Codes völlig achtlos mit der Zahl der Integermultiplikationen umgegangen sind (Array Subscripts), die genausolang wie ein fmul gedauert haben.

Marcel

*Puh*, im Keller müsste auch noch eine bestückte ISA-Karte liegen. Allerdings ohne Transputer. Für die Diskette gilt ähnliches wie bei Dir: Theoretisch existiert sie noch (irgendwo, irgendwie)...

Also, wenn Du sie nicht mehr findest, könnte ich zur Not auch mal suchen...

Na das musst du jetzt aber erläutern - wieso sollten Semaphoren anfällig für subtile PRogrammierfehler sein? Wenn du Mutexte geschrieben hättest, würde ich's dir glauben, aber ich finde Semaphoren ein hübsches und vorallem sehr einfaches Konzept zur Resourcenverwaltung.

Viele Grüße, Johannes

--
durch dei Verdunstung kült das sogar ziemlich gut
das ist wie schweiß. Hünde müssen da hecheln so wie Lüfter.
                              Markus Gronotte in de.sci.electronics

Johannes Bauer :

Ich vermute mal, er meint es anders: Aufteilung von Code in viele sequentielle Stränge, in denen dann syncron auf das Eintreffen eines Ereignisses gewartet wird, anstatt das alles in einem Thread abzuwickeln und dort dann mit vielen Flags zu hantieren, um Ereignisse asynchron zu signalisieren. Ganz ohne Semaphoren und Mutexe geht das aber auch nicht, die Anzahl derer lässt sich aber ziemlich reduzieren. Ein simples Beispiel aus der PC-Welt ist z.B. die Pascalunit synaser (zum Zugriff auf die serielle Schnittstelle). Dort sieht der Progammablauf z.B. so aus: Öffnen der Schnittstelle: M: Zeichen senden, warten auf das Eintreffen (hier ist der Thread komplett blockiert!), empfangene Zeichen lesen Loop M oder Ende Schnittstelle schliessen (Parallel läuft der Hauptthread, der aber in diesen Thread eingreifen kann.)

Sehr viele andere Bibliotheken im Web arbeiten ereignisorientiert: Start der exe: Schnittstelle öffnen, Ereignisshandles einrichten irgendwo im Code, Routine A: Zeichen senden irgendwo im Code reagiert der Ereignishandler B: Zeichen empfangen irgendwo im Code Routine C: Zeichen senden (wenn COM frei) irgendwo im Code reagiert der Ereignishandler B: Zeichen empfangen exe schliesst: Schnittstelle schliessen

Die erste Version ist sehr viel übersichtlicher und multicorefreundlich. Die zweite kommt mit nur einem Thread aus.

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

Also ich muss leider gestehen, dass ich auch Heute noch Trapus aktiv fuer private Basteleien benutze. Fuer mich ist das eine wunderbare Plattform, um mal schnell was in Hardware zu implementieren. Man kann an die Dinger namelich leicht und schnell ein paar IO-Ports und dergleichen dranbauen (wer macht das Heute schon bei einem PC mit dem ganzen PCI-WeissnichtWas Schnick-Schnack).

Wenn man als Betriebssystem Helios benutzt (das unterstuetzt natuerlich auch Trapu-Netzwerke), so hat man ein UNIX-artigs Betriebssystem mit C-Compiler, das auf so einem Transputer innerhalb von 2 Sekunden bootet. So kann man den Zyklus "Loeten, OS starten, testen" recht zuegig fahren, ohne auf das booten von irgendwelchem PC-Mist zu warten (manche IDE auf dem PC startet langsamer). Ausserdem kann der Experimentier- aufbau irgendwo stehen (Laenge der Links unproblematisch), so dass man auf dem Arbeitsplatz sehr schoen arbeiten kann.

Was den Speed angeht, so finde ich die Performance nicht so schlecht (man lasse wirklich mal ein linux auf einem 486-25 im Vergleich dazu laufen und dann stellt man fest, dass es kein Unterschied ist), besonders wenn man Groesse und Leistungs- verbrauch der damaligen 486er beachtet (ein Trapu-Knoten mit T805 braucht bei 30MHz unter 10W und passt auf eine EURO-Karte).

Last but not least kann man die Dinger recht nett in Assembler programmieren und dann einzelne Routinen ins interne RAM packen lassen (es gibt dafuer sogar ein C-API wer moechte) und dann ist die Sache recht flott.

Aber zugegeben - im Zeitalter der spottbilligen PCs, der extensiven Verwendung von irgendwelchen Libraries und Abstraktions- layern kommt man mit den Transputern nirgendwo mehr hin...

... sie sind eben Geschichte ...

... von der aber einiges zu lernen ist und von der gottseidank auch manche etwas gelernt haben ...

Ciao,

Erik.

Ich hätte irgendwo auch noch die Disketten von dem C-Compiler liegen (Vollständig?)

Einen T800 und einen T805 (Copro evtl Defekt) habe ich zur Not abzugeben.

tschuessle Bernhard Spitzer

--
bash.org - Top 100...
 hm. I've lost a machine.. literally _lost_. it responds to ping, it 
works completely, I just can't figure out where in my apartment it is.

...also an dem 805er haette ich Interesse. Ist der 25MHz?

Gruessle,

Erik, snipped-for-privacy@baigar.de

Hallo,

Matthias Weingart schrieb:

ja richtig, das hatte ich gemeint.

Marcel

"Marcel Müller" schrieb

in den Sparcs stecken da noch einige Ideen von den Dingern

Für einen einzelnen Transputer gebe ich dir Recht. In der Luftfahrt, wo es um redundante Systeme geht, war das schon OK.

Hmm, massive Threads gegenüber ein paar Cores ... für mich kein Argument "massiv" Threads zu verwenden.

Threads sind kein Mittel Aufgaben oder Programme zu strukturieren. Es macht z.B. keinen Sinn Aufgaben, welche den Processor jeweils zu 100% auslasten auch noch in Threads zu unterteilen.

Wer erzählt denn sowas ;-) Semphore sind Synchronisationsobjekte und per se nicht für Fehler haftbar zu machen. Das Problem sitzt wie immer vor der Tastatur ( Stichwort Deadlock).

Nur brauchen alle Syncronisationsobjekte eine korrekte Implementierung mit einem nicht unterbrechbaren Codeabschnitt. Durch Hardwareunterstützung (atomare Befehle) oder durch sperren der Interrupts.

Gruß

Hans-Georg

|> Threads sind kein Mittel Aufgaben oder Programme zu strukturieren.

Das nicht, aber oft ein Mittel, die Aufgaben gut und elegant zu implementieren.

|> Es macht z.B. keinen Sinn Aufgaben, welche den Processor jeweils zu 100% |> auslasten auch noch in Threads zu unterteilen.

Muss nicht unbedingt sein. Wenn die Threads nicht völlig voneinander abhängen, kann durch die Verlagerung in Threads der Cache evtl. besser genutzt werden. Bei Multicore mit getrennten Caches hilft das erst recht.

Die Abneigung gegen bzw. Unwissen über Threads ist übrigens ein Problem, was Intel/AMD mit ihren Multicores ziemlich übel trifft, weil die CPUs sonst kaum schneller werden. Gerade Intel versucht jetzt eine ganze Menge, um den Anwendern das Programmieren mit Threads näher zu bringen. "Anwender" umfasst dabei nicht nur die informatisch vorbelasteten (da gehts noch einfacher), sondern auch alle Sonstigen (Physiker etc.). Die haben ohnehin schon genug Problem, ihre Algorithmen so zu schreiben, dass sie halbwegs Cache-effizient laufen ;-)

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

"Matthias Weingart" schrieb>:

Man sollte mal (wieder) Tannenbaums Bücher lesen. Mutexe sind nur eine spezial Form von Semaphoren (nicht zählend, sondern binär). Der grundlegende Mechanismus darunter ist die critical section, welche einen nicht unterbrechbaren Codeabschnitt markiert. Bei Multiprozzesor Systemen muss auch noch der gemeinsame Speicher gesperrt werden (Stichwort TSL).

Was meinst du damit ? Multi Threads ? Warum brauche ich dann in einem Single Thread Semaphore und Mutexe, wenn es eine While (! ereignisVariable ) Schleife zum Warten auch tut ?

Dazu wollte ich eigendlich nichts sagen .. aber mal wieder aus aktuellem Anlass kommt bei mir bei Borlands Produkten (Delphi in diesem Fall) keine Begeisterung in Beziehung Multithreading auf.

Pacal != Borland

Was bedeutet "ereignisorientiert" ? Interrupts ? Oder doch nur Threads, eventuell im Betriebssystem versteckt, die auf ein Synchronisationsobjekt warten.

.. oh Tannenbaum ... ;-))

Gruß

Hans-Georg