Wirkungsgrad von 100 m RG213U...

[Carla Schneider]

Leo Baumann wrote:

Am 22.09.2023 um 13:50 schrieb Carla Schneider:
Ich bin alergisch gegen C.
Alles was in Pascal geht, geht auch in C, aber man kann in C Dinge machen die
in Pascal nicht gehen.

In der Kombination Pascal-Assembler geht alles!

Alles was in Pascal nicht geht in Assembler schreiben - kann man natuerlich,
ist aber keine Gute Idee das oft zu machen wenn das Programm laenger leben soll als
die Hardware auf der es laeuft.

 

[Leo Baumann]

Am 22.09.2023 um 15:21 schrieb Carla Schneider:

Alles was in Pascal nicht geht in Assembler schreiben - kann man natuerlich,
ist aber keine Gute Idee das oft zu machen wenn das Programm laenger leben soll als
die Hardware auf der es laeuft.

Was interessiert mich die Portabilität - Wir haben den Weltcomputer PC,
x86 u.s.w.

 

[Helmut Schellong]

Am 22.09.2023 um 14:41 schrieb Stefan Ram:

Volker Bartheld <news2023@bartheld.net> writes:
Für denjenigen, der irgendwann in seinem Leben
LD IX,1234
LD (IX+6),7
benutzt hat, wirklich keine allzu große Transferleistung.

Ein wichtiger Unterschied zwischen Maschinenadressen und Zeigern
besteht darin, daß ein Zeiger einen Typ hat, und die Addition einer 1
zu einem Objektzeiger in C in Abhängigkeit vom Typ des Zeigers einer
Addition einer größeren Zahl in Maschinensprache entsprechen kann.

Dann sind Zeiger in C stärker eingeschränkt als Maschinenadressen,
um bestimmte Fehler zu vermeiden und portabler zu sein. So
können in der Regel nur Zeiger auf \"größer\" verglichen werden,
welche in dieselbe Reihung zeigen, ein Zeiger darf nur auf
bestimmte Funktionen/Objekte oder Stellen in einer Reihung zeigen
und nur unter bestimmten Bedingungen dereferenziert werden.

Zwei Zeiger dürfen miteinander nur verglichen (< > == !=) werden, wenn sie
vom selben Objekt stammen.
Ein Zeiger darf um _eine_ Position _hinter_ ein Array zeigen, darf dabei
aber nicht dereferenziert werden.

--
Mit freundlichen Grüßen
Helmut Schellong

 

[Andreas Fecht]

Am 22.09.2023 um 15:25 schrieb Leo Baumann:

Am 22.09.2023 um 15:21 schrieb Carla Schneider:
Alles was in Pascal nicht geht in Assembler schreiben - kann man
natuerlich,
ist aber keine Gute Idee das oft zu machen wenn das Programm laenger
leben soll als
die Hardware auf der es laeuft.

Was interessiert mich die Portabilität - Wir haben den Weltcomputer PC,
x86 u.s.w.

Bei den neuen Surface-Tablets vom Microsoft
haben einige schon einen ARM-Prozessor.

Gruß Andreas

 

[Leo Baumann]

Am 22.09.2023 um 15:39 schrieb Andreas Fecht:

Am 22.09.2023 um 15:25 schrieb Leo Baumann:
Am 22.09.2023 um 15:21 schrieb Carla Schneider:
Alles was in Pascal nicht geht in Assembler schreiben - kann man
natuerlich,
ist aber keine Gute Idee das oft zu machen wenn das Programm laenger
leben soll als
die Hardware auf der es laeuft.

Was interessiert mich die Portabilität - Wir haben den Weltcomputer
PC, x86 u.s.w.

Bei den neuen Surface-Tablets vom Microsoft
haben einige schon einen ARM-Prozessor.

Smartphone, Tablet, das fällt unter neumodisches Spielzeug für Kids

 

[Helmut Schellong]

Am 22.09.2023 um 15:25 schrieb Leo Baumann:

Am 22.09.2023 um 15:21 schrieb Carla Schneider:
Alles was in Pascal nicht geht in Assembler schreiben - kann man natuerlich,
ist aber keine Gute Idee das oft zu machen wenn das Programm laenger leben soll als
die Hardware auf der es laeuft.

Was interessiert mich die Portabilität - Wir haben den Weltcomputer PC, x86 u.s.w.

http://www.schellong.de/htm/math87.htm

Ich beschreibe dort, warum ich eine Assembler-Funktions-Library
Jahrzehnte später noch einmal entwickeln mußte.

Und zwar sind zwei Assembler-Kommandos miteinander nicht kompatibel, obwohl
beide für x86-Instruktionen bestimmt sind.
Ich schrieb die Library 1988 unter SCO-Unix386.

Diesmal habe ich sie als inline-Assembler in eine C-Datei geschrieben.
Somit ist sie auf Dauer innerhalb der x86-Welt portabel.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Carla Schneider]

Leo Baumann wrote:

Am 22.09.2023 um 15:39 schrieb Andreas Fecht:
Am 22.09.2023 um 15:25 schrieb Leo Baumann:
Am 22.09.2023 um 15:21 schrieb Carla Schneider:
Alles was in Pascal nicht geht in Assembler schreiben - kann man
natuerlich,
ist aber keine Gute Idee das oft zu machen wenn das Programm laenger
leben soll als
die Hardware auf der es laeuft.

Was interessiert mich die Portabilität - Wir haben den Weltcomputer
PC, x86 u.s.w.

Bei den neuen Surface-Tablets vom Microsoft
haben einige schon einen ARM-Prozessor.

Smartphone, Tablet, das fällt unter neumodisches Spielzeug für Kids

Wenn man eine Tastatur und einen Bildschirm anschliessen kann ist es
ein Computer.

 

[Leo Baumann]

Am 22.09.2023 um 16:08 schrieb Carla Schneider:

Smartphone, Tablet, das fällt unter neumodisches Spielzeug für Kids 😄
Wenn man eine Tastatur und einen Bildschirm anschliessen kann ist es
ein Computer.

Ja, irgendeine inkompatible Spielzeugscheiße

 

[Carla Schneider]

Leo Baumann wrote:

Am 22.09.2023 um 16:08 schrieb Carla Schneider:
Smartphone, Tablet, das fällt unter neumodisches Spielzeug für Kids ð???
Wenn man eine Tastatur und einen Bildschirm anschliessen kann ist es
ein Computer.

Ja, irgendeine inkompatible Spielzeugscheiße

Aber all die Microcontroller die man verwendet um Elektronik zu steuern...

 

[Leo Baumann]

Am 22.09.2023 um 16:20 schrieb Carla Schneider:

Leo Baumann wrote:

Am 22.09.2023 um 16:08 schrieb Carla Schneider:
Smartphone, Tablet, das fällt unter neumodisches Spielzeug für Kids ð???
Wenn man eine Tastatur und einen Bildschirm anschliessen kann ist es
ein Computer.

Ja, irgendeine inkompatible Spielzeugscheiße



Aber all die Microcontroller die man verwendet um Elektronik zu steuern...

Habe ich auch schon in C und Assembler gemischt programmiert ...

www.leobaumann.de/Main_A.txt

www.leobaumann.de/MAIN_C.txt

Läuft ehe nur auf einem P89V664 von NXP, aus Hardware-Gründen.

 

[Hans-Peter Diettrich]

On 9/22/23 10:54 AM, Stefan Ram wrote:

In Python ist es auch möglich, Teile einer Bibliothek oder
eines Programms zur Beschleunigung in C zu schreiben,

oder in jeder anderen Hochsprache.

DoDi

 

[Hans-Peter Diettrich]

On 9/22/23 10:07 AM, Stefan Ram wrote:

Carla Schneider <carla_schn@proton.me> writes:
Der Preprozessor ist auch kein Teil von C

Die Programmiersprache C wird durch die ISO/IEC 9899
beschrieben. Und diese Beschreibung umfaßt auch den
Präprozessor:

Wobei man erkennen kann, daß C und Präprozessor eine andere Syntax
haben, also unterschiedliche formale Sprachen darstellen.

|5.1 Conceptual models
|
|5.1.1 Translation environment
|
|5.1.1.1 Program structure
|
|A C program need not all be translated at the same time.
|The text of the program is kept in units called source files,
|(or preprocessing files) in this document. A source file
|together with all the headers and source files included via
|the preprocessing directive #include is known as a
|preprocessing translation unit. After preprocessing, a
|preprocessing translation unit is called a translation unit.

Wobei selbst das Einbinden der Standard-Header bereits die Benutzung der
Präprozessor-Sprache voraussetzt.

DoDi

 

[Hans-Peter Diettrich]

On 9/22/23 11:12 AM, Helmut Schellong wrote:

Ich hatte im Jahr 2000 rechts von mir einen Kollegen, Tarek, sitzen, der
mit Delphi programmierte.
Ich bekam mit, wie sehr er sich mit Delphi abmühen mußte.
Delphi verlangte dauernd krampfartige Zusatzarbeiten, wenn man z.B. nur
etwas
bitweise Undieren wollte.

Genau das ist eine Stärke von Delphi, mit Sets etc.
Natürlich muß man seine Sprache auch kennen, wenn man damit komfortabel
arbeiten möchte.

> Da gab es den Typ Kardinal, 29 Bit breit oder so - Hää?!

Quatsch mit Soße :-(
Du offenbarst immer mehr Deine Unkenntnis von Delphi. Da stellt sich
praktisch jeder Deiner Kritikpunkte an Delphi als tatsächlicher Vorteil
heraus! Mach nur weiter so ;-)

C/C++ ist mit int, long und long long <schauder> viel unpräziser als Delphi.

Wenn Du schon auf exotische Datentypen hinaus möchtest, da sind die
Delphi Subranges jedem anderen bit/byte-size Gehampel haushoch
überlegen. Ob die jemals Einzug in C++ halten werden? Vermutlich nicht,
wer zu viel C/C++ programmiert ist hoffnungslos in seiner Blase gefangen.

Ja, Delphi macht Tests zur Runtime.
Man merkt das deutlich!
Brauche ich nicht, ich sorge selbst für Vorabsicherheit, plausible
Werte, etc.

Das Schöne an den Runtime-Tests ist, daß man sie in den Projekt-Optionen
einfach global, unitweise oder lokal ein- und ausschalten kann, Debug
und Release Versionen ohne großen Aufwand. Zudem kosten die
Runtime-Tests so wenig Laufzeit, daß ich sie meist eingeschaltet lasse.
Wo bleiben denn solche Testmöglichkeiten in C/C++?

DoDi

 

[Hans-Peter Diettrich]

On 9/22/23 3:25 PM, Leo Baumann wrote:

Am 22.09.2023 um 15:21 schrieb Carla Schneider:
Alles was in Pascal nicht geht in Assembler schreiben - kann man
natuerlich,
ist aber keine Gute Idee das oft zu machen wenn das Programm laenger
leben soll als
die Hardware auf der es laeuft.

Was interessiert mich die Portabilität - Wir haben den Weltcomputer PC,
x86 u.s.w.

Deshalb braucht man dafür auch keinen Assembler mehr und keine
Interrupts, die laufen dort alle über das Betriebssystem. Womit die
Sprachmittel von Delphi/OPL für solche Targets völlig ausreichend sind.
Wer heute einen x86 in Assembler programmiert, der hat vielleicht noch
nicht mitbekommen, wie effizient ein Compiler so eine Architektur
ausnützen kann, mit Pipelines, register renaming usw.

DoDi

 

[Hans-Peter Diettrich]

On 9/22/23 10:49 AM, Hergen Lehmann wrote:

Am 22.09.23 um 00:23 schrieb Wolfgang Allinger:

Ein C-Programmierer sollte verstanden haben, was ein Zeiger ist, das ist
aber auch alles.

Wer nicht weiß, daß Zugriffe über Pointer nicht überwachbar sind, hat
die Konsequenzen nicht verstanden. Eine sichere Sprache kommt ohne
Pointer aus, ohne an Effizienz zu verlieren.

Nein, Du irrst. FORTH schaltet zwischen Interpreter und Compiler ständig
hin und her. Kommt drauf an, was da gerade im Eingabestrom gefunden wird.

Und wenn er compiliert, compiliert er in echten Maschinencode?

Ein Compiler erzeugt oft auch nur Aufrufe von Bibliotheksfunktionen. Da
kann threaded Code auch mal schneller sein. Und FORTH ist auch nicht
mehr das, was es mal war. Siehe auch Wikipedia zu Forth:
>>
there are modern implementations that generate optimized machine code
like other language compilers.
<<

Wie soll das gehen, bei einer Stack-orientierten Spracharchitektur und
Mikrocontrollern, deren Hardware-Stack teilweise auf eine handvoll
Ebenen beschränkt ist?

In welcher Sprache läßt sich so ein Zwerg programmieren, außer in Assembler?

DoDi

 

[Hans-Peter Diettrich]

On 9/22/23 10:31 AM, Hergen Lehmann wrote:

Am 22.09.23 um 00:45 schrieb Hans-Peter Diettrich:

Es gibt noch FreePascal/Lazarus, damit lassen sich auch µC programmieren.

Das ist dann aber kein Delphi mehr, sondern ein weiterer Dialekt...

Dialekt würde ich das nicht nennen, dann wäre jede neue C/C++ Version
auch wieder ein neuer Dialekt.

Das Blöde an Pascal ist, das die offizielle Entwicklung der Sprache Ende
der 80er Jahre (IEEE/ANSI 770X3.160-1989) stehen geblieben ist

Delphi hat in den 90er Jahren einen gewaltigen Schub (OPL) gegeben. Seit
D7 fehlt mir eigentlich nichts mehr an diesem Entwicklungspaket.
FreePascal/Lazarus hat noch weitere Plattformen und Compiler
hinzugefügt, was im Laufe der Zeit für jede compilierte Sprache
notwendig wird.

und
danach nur noch Wildwuchs herrschte, mit zahlreichen Queranleihen
zwischen den Entwicklungslinien, aber keiner garantierten Portabilität.
Wenn der (englische) Wikipedia-Artikel stimmt, hat FreePascal selbst
heute noch keine vollständige Kompatibilität zu der o.g. Norm... :-(

Welche Norm?

Pascal war ein einfaches Lehrstück für den Compilerbau. Deshalb wurden
Bibliotheken nicht zum Sprachumfang hinzugenommen, da sie mit dem selben
Compiler übersetzt werden können. Deshalb war jeder Implementierer eines
praxistauglichen Systems gezwungen, eigene Bibliotheken hinzuzufügen
oder (besser) irgendwo abzustauben. Mit $MODE DELPHI sollte FP
eigentlich alle Delphi-Programme verdauen. Seit der Entscheidung der
Embarcadero-Entwickler für ein untaugliches Multi-/Unicode Konzept ist
das Stringhandling nicht mehr kompatibel. Wobei FPC mit der Verwendung
von UTF-8 keinerlei Probleme mit älterem Code hat, im Gegensatz zu
Delphi-Xy.

 Die Architektur ist unerreicht was Projekt-Management,
turn-around Zeiten und Fehlersuche betrifft. Aber wer nur C kennt, der
weiß nicht, was ihm in dieser Hinsicht alles entgeht.

Hey, Pascal war meine erste höhere Programmiersprache! Ich habe während
Schule, Studium (Nebenjobs) und in den ersten Berufsjahren viel in Turbo
Pascal und auch ein wenig Delphi gemacht.

Ich bin auf dem ST erstmals mit Pascal in Berührung gekommen und war
nicht besonders begeister von dieser Implementierung. Dagegen war ich
mit Borland CBuilder ganz zufrieden, auch wenn die Bibliotheken im
Beta-Test noch einige Probleme aufwiesen. Auf dem PC ließen sich damit
jedenfalls mehr als 50 Fehler in den SDK Samples von MS nachweisen,
Compiler waren schon immer eine der Schwachstellen von MS. Das hat sich
erst mit C# geändert, nachdem MS die Delphi-Entwickler abgeworben hatte.

Zu Delphi bin ich erst mit D4 gekommen und war absolut begeistert davon.
Davor habe ich privat und auch beruflich (gezwungenermaßen) in Basic
programmiert, strukturiert bis OO, und war von da schon etwas verwöhnt,
was die Möglichkeiten zu Fehlersuche bzw. -Vermeidung betrifft. In C
habe ich den umgekehrten Eindruck, da steigen die Möglichkeiten zur
Fehlererzeugung eher an. Zugegeben, C++ leidet an dem freiwillig
auferlegten Erbe und erklärter Kompatibilität mit C, wo Typsicherheit
ursprünglich überhaupt keine Rolle gespielt hat.

Ein Schmankerl zur Fehlersuche:
Bei der Konvertierung eines Komprimierungsprogramms (zip?) von C nach
Delphi bin ich auf einen Fehler gestoßen, der schon 10 Jahre lang
unentdeckt im Quelltext gelauert hat. D.h. nicht ich habe den Fehler
gefunden, sondern der Compiler.

Ich war dann aber ehrlich gesagt froh, davon weg zu kommen, habe
allerdings C nur gekratzt (für einige uC-Projekte) und für die dicken
Projekte gleich mit C++ weiter gemacht. Wenn ich mir den aktuellen
C-Standard ansehe, ist da aber inzwischen viel zurück geflossen und
einige Dinge sind sogar schöner gelöst als in C++.

Ich erkenne auch da einen gewissen Wildwuchs ;-)

Beide Sprachen leben, was man von Pascal, FORTH, etc. nicht behaupten
kann.

FORTH war unverzichtbar für meine Mikroprozessor-Systeme, privat und
beruflich, und sogar zur Fehlersuche auf einer pdp-11/34 geeignet. Was
mich schon damals am meisten gestört hat, war der Write-Only Code und
der Mangel an Standard-Bibliotheken.

Mit OPL bin ich völlig zufrieden, da fehlt es an keinem Sprachmittel.
Und mit dem Tandem Delphi/CBuilder wäre ich restlos glücklich, wenn da
nicht der Wildwuchs im C/C++ Standard wäre, der ständig neue C++
Compiler erforderlich macht.

Nur meine Arduinos programmiere ich noch in C/C++, für Kleinkram reicht
das allemal.

DoDi

 

[Hans-Peter Diettrich]

On 9/22/23 1:50 PM, Carla Schneider wrote:

Alles was in Pascal geht, geht auch in C, aber man kann in C Dinge machen die
in Pascal nicht gehen.

Alles was in C geht, geht auch in Assembler...

Je schlabbriger eine Sprache wird, desto einfacher wird es, Fehler ins
Programm einzubauen. Muß jeder selbst entscheiden, was er lieber haben
möchte.

DoDi

 

[Wolfgang Allinger]

On 22 Sep 23 at group /de/sci/electronics in article 650D324B.1EC4A3D7@proton.me
<carla_schn@proton.me> (Carla Schneider) wrote:

Wolfgang Allinger wrote:

On 21 Sep 23 at group /de/sci/electronics in article
650C329F.14B4EC2C@proton.me <carla_schn@proton.me> (Carla Schneider)
wrote:

Wolfgang Allinger wrote:

On 21 Sep 23 at group /de/sci/electronics in article
uegt1gUl1fuL1@news.in-ulm.de <spamless@gmx.de> (Holger Schieferdecker)
wrote:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man
nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber
siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird
nichts weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte
ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9.
Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

C tut weh! (*)

Der C-Programmierer hat den Compiler im Kopf.
Der FORTH-Programmierer hat den Compiler im Target.

Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als
unlösbar.
Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und
veröffentlich das in der \'Vierten Dimension\'

(*) C ist zB: (*(void(*)())0)()

Ueblicherweise macht man noch einen ; dahinter dann wird die Funktion
aufgerufen die an Adresse Null liegt.

Hab das ; weggelassen, da IMHO nicht relevant

Ist FORTH eine Sprache in der das Newline diese Aufgabe uebernimmt ?

Dunkel ist der Sinn Deiner Frage

Auf einem PC gibt das ein Segmentation
fault, aber ich will nicht ausschliessen dass es Systeme gibt wo an
Adresse 0 eine wichtige Funktion liegt die er auf diese Weise aufgerufen
hat, vielleicht ein Restart des gesamten Systems, bei Mikrokontrollern ist
ja manches moeglich.

Einige uC haben an der Adresse 0000 einen Vector auf die Kaltstartroutine.
Hab bei diesem Speibiel vergessen, was es für ein uC war.

Für mich sind i.a. alle uC gleich bzw. ähnlich, da ich mit FORTH
arbeite(te)

Und wie sieht dieser Aufruf in FORTH aus, nur so zum Vergleich ?
Wenn ich mich recht erinnere ist das eine Sprache die so um 1990 herum
populaer war.

Ich benutze FORTH seit 1980 (nach dem BYTE Heft Aug. 1980 mit FORTH)

Er wollte halt nicht extra einen Pointer auf eine Funktion definieren,
dort eine Null reinschreiben und sie dann aufrufen und dadurch ein paar
Byte einsparen.

Gemeint ist natuerlich dort die Adresse hineinschreiben die auf Adresse
gespeichert ist.



Auflösung auf Anfrage

Du hast es recht gut getroffen.
in Z80 Assembler:
LD HL,0000h
JMP (HL)

Ist nicht genau das gleiche weil kein Funktionsaufruf, aber egal
weil der Hardware-Reset den Stapel auf Null setzt.


Also die SW Emulation eines HW PWR up


Waere also etwas das in den Libraries zu diesem System
drin sein sollte, z.B. als Funktion mit Namen \"hw_reset\".

Weil es das offenbar nicht war, musste
sich der Programmierer so abhelfen.

Das ganze ist aber kein Beispiel dafuer das zeigt
ob FORTH besser ist als C oder umgekehrt.

Doch. In FORTH definiere ich in eine Datei...
: HWreset 0 EXECUTE ; \\ simuliert einen HW reset

Wobei das latürnich kein echter HWreset ist, da einiges nur mit einem
echten PWRup initialisiert wird, oder auch nicht.

Ich schreibe schon seit vielen Jahren eine ICEcold Routine, die alles so
setzt, wie der echte HW reset mit der Besonderheit, dass sogar
undefinierte Zustände mit 0 oder -1 gesetzt werden, je nachdem...
Also alle Register, Memory, Ports...
Ja das kann länglich werden, aber ist extrem hilfreich.

und führe das einfach durch \'HWreset\' im Eingabestrom aus.

Also von Klapperatur, Datei...

Eingabestrom ist alles, was als Input reinkommt.
Kann Klapperatur, Datei oder was weis ich sein.
FORTH könnte auch MORSE-Zeichen verstehen.
Muss man nur als Worte schreiben.
Ich würde es mit CREATE DOES> beschreiben.
Vermutlich gibbet das schon irgendwo.
Oder auch jede beliebige Sprache.
FORTH ist völlig offen und hat alles an Board, um neue Worte (Funktionen)
in beliebigen Worten bechreiben. Ein Wort wird im Eingabestrom durch white
space getrennt.

Chuck Moore hat seinerzeit FORTH erfunden und da ihm klar war, dass er
nicht allumfassenden Funktionen erfinden kann, hat er aus der Not eine
Tugend gemacht und FORTH so gemacht, dass man es beliebig und
allereinfachst erweitern kann.

Forth ist Assembler, Interpreter, HLL Compiler und Metasprachen Script und
und und.

Ein Projet ist dann feddich, wenn alles als Worte definiert ist, was man
gerade braucht und nicht schon an Board ist.

Am besten die Definitionen in der Sprache des Anwenders.

Für Küche und Zirkus gäbs bei mir u.a. \'Messer\' \'werfen\'
Die Worte Kochen, Gasherd, Backofen, Pfanne, Minuten, Grad Celsius....
würden beim Zirkus wohl nicht drinstehen.

Wenn der Anwender usanisch will, dann eben
Cooking, gasowen, owen, pan, minits, degree Fahrenheit...



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

 

[Wolfgang Allinger]

On 22 Sep 23 at group /de/sci/electronics in article f210uj-u7rc3.ln1@hergen.spdns.de
<hlehmann.expires.12-22@snafu.de> (Hergen Lehmann) wrote:

Am 22.09.23 um 00:23 schrieb Wolfgang Allinger:

On 21 Sep 23 at group /de/sci/electronics in article
4eqttj-u7rc3.ln1@hergen.spdns.de <hlehmann.expires.12-22@snafu.de> (Hergen
Lehmann) wrote >> Ich arbeite heute zwar überwiegend mit C++, aber auch zu
C-Zeiten habe
ich nie ein Programm von Hand compiliert.

Damit war gemeint, dass der C-Programmierer im Kopf haben muss, was der
Compiler veranstaltet.

Ein C-Programmierer sollte verstanden haben, was ein Zeiger ist, das ist
aber auch alles.

Mehr Lowlevel-Kenntnisse sind nur erforderlich, wenn man tatsächlich
hardwarenah programmiert. Dann ist es aber gerade ein Vorteil, das der
Zusammenhang zwischen Quellcode und Maschinencode nachvollziehbar bleibt.

Wenn mich meine Erinnerung nicht täuscht, \"compiliert\" FORTH lediglich
in eine Art Zwischencode, welcher auf 99.9998% der verfügbaren Hardware
anschließend interpretiert wird.
Es gab zwar mal auf FORTH optimierte Hardware, aber das war eine Nische
in der Nische in der Nische.

Nein, Du irrst. FORTH schaltet zwischen Interpreter und Compiler ständig
hin und her. Kommt drauf an, was da gerade im Eingabestrom gefunden wird.

Und wenn er compiliert, compiliert er in echten Maschinencode?

Jein, der Forth Compiler stellt gefädelte Wort-Listen auf, also eine Liste
mit Adressen. Unter diesen Adressen sind dann wieder Listen von Listen,
die Listen von Listen sind... bis irgendwann ein sog. Primitive dabei ist.
Ein Primitive ist eine ASS routine, die auch in FORTH Assembler
geschrieben sein kann...

Also wie im wirklichen Leben, ein Befehl wird gegeben, FORTH sucht dann im
Wörterbuch, ob es den Befehl kennt, wenn ja gehts dahin. Und diese Listen
hangeln sich so durch... bis primitive...

Wenn das Wort nicht im Wörterbuch steht, wird untersucht, ob es ein Zahl
in der aktuell eingestellten Zahlenbasis ist (wg. mir 2, 3, 4, 8, 10, 16,
36 oder was auch immer ist) Wenn ja, wird die Zahl auf den (Parameter)
Stack gelegt und da nächste Wort wird abgehampelt.

Wenn nicht meckert FORTH: ...is undefined und löscht Parameter und Return
Stack.

wenn nix mehr anliegt, prompted FORTH \'ok\'

Wie soll das gehen, bei einer Stack-orientierten Spracharchitektur und
Mikrocontrollern, deren Hardware-Stack teilweise auf eine handvoll
Ebenen beschränkt ist?

Die Forth Engine (hat nur 6 Elemente!) besteht aus rund 30 Primitives, die
im Maschinen Assembler geschrieben sind und dann eben die FORTH engine
darstellen. Alles oberhalb ist in HLL definiert.

Aber er hat was vorzuweisen. Typischerweise ist ein Forth Programmierer
2-30! mal produktiver, als ein C-Programmierer.

Ja, für Rapid Prototyping kleiner Sachen hat eine Interpreter- oder
JIT-Sprache Vorteile. Nicht umsonst hat Python in den vergangenen Jahren
einen Siegeszug hingelegt.

Das ändert sich aber schnell, wenn die Projekte umfangreicher werden,
wenn auf Performance optimiert werden soll, oder wenn in kommerziellen
Projekten eine Weitergabe des Quellcode ausdrücklich unerwünscht ist.

Auch das kann man in FORTH einfach verriegeln: Outer Interpreter (der
Eingabstrom Parser) abschalten. Wenn man dann noch das dictionary löscht,
ist Ende im Gelände für Abkupferer, definitiv.

Ich hab etliche Projekte als Rapid-Prototyping gemacht, die dann
anschließend in eine andere Programmiersprache umgesetzt worden
Also scheinbar nicht so wirklich Produktions-tauglich?

Doch, latürnich, wenn der Prototyp funzt, dann ist die Applikation fertig.

Ich hab geschätzt 400 Projekte in meinem Leben gemacht, die letzten 300
alle in FORTH

Bin von Haus aus HW-bitpopler, Hardcore-Assemblierer und Elektroniker.


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

 

[Hartmut Kraus]

Am 23.09.23 um 00:50 schrieb Hans-Peter Diettrich:
> Bei der Konvertierung eines Komprimierungsprogramms (zip?) von C nach Delphi bin ich auf einen Fehler gestoßen, der schon 10 Jahre lang unentdeckt im Quelltext gelauert hat. D.h. nicht ich habe den Fehler gefunden, sondern der Compiler.

Nicht schlecht. Ausgerechnet ein Komprimierungsprogramm, wie sie massenweise eingesetzt werden. Ist der Fehler noch drin? Oder kriegt man mit der \"fehlerfreien\" Version Dateien, die mit der \"fehlerhaften\" gepackt sind, nie wieder entpackt ...

--
\"Man sollte keine Dummheit zweimal begehen, die Auswahl ist schließlich groß genug.\" (Jean-Paul Sartre)

https://hkraus.eu/hk/Profil.pdf