Wirkungsgrad von 100 m RG213U

Jau, deshalb Steinzeit :)

Die Facit Leser kenne ich auch, waren aber viel langsamer, als die hp-2737 LS-Leser (WIMRE 300cps) 19" Einbau. Normale Glühlampulle und Foto Dioden. Capstan mit Andruck/Stopp-Magnet. Unkaputtbar.

Aber ich kann mich nicht mehr erinnern, wie die LS Programm Quellen editiert wurden. Habe den Workflow völlig vergessen :(

Ahh, jetzt dämmerts wieder, ich fing mit dem Folgemodellen hp-2108 und hp-

2114 an.

Mit den 4 Knöpfen am TTY-ASR33 Stanzer wurde 'copy&paste' gesteuert... und irgendwas musste man am Keybord des hp 2114 auch noch flippern...

TTY 110 cps Stanze 75cps Leser 300cps

Mein 1. Video Terminal (DEC VT52) bekam ich 1978 in die Finger, an einer PDP 11/34, 8k Core, 2x RK05 (mit 2,5MB! ja richtig 2,5 Mega Byte!!!) RSX12M und einem LP300 Hammerbank Printer. Da arbeitet eine ganze Fa. mit insgesamt 8 VT52 dran!

Die (Wechsel)Platten der RK05 sahen aus, wie Behälter für Heiligenscheine :)

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Am 15.09.23 um 10:54 schrieb Andreas Bockelmann:

Heute ja, bis weit in die 1980er Jahre hinein nein. Für die damals weit verbreitete Hardware waren Hochsprachen-Compiler teils gar nicht erhältlich, teils so beschränkt, das man damit keinen Blumentopf gewinnen konnte. Die meiste kommerzielle Software war ganz oder teilweise in Assembler geschrieben.

Seit Erfindung des Mikroprozessors existierte eigentlich zu jeder Zeit eine Prozessorfamilie, die einen so hohen Marktanteil hatte, das Softwarehäuser gut mit der Beschränkung auf eine Familie leben konnten. Teilweise existierte sogar automatische Übersetzungssoftware - der 8086 zum Beispiel verdankt seinen Siegeszug zu einem guten Teil der Tatsache, das sich 8080-Assembler-Quellcode automatisch umwandeln ließ.

Anpassungen an die spezifische Maschine (Schnittstellen zum BIOS und OS, Treiber für spezielle Hardware) kann man in einem guten (Makro-) Assembler genauso leicht realisieren, wie in einer Hochsprache.

Und trotz perfektionierter Hochsprachen wird heute leider immer noch sehr, sehr viel Code mit so engen Scheuklappen geschrieben, das er am Ende doch nur auf x86-Prozessoren unter Windows läuft... :-(

Du hast mindestens noch Betriebssysteme vergessen. Zwar bestehen diese heute zu 98% aus Hochsprachen-Code, fürs Eingemachte muss man aber dichter an die Maschine heran.

Ich habe mich zwar nie mit Fortran quälen müssen, möchte aber wetten, das jeder Compiler seine proprietären Erweiterungen hatte, die mit Begeisterung auch von "Spezialisten" genutzt wurden.

Helmut Schellong schrieb:

Bei den PDP-Maschinen war es trivial, mit FORTRAN eine Assembler-Routine aufzurufen. Und mit einer Zweiadress-Maschine mit Memory Mapped I/O konnte man Assembler aus dem Ärmel schreiben. Ich konnte so problemlos 20 Flugzeit- Massenspektren pro Sekunde einlesen (DMA) und vorverdaut an das FORTRAN-Hauptprogramm zurückgeben. Dazwischen hat das Progamm, ebenfalls via Assembler-Routinen, die Wellenlänge des Lasers weitergedreht und die Verdopplerkristalle nach Polynomtabelle nachjustiert. Speichern usw geht dann natürlich einfacher, das ist der Vorteil der Hochsprachen. Das war ja der entscheidende Vorteil von FORTRAN; FORTRAN ist sozusagen eine App, die es ermöglicht, einen Rechner zu benutzen, ohne irgend eine Ahnung von ihm zu haben.

Hypsch, aber da fehlt u.a.

Real Programmers don't comment! If it was hard to write, it should be hard to read!

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Hergen Lehmann schrieb:

Bis weit in die 1980er Jahre hatten die meisten Computer erst einmal ein Basic. (Ja, der Sharp MZ-80 wieder nicht....)

Mag sein, die durfte man für jede Platform extra erwerben, siehe mein Einwand nach der Portabilität.

Das war nie die Idee von Fortran. Ings. verwenden Fortran um ein konkretes Problem oder eine konkrete Aufgabe zu berechnen. Heute würde man dafür fertige Software nehmen, in die man seine Formeln eingibt. (oder OpenAI fragen :-))

Bei Fortran gibt es mehrere Generationen. Ich kenne noch Fortran IV, Fortran V und Fortran 77.

Über 50% meiner Kollegen würden fest zusichern, noch nie von einem Problem gehört zu haben, das sich nicht mit ein wenig ABAP-Code lösen ließe.

Am 15.09.23 um 12:32 schrieb Andreas Bockelmann:

Dessen Verwendung für kommerzielle Software scheiterte sowohl an der grauenhaften Performance als auch an der Tatsache, das das wenige RAM in Nullkommanix voll war.

Die meiste kommerzielle Software war auf diesen Maschinen "natürlich" in Assembler realisiert und kam gerne auch in Form von ROM-Cartridges, um das RAM zu entlasten und stundenlange Ladevorgänge von den schnarchlahmen Massenspeichern zu vermeiden.

Da kommen wir dank der Bindung an Cloud-Accounts ja gerade wieder hin. Und diesmal wird nicht nur für jede neue Plattform, sondern für jede Maschine, jeden Nutzer und jedes Jahr die Hand aufgehalten... :-(

Die Idee nicht - aber das, was man in der Praxis oft tun musste, um Daten von wissenschaftliche Geräten automatisiert zu übernehmen oder um aus der verfügbaren Hardware eine erträgliche Performance heraus zu kitzeln.

Na, dann sag mir doch mal, welche Hochsprachen Du für einen Editor z. B. auf einem Sinclair ZX Spectrum verwenden würdest. Wo wir doch bei Bitpopeln in der Gründerzeit angelangt sind.

Volker

Am 10.09.2023 um 07:46 schrieb Helmut Wabnig:

Uuuhhh, übel, für die Koaxialltg. Belden8267 (RG213/U) in Deinem Programm ist die Heaviside-Bedingung nicht erfüllt.

Belden8267 verzerrt.

Ich bin in meiner Rechnung von einer verzerrungsfreien Ltg. ausgegangen...

Gs/Cs = Rs/Ls

Bei der Belden-Ltg. steht da...

4686011.08 = 7303509.174 Ü B E L ...

War das der, der nicht auf echten 32-Bit-Maschinen (also ab 68020) lief, weil der Programmierer die oberen 8 Bit von Pointern anderweitig verwendet hatte?

cu Michael

Ich hatte nie ein Sinclair ZX, warum sollte ich dafür, dadrauf... was schreiben?

Ich hatte hp21xx, PDP 11/34 sowie Mostek (samt CP/M) zur Verfügung, da waren Editoren drauf!

SEDT (DEC) war der fast Wunschlos beste Editor, W-Star auf dem CP/M...

Aber nochmal, Editor mit Assembler schreiben, ist Unfug! Flasches Werkzeug!

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Der erste Editor ist immer der schwierigste. :-]

Helmut Schellong schrieb:

Weil viele durchgeknallte Doktoranden sich ein Denkmal setzen wollen?

Definitionsfrage. Letztendlich wird alles in Assembler respektive Maschinensprache gecoded. Allerdings nicht von Menschen, sondern von Compilern. Am meisten wird wohl in C-irgtenwas gecoded, aber auch hier das allermeiste von Maschinen und nicht von Menschen.

Und das meiste, was gecoded wird (ich rede hier absichtlich und vorsätzlich nicht von programmiert), ist die Neuerfindung des Rads. Die Arbeit darf ja nicht ausgehen. >20 Mio E-businesses on planet earth, und keiner läuft einwandfrei. So einen Markt darf man ja nicht austrocknen lassen.

Anders sieht es für Entwickler aus, die z.B. einen neuen Sensor bauen müssen, der nichts kosten darf.

Am 16.09.2023 um 14:07 schrieb Rolf Bombach:

Das dürfte auf Dennis Ritchie und Bjarne Stroustrup nicht zutreffen, die das Paar C/C++ entwickelt haben, welches mit großem Abstand die meist verwendeten Programmiersprachen sind.

Am meisten wird in C oder C/C++ programmiert - von Menschen.

UML ist eine 4GL-Sprache, worin C eine Komponente sein kann. Ich mag diese Ebene gar nicht.

Mir fällt seit langem auf, daß Programme, die nicht von mir programmiert wurden, oft etwa 25-fach langsamer sind als PC-Programme für den gleichen Zweck, die von mir programmiert wurden. Das liegt daran, daß meistens nicht 'direkt' programmiert wird, sondern sehr indirekt verschachtelt und unnötig verschwurbelt.

Eine Verwandtschaft besteht darin, daß ich oft die Aussage las, Microsoft würde es fast immer gelingen, die erhebliche Mehrleistung von neuer Hardware umgehend wieder zu verdampfen, mit der nächsten Betriebssystem-Version.

Ich stellte vor Jahrzehnten fest, daß die Sprache COBOL bei gleicher einfacher Aufgabe 80-fach langsamer ist als C. Das bedeutet, daß weltweit viele Jahre lang entsprechend größere und teurere Hardware-Leistung vergeudet wurde. Mittlere EDV hätte ausgereicht, anstatt Groß-EDV.

Wolfgang Allinger schrieb:

Den ersten Editor wirst du mit Assembler oder gar in Maschinensprache schreiben müssen, und zwar ohne Editor :-]

Die erste Drehbank zu bauen war sicher auch nicht lustig.

Editor in LabVIEW? Wäre interessant, allen schon von der Ressourcenverbraterei her.

Lustre? Für extrem reaktive Editoren sicher geeignet. Für Hochgeschwindigkeits- Programmierer.

Postscript?

Hallo Hergen,

Du schriebst am Sat, 16 Sep 2023 15:02:50 +0200:

Naja, bei letzteren mußt Du inzwischen schon noch differenzieren. Meinst Du hier die PIC10, 12, 16 oder 18 - das sind die 8-Bitter der Reihe, wobei die Zahl die Anzahl der Bits im Befehlscode angibt. Das sind typisch CPUs mit Harvard-Architektur und _sehr_ bis halt durch die Adressierfähigkeit beschränkten Fähigkeiten, wozu auch der als spezielle Registergruppe implementierte unveränderliche Stack gehört (4 bis ca. 16 Ebenen). Die "höheren" PICs, ab PIC24, haben dann wieder im wesentlichen eine von-Neumann-ähnliche Architektur mit Trennung zwischen Befehls- und Datenspeicher. Das ist auch sinnvoll aufgrund ihres Aufbaus, der für den Programmcode einen (internen) Festwertspeicher vorsieht. Der 32-bittige PIC32 hat wegen seiner MIPS-Struktur keine relevante Bedeutung mehr erlangt.

Am 16.09.2023 um 20:57 schrieb Rolf Bombach:

Ein _wirklich einfacher_ Editor kann im kanonischen Modus eines Terminals verbleiben.

Eine Programmiersprache sollte Turing-vollständig sein, um als solche zu gelten. Eine universelle Programmierbarkeit soll vorliegen.

Nach rabbinischer Lehre war die erste Zange ein g"ttliches Geschenk, denn man braucht eine Zange, um eine Zange zu schmieden. (OK, nach denselben Rabbinen ist ein Kaninchen nur unkoscher, weil es keine paarigen Hufe hat -- ein Wiederkäuer ist es ja.)

Hi Axel,

Der Hase bittschön, nicht das Kaninchen.

Marte