Wirkungsgrad von 100 m RG213U

Andreas Bockelmann schrieb:

Fortran war halt _der_ Durchbruch, 1957(!). Endlich konnten Ings usw. direkt den Rechner verwenden. Coder hassten Fortran, da die Hochsprache ihre Jobs überflüssig machten. Ja, ich kannte noch solche Leute. Die waren oft peinlich, rannten in weissen Kitteln rum, warum auch immer. Konnten Coden, aber eher nicht Programmieren.

Damals war Fortran schon literate programming :-). Wie ich schon bemerkte, damals war das so was wie eine App heute. Ein Schritt Richtung Kommentar ist der Code.

Bei Numerikern durchaus noch beliebt, vorallem weil C oftmals nicht gut lesbar ist, insbesondere wenn von Laien programmiert. Zu wenig orthogonal, zuviele "individuelle" Programmierstile möglich, nicht wirklich strukturiert.

Wo Du recht hast ...

Danke Axel

Mir waren die Falt-LS immer suspect. WIMRE irrer Verschleiß

Ich kenne auch einen LS-Leser mit 1000cps, aber der zerriss mehr als man flicken konnte. Hersteller HIV, hamwa schnell wieder ausgemustert. Und ich war ein Spitzen LS-Flicker :) Händisch bin ich der Typ: Hobby-Gynäkologe :)

Hab 300m Rollen mit dem berühmten hp Radierapparat aufgewickelt, obwohl der nur für knapp 50m gedacht war. Ohne was zu zerreissen und 300m Haufen auf dem Boden. Man durfte sich nur nicht mit den Hinterbeinen bewegen. Und jeden im Umkreis von 2m vor Lesen verscheuchen.

Bei der AEG 60/10 war die Stanze und der Leser in einem ausziehbaren Wagen als Auffangkorb. Auf dem Tisch ein Wickelteller für 300m. Bekam ich auch gut hin.

Die MIESENS R300 hatte dt. 5 Lochstreifen (Fernschreiber). Ein Graus :}

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

Helmut Schellong schrieb:

Es ging um die grosse Anzahl, nicht um eine. Ausserdem wirst du immer jemanden finden, der behauptet, C++ wäre eigentlich tot. Programmier/Codingsprachen kommen und gehen, das ist gut fürs Geschäft und schlecht für ältere Mitarbeiter. Warum wir jetzt unbedingt Bosque, Dafny, Red, Crystal, Hack, Haxe, Zig und Reason brauchen, keine Ahnung. Hautpsache hot shit.

UML ist auch am zersplittern.

Klar. Hatten wir ja mit dem Editor-Programmieren. Was an sich ja eine dumme Frage ist, da bei Systemen, welche Hochsprachen anbieten, der Editor ja dabei ist. Und wenn man einen in einer Umgebung braucht, zieht man mit Visual- Whatever eine Textbox hin und fertig. Dann kann man das gleich "publizieren", zusammen mit der 100 MB grossen Runtime. Ab Win11 und 12Gen Intel und aufwärts :-], Microsoft Account mandatory.

Da würde ich nicht notwendigerweise Absicht unterstellen. Eher, je leistungs- fähiger das System, desto bequemer kann man "programmieren", so wie Lego- Klötzchen aneinander reihen. Zum Glück gibt es noch Bedarf an Billigwinzig- Microcontrollern einerseits und Höchstleistungs-Rechnern andererseits, sonst würden alle Programmierer verblöden. Bloatware ist die Zukunft. Ob das gut ist, da sagt man hier besser nichts, sonst wird man von den Physikern, Juristen usw hier wieder als Ewiggestriger abgekanzelt.

Zu jener Zeit waren C-Programme drei mal langsamer als FORTRAN-Programme. Und F2C-Programme 10 mal langsamer.

COBOL lief zuerst auf BCD-Rechnern wie der IBM1620, dann BCDIC und EBDIC. COBOL war so ein Anlauf für literate programming, damit eventuell nicht optimal für Numerik. Mit einem anständigen Compiler läuft das sicher gleich schnell. Soll ja EGL to COBOL Compiler geben. Abgründe.

Am 16.09.2023 um 23:40 schrieb Rolf Bombach:

Bei disziplinierten Programmierern wirkt sich das allerdings nicht schädlich aus. Man muß sich halt selbst aufgesetzten, vernünftigen Konventionen strikt unterwerfen.

Am 18.09.2023 um 11:56 schrieb Rolf Bombach:

Hot shit brauche jedenfalls ich nicht.

Es begann mit ALGOL, COBOL, FORTRAN. Dann folgten Pascal, C, Ada, Shell (Kommando-Programmiersprachen). Später Python, Ruby, Modula, C++.

Ich führte vorstehend konkret viel benutzte Sprachen auf.

Ich benötige eine Compiler-Sprache, die ultimativ schnelle Programme generiert. Das ist mit C und C++ sichergestellt. Weiterhin brauche ich eine Shell-Skript-Interpreter-Sprache.

Grundsätzlich interessiert mich noch Ada. Aber immer, wenn ich darüber nachdenke, komme ich zu dem Schluß, daß ich Ada nicht wirklich benötige. Viel eher benötige ich PEARL.

Haben wohl viele aus Modegründen aufs (letztlich) falsche Pferd gesetzt.

Ich hörte von einem Kollegen, daß Miele ihre Waschmaschinen mit UML programmiert. Der Kollege wollte dort anfangen, konnte aber selbstverständlich kein UML...

Ich habe bei so Etwas stets das Gefühl, daß in UML programmiert werden soll, damit die Vorgesetzten, die nicht programmieren können, zumindest ein wenig von der entwickelten Software verstehen wollen, wegen der grafischen Darstellung durch UML. So ähnlich wie durch die dämlichen Struktogramme.

Der Gipfelpunkt war ein Programm, das eine Suchfunktion anbot, die 6 Dateien mit jeweils 0,8 .. 2 MB Größe durchsuchte. Ein Suchvorgang dauerte meist etwa 2 Minuten. Meine Algorithmen hingegen brauchten einen Zeitbedarf von Millisekunden und waren damit ungefähr 1000-fach schneller.

Ich fragte mich bei solchen Feststellungen stets: wie bekommt man es hin, daß ein Code zu einer immer noch einfachen Problemstellung derart langsam ist?

Zu COBOL habe ich zufällig einen alten Compiler zur Verfügung. Eine Handvoll kleine Programme habe ich damals programmiert. COBOL hat eine streng einzuhaltende Schreibweise. Beispielsweise müssen bestimmte Elemente in bestimmten Zeichenspalten stehen. COBOL ist bekannt für sehr vielfältig programmierbare Eingabemasken.

Richtig - für numerische Aufgaben schlecht geeignet. Kann sein, daß COBOL eine 18-stellige BCD-Integer-Mathematik für Gleitkomma-Darstellungen verwendet.

Im Assembler-Listing habe ich eigentlich keine einzelnen Prozessor-Instruktionen gesehen, sondern fast nur Funktionsaufrufe. Da erklärt sich die extreme Langsamkeit.

Am 18.09.2023 um 11:56 schrieb Rolf Bombach:

Im OnTopic-Bereich dieser Gruppe - uC - sind die Sprachen C/C++ zum Glück meines Wissens beinahe zu 100% vertreten. Ich hatte jedenfalls ab 1988 einen C-Compiler von Firma Keil. Auch später der IPC@CHIP (Beck IPC GmbH)

Für die uC 16 Bit von Fujitsu gibt es nur ein C-Entwicklungssystem, für die uC 32 Bit Coldfire gibt es nur ein C/C++-Entwicklungssystem, usw.

Das ist jetzt fast 40 Jahre der Fall mit der Paarung uC und Sprache C/C++. Und es wird noch lange so bleiben!

Wer behauptet, C++ sei () tot, ist in jedem Falle krank im Kopf. Erstens, weil das krasse Gegenteil vorliegt, und noch lange vorliegen wird. Zweitens, weil zu beiden Sprachen regelmäßig neue ISO-Standards erscheinen. Drittens, weil der nicht damit rechnen kann, daß seine irre Behauptung geglaubt wird.

Der Vorteil der hoeheren Programmiersprachen ist dass man die Programme beim Wechsel auf andere Hardware weiter verwenden kann.

Den allerersten, aber der ist ja schon da. D.h. man wird fuer eine neue Art Prozessor erst mal einen existierenden Compiler auf einem existierenden Computer modifizieren so dass er Code fuer den neuen Prozessor erzeugt, und damit existiernde Software einschliesslich des Compilers und Editors fuer den neuen Prozessor uebersetzen.

Man braucht ihn fuer spezielle Befehle der CPU die die Hochsprache nicht verwendet. Die Raspberry Pi Pico (2021) Pio muss man in Assembler programmieren, weil es bisher keine Hochsprache dafuer gibt. Die Pio ist ein spezieller Koprozessor der im Pico mehrfach vorhanden ist und Aufgaben uebernimmt fuer die man ohne ein FPGA gebraucht haette. Man kann damit z.B. nur mit dem Pico und einem ueblichen GPS Modul mit Sekundenausgang einen Frequenzzaehler der bis zu 60MHz Signale zaehlen kann:

Oder wenn man spezielle Befehle eines Prozessors benutzen will die die Hochsprache nicht kennt, bzw. die in ihr nicht vorgesehen sind.

Im obigen Beispiel kommt es offenbar wieder.

Heute wuerde man einen C-Compiler fuer Z80 verwenden, ich weiss aber nicht seit wann es den gibt. Was es damals sicher gab war BASIC.

Schrieb ich ja oben: "Zugang zu allen Instruktionen, die der Compiler nicht verwendet."

Z.B. Quotient und Divisionsrest auf einen Schlag berechnen. Ein Compiler macht das nicht, wenn das in der Quelle nebeneinander steht.

Kann sein, daß der Pico verschwindet, weil für ihn keine Hochsprache da ist.

Für Spieleentwicklung. Endnutzer konnten für eigene Programme keine Großrechner einsetzen sondern nur Compiler, die auf der eigenen Maschine liefen, beim Sinclair also iirc keine. Für etwas besser ausgestattete Rechner unter CP/M gab es u.a. ein gutes Pascal.

Hi Carla,

ja ja, der Z80. Wehmütig denke ich an meinen MZ-731 von Sharp zurück. Basic gab es als Interpreter, Pascal als Compiler. Allerdings brauchte man Geduld beim Start. Das ROM enthielt nicht viel mehr, als ein Bootloader für Datasette. Ich hab mir das ROM-Listing auseinandergedröselt und konnte so meine Pascalprogramme direkt von Kassette starten. Das ging dann recht flott. Ausserdem konnte ich das voreingestellte Kontrollesen umgehen, was die Startgeschwindigkeit halbierte.

Die Klötzchengrafik war aber echt übel. Aber schnell war er, wenn man den Compiler nutzte. Noch cooler war der mit einem rückseitigen Anschluss erreichbare Z80-Bus. Da konnte man einfach einen AD-Wandler anstecken und hatte dann mit dem Plotter einen super Datenschreiber.

Marte

Hallo zusammen,

Wer schwadroniert hier eigentlich herum? Für den Pi Pico gibts selbstredend Python. C und C++ gabs auch vom Start weg. Kein vernünftiger Mensch schreibt ohne Not eine Zeile Assembler mehr.

Marte

Am 18.09.2023 um 23:43 schrieb Carla Schneider:

Habe ein paar Programme in VB6 (Visual Basic) geschrieben. Die Original CDs sind verschollen. Wie kriegt man nun die Programme mit möglichst wenig Aufwand in gängigere Hochsprachen? Auf Win10 kriege ich sie jedenfalls nur teilweise zum Laufen. Deshalb steht der alte Computer noch immer in meinem Büro.

Assembler braucht man nur fuer die PIO Prozessoren, nicht fuer die CPU. Die Programme dafuer sind recht klein weil es nur je 32 Worte Befehlsspeicher gibt fuer die 2 PIOs die jeweils 4 Prozessoren haben.

Sofern man beim Programmieren auf Portabilität geachtet hat, was durchaus nicht trivial ist. Byteorder, Zeigergrösse und Alignment können z.B. auf der anderen Hardware unterschiedlich sein.

Kein Problem, denn für solche Fälle bietet sich Forth an. Dort hat man auch einen Editor, der nicht in Maschinensprache geschrieben werden mußte.

Wer firmeninterne Programmiersprachen wie VB für dauerhafte Software benutzt, der hat sowieso etwas falsch gemacht. Andererseits ist C zwar sehr weit verbreitet, aber nicht unbedingt zur Portierung von Software auf andere Plattformen geeignet. Dafür wäre Python und andere Interpreter-Sprachen ideal, insbesondere im Hinblick auf die vielen Linux-Varianten. Dann muß ein Interpreter für jedes Zielsystem nur einmal angepaßt werden, und schon laufen alle Programme auch auf diesem System. Zwar wären .NET Programme weit effizienter, doch auch da ist die Verfügbarkeit eher zweifelhaft.

DoDi