Wirkungsgrad von 100 m RG213U...

[Axel Berger]

Rolf Bombach wrote:
> Die erste Drehbank zu bauen war sicher auch nicht lustig.

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.)


--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

 

[Sieghard Schicktanz]

Hallo Hergen,

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

WIRKLICH spartanisch wird es erst bei älteren Microcontroller-Familien,
etwa 8051 oder PIC...

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.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Marte Schwarz]

Hi Axel,

denselben Rabbinen ist ein Kaninchen nur unkoscher, weil es keine
paarigen Hufe hat -- ein Wiederkäuer ist es ja.)

Der Hase bittschön, nicht das Kaninchen.

Marte

 

[Rolf Bombach]

Wolfgang Allinger schrieb:

....
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.

....
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!

Den Lochstreifenleser in der PDP8 habe ich allerdings in anderer
Geschwindigkeit in Erinnerung. Eher was mit Metern pro Sekunde.
Motor direkt auf grosse Trommel mit den Traktor-Pins. Die
Erfindung waren die gefalteten Lochstreifen, aufgerollte hätte
es wohl zerrissen bei der Beschleunigung.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Andreas Bockelmann schrieb:

Auch mich hat man im Studiom mit Fortran gequält. Das war früher mal okay, mit einem Fortran-Programm kann ein Ing. seine Berechnungen durhcführen und den Quelltext auf jeder x-beliebigen Maschine
mit passendem Fortran-Compiler in Betrieb nehmen, aber mehr auch nicht.

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.

--
mfg Rolf Bombach

 

[Axel Berger]

Marte Schwarz wrote:
> Der Hase bittschön, nicht das Kaninchen.

Wo Du recht hast ...

Danke
Axel


--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

 

[Wolfgang Allinger]

On 16 Sep 23 at group /de/sci/electronics in article ue56dr$eep$1@dont-email.me
<rolfnospambombach@invalid.invalid> (Rolf Bombach) wrote:

Wolfgang Allinger schrieb:

...
hp-2737
LS-Leser (WIMRE 300cps) 19\" Einbau. Normale Glühlampulle und Foto Dioden.
Capstan mit Andruck/Stopp-Magnet. Unkaputtbar.

Den Lochstreifenleser in der PDP8 habe ich allerdings in anderer
Geschwindigkeit in Erinnerung. Eher was mit Metern pro Sekunde.
Motor direkt auf grosse Trommel mit den Traktor-Pins. Die
Erfindung waren die gefalteten Lochstreifen, aufgerollte hätte
es wohl zerrissen bei der Beschleunigung.

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

300cps sind WIMRE auch 0,76m/sec

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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Rolf Bombach]

Wolfgang Allinger schrieb:

On 16 Sep 23 at group /de/sci/electronics in article ue56dr$eep$1@dont-email.me
rolfnospambombach@invalid.invalid> (Rolf Bombach) wrote:

Wolfgang Allinger schrieb:

...
hp-2737
LS-Leser (WIMRE 300cps) 19\" Einbau. Normale Glühlampulle und Foto Dioden.
Capstan mit Andruck/Stopp-Magnet. Unkaputtbar.

Den Lochstreifenleser in der PDP8 habe ich allerdings in anderer
Geschwindigkeit in Erinnerung. Eher was mit Metern pro Sekunde.
Motor direkt auf grosse Trommel mit den Traktor-Pins. Die
Erfindung waren die gefalteten Lochstreifen, aufgerollte hätte
es wohl zerrissen bei der Beschleunigung.

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

300cps sind WIMRE auch 0,76m/sec

OK, kann hinkommen. Eigene Streifen habe ich nicht gefaltet, hatte
auch selten mehr Daten als wenige Meter.

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.

Holy smoke.

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

Ich musste genau drei mal ein Fernschreiben selber eintippen, Uni Bern.
Das erste mal, das letzte mal und nie wieder. Was für ein Scheiss mit
dem Umschalten auf Ziffern.

Danach/davor nur ASR33, nicht zu Verwechseln mit ARSR3 :-]

Dann die Erlösung: Datenübertragung per Floppy. 8\", 256 KB.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Helmut Schellong schrieb:

Am 16.09.2023 um 14:07 schrieb Rolf Bombach:
Helmut Schellong schrieb:

Warum gibt es denn eine große Anzahl höherer Programmiersprachen?

Weil viele durchgeknallte Doktoranden sich ein Denkmal setzen wollen?

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.

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.

Und warum wird vielleicht nur zu 0,01% in Assembler programmiert?

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.

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.

UML ist auch am zersplittern.

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.

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.

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.

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.

Ich stellte vor Jahrzehnten fest, daß die Sprache COBOL bei gleicher einfacher
Aufgabe 80-fach langsamer ist als C.

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

Das bedeutet, daß weltweit viele Jahre lang entsprechend größere und teurere
Hardware-Leistung vergeudet wurde.
Mittlere EDV hätte ausgereicht, anstatt Groß-EDV.

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.

--
mfg Rolf Bombach

 

[Helmut Schellong]

Am 16.09.2023 um 23:40 schrieb Rolf Bombach:

Andreas Bockelmann schrieb:

Auch mich hat man im Studiom mit Fortran gequält. Das war früher mal okay, mit einem
Fortran-Programm kann ein Ing. seine Berechnungen durhcführen und den Quelltext auf jeder
x-beliebigen Maschine mit passendem Fortran-Compiler in Betrieb nehmen, aber mehr auch nicht.

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.

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


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 18.09.2023 um 11:56 schrieb Rolf Bombach:

Helmut Schellong schrieb:
Am 16.09.2023 um 14:07 schrieb Rolf Bombach:
Helmut Schellong schrieb:

Warum gibt es denn eine große Anzahl höherer Programmiersprachen?

Weil viele durchgeknallte Doktoranden sich ein Denkmal setzen wollen?

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.

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.

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.

Und warum wird vielleicht nur zu 0,01% in Assembler programmiert?

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.

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.

UML ist auch am zersplittern.

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.

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.

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.

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?

Ich stellte vor Jahrzehnten fest, daß die Sprache COBOL bei gleicher einfacher
Aufgabe 80-fach langsamer ist als C.

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

Das bedeutet, daß weltweit viele Jahre lang entsprechend größere und teurere
Hardware-Leistung vergeudet wurde.
Mittlere EDV hätte ausgereicht, anstatt Groß-EDV.

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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 18.09.2023 um 11:56 schrieb Rolf Bombach:

Helmut Schellong schrieb:
Am 16.09.2023 um 14:07 schrieb Rolf Bombach:
Helmut Schellong schrieb:

Warum gibt es denn eine große Anzahl höherer Programmiersprachen?

Weil viele durchgeknallte Doktoranden sich ein Denkmal setzen wollen?

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.

Es ging um die grosse Anzahl, nicht um eine. Ausserdem wirst du
immer jemanden finden, der behauptet, C++ wäre eigentlich tot.

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)
https://www.tapko.de/fileadmin/_processed_/9/a/csm_Kaistack-for-Beck_d649bc3f40.jpg
hat nur die Sprache C im Angebot.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Carla Schneider]

Peter Heitzer wrote:

Helmut Schellong <var@schellong.biz> wrote:
Am 14.09.2023 um 16:17 schrieb Leo Baumann:
Am 14.09.2023 um 16:10 schrieb Helmut Schellong:
Jedoch noch viel ungeeigneter ist Assembler.

Assembler ist für ALLES perfekt geeignet, wenn man es kann.

Assembler ist für ALLES geeignet, aber für fast nichts _perfekt_ geeignet.
Man hat z.B. Zugang zu allen Instruktionen, die der Compiler nicht verwendet.
Assembler ist _keine_ strukturierte Programmiersprache mit übersichtlichem Quell-Code.
Mittels Makros kann man durchaus übersichtlichen Assemblercode schreiben.
Andererseits kann man in jeder höheren Programmiersprache auch
unübersichtlichen und kaum wartbaren Code schreiben.

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

 

[Carla Schneider]

Rolf Bombach wrote:

Wolfgang Allinger schrieb:

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

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

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.

Die erste Drehbank zu bauen war sicher auch nicht lustig.

 

[Carla Schneider]

Helmut Schellong wrote:

Am 14.09.2023 um 16:17 schrieb Leo Baumann:
Am 14.09.2023 um 16:10 schrieb Helmut Schellong:
Jedoch noch viel ungeeigneter ist Assembler.

Assembler ist für ALLES perfekt geeignet, wenn man es kann.

Assembler ist für ALLES geeignet, aber für fast nichts _perfekt_ geeignet.
Man hat z.B. Zugang zu allen Instruktionen, die der Compiler nicht verwendet.

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:
https://rjk.codes/post/building-a-frequency-counter/

Assembler ist _keine_ strukturierte Programmiersprache mit übersichtlichem Quell-Code.

Assembler wird heute nur noch auf Betriebssystemebene nennenswert verwendet.

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

Für Code im Kernel oder Funktions-Bibliotheken.
Für Anwender-Programme seit Jahrzehnten nicht mehr.

Im obigen Beispiel kommt es offenbar wieder.

> Ich selbst habe auch nur Funktions-Bibliotheken damit geschrieben (sehr lohnend!).

 

[Carla Schneider]

Volker Bartheld wrote:

On Thu, 2023-09-14 at 17:27 -0400, Wolfgang Allinger wrote:
BTW ich bin Bitpopler der ersten Stunden, also absoluter HardCore 
Assembler Programmierer. Ich käme nie auf die Idee, einen Editor in 
Assembler zu schreiben. Assembler ist für high speed, nix für lahmarschige 
Menschen, die an einer Klapperatur sitzen.

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.

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.

 

[Helmut Schellong]

Am 19.09.2023 um 00:50 schrieb Carla Schneider:

Helmut Schellong wrote:

Am 14.09.2023 um 16:17 schrieb Leo Baumann:
Am 14.09.2023 um 16:10 schrieb Helmut Schellong:
Jedoch noch viel ungeeigneter ist Assembler.

Assembler ist für ALLES perfekt geeignet, wenn man es kann.

Assembler ist für ALLES geeignet, aber für fast nichts _perfekt_ geeignet.
Man hat z.B. Zugang zu allen Instruktionen, die der Compiler nicht verwendet.

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:
https://rjk.codes/post/building-a-frequency-counter/


Assembler ist _keine_ strukturierte Programmiersprache mit übersichtlichem Quell-Code.

Assembler wird heute nur noch auf Betriebssystemebene nennenswert verwendet.

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

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.

Für Code im Kernel oder Funktions-Bibliotheken.
Für Anwender-Programme seit Jahrzehnten nicht mehr.

Im obigen Beispiel kommt es offenbar wieder.

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


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Axel Berger]

Carla Schneider wrote:

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.

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.


--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

 

[Marte Schwarz]

Hi Carla,

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.

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

 

[Marte Schwarz]

Hallo zusammen,

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

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