Wirkungsgrad von 100 m RG213U

Am 22.09.2023 um 16:08 schrieb Carla Schneider:

Ja, irgendeine inkompatible Spielzeugscheiße

:)

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

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

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

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

:)

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

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

DoDi

oder in jeder anderen Hochsprache.

DoDi

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.

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.

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

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

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.

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.

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 erkenne auch da einen gewissen Wildwuchs ;-)

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

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

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.

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

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

DoDi

Dunkel ist der Sinn Deiner Frage :(

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

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

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

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'

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.

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.

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

Am 23.09.23 um 00:50 schrieb Hans-Peter Diettrich:

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

Vielleicht in C? ;)

Am 23.09.23 um 01:55 schrieb Wolfgang Allinger:

Von der alten Garde, sozusagen.

Nein, als ich den Fehler gemeldet habe hat sich herausgestellt, daß er ein paar Wochen vorher schon gefixt worden war. Ich habe allerdings vergessen zu fragen, wie lange der Fehler zuvor schon drin war.

Der Fehler tritt nur sehr selten auf, deshalb wurde er ja zuvor nicht bemerkt. Die ganze Geschichte ist schon über 10 Jahre her, allerdings habe ich seitdem auch nicht mehr kontrolliert. Es können sich also durchaus neue Fehler eingeschlichen haben, wie das bei unsicheren Programmiersprachen immer wieder vorkommt.

DoDi

Nein, beispielsweise # if defined(SV) && !defined(KR) || SK == 54 && (SK & 4) == 4 ist C.

Es gibt keine separate Präprozessor-Sprache. Der C-Standard beschreibt _nur_ die Sprache C.

Überwiegend nein, weil keine anderen Sprachen als C und ASM genügend schnellen Code generieren.