FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "

[Johannes Bauer]

On 22.08.19 00:47, Hanno Foest wrote:

Am 22.08.19 um 00:34 schrieb Johannes Bauer:

Wenn ich Assembler schreibe, kann ich mich immer *jedes* Compilers
bedienen.

Nein. Wenn du Assembler schreibst, dann schreibst du Assembler. Wenn du
einen Compiler Assembler schreiben läßt, dann kompilierst du. Das
Kompilat handzuoptimieren ist dann noch mal was anderes.

Hm, ich sehe einen Compiler durchaus als Werkzeug, sich Tipps und Ideen
zu holen.

Am Ende kommt zwar immer Assembler raus, aber der Vorgang ist ein
anderer. Jedenfalls, wenn man die Bedeutung von "etwas schreiben" nicht
zur Unkenntlichkeit verbiegen mĂśchte.

Es ist jedenfalls nicht abzustreiten, dass ich selbst in händisch
geschriebenem Assembler zumindest theoretisch die MÜglichkeit hätte,
jeden Compiler zu outperformen. Dass /ich/ das nicht kann und vermutlich
die allermeisten Programmierer ebensowenig, ist schon ein separates Thema.

Fakt ist, dass performance-kritischer Code sich heute immernoch an
Assembler bedient. Sieht man z.B. dutzendfach in OpenSSL. Oder bei djb's
Kryptocode. Oder bei BLAS.

Sicher. Und wie wurde der im Einzelfall erzeugt?

Händisch geschrieben, wenn du dir den anschaust. Bzw bei OpenSSL
schreiben die händisch ein perl-Skript dass dann ASM erzeugt. Also
nutzen quasi perl als Makroassembler. Der Curve25519 Code sah auch nach
handgeschriebenem Zeug aus. Ich finde jetzt djb's Sachen nicht, aber
hier ist ein Beispiel:
https://github.com/msotoodeh/curve25519/blob/master/source/asm64/amd64.masm/Mult.asm

Viele Grüße,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Johannes Bauer]

On 22.08.19 00:18, Alfred Gemsa wrote:

Mit Delphi kriegst du halt aber z.B. keinen Kerneltreiber implementiert.
Ist jetzt nur ein Beispiel, aber das habe ich schon gemacht.

Das musst du mir erklären, ich sag mal ins Blaue, das stimmt nicht.

Hmmm. Naja, wie wĂźrdest du das denn machen? Hier hat das mal jemand
gefragt:
https://stackoverflow.com/questions/2263474/can-i-write-windows-drivers-with-delphi-2010

Bei Linux wßsste ich gar nicht, wo man anfängt. Also dir fehlen ja alle
Language Bindings. Die konnte man glaube ich irgendwie kompatibel
deklarieren, wenn ich mich recht errinere. Ich hab mal Win32-API
Programmierung gemacht in Delphi und das ging auch irgendwie. Aber das
ist echt zu lange her.

Delphi habe ich frĂźher auch mal programmiert, insbesondere das GUI RAD
hat mir wirklich gut gefallen. Sowas gut gelĂśstes suche ich immernoch
vergeblich (obwohl GTK/Glade da mittlerweile fast, aber nur fast,
rankommt).



Der Wermutstropfen: Delphi kostet richtig viele Ocken, C-GUIs gibt es
meist fĂźr Umme.

Puh, in der Tat. Habe gerade mal nachgesehen, die Professional-Version
fängt bei 1.5kEUR an. Die nehmen's aber auch von den Lebenden. Als ich
Delphi programmiert habe, das war erst Delphi 1 bis Delphi 3 und später
irgendwann glaube ich Delphi 6, da hat das nie mehr als 300. Hm ja Mark
oder EUR? Weiß nicht mehr. Die Delphi 6 Personal glaube ich sogar 100,
ja EUR bestimmt oder.

Dass sich das so krass im Preis erhĂśht hat, ist echt schade. Kann eh
nicht verstehen dass Borland so verscherbelt wurde.

Viele Grüße,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Hergen Lehmann]

Am 22.08.19 um 00:34 schrieb Johannes Bauer:

On 22.08.19 00:12, Hanno Foest wrote:
Am 21.08.19 um 23:55 schrieb Johannes Bauer:

Handgeschriebens Assembler ist schon deswegen IMMER mindestens genauso
gut wie jede Hochsprache, weil ich einfach einen Compiler nehmen kann,
das zu Assembler runterkompilieren und dann meinen mindestens
gleichguten Assembler-Code habe.

Hä? Das ist wirr. Die Frage ist, ob du von Hand genausogut optimieren
kannst wie ein Compiler. Und das wurde schon vor 2 Jahrzehnten von
qualifizierter Seite bezweifelt - spätestens, wenn der Code
umfangreicher wird.

Wenn ich Assembler schreibe, kann ich mich immer *jedes* Compilers
bedienen. Also konkret: Ich habe die MĂśglichkeit, mein Programm durch
zig verschiedene Compiler zu assemblieren und *zusätzlich* die
MÜglichkeit, das zu verändern oder ganz neu zu schreiben. Deswegen ist
es notwendigerweise immer mindestens gleichschnell.

In der Praxis: Nein.
Zum einen ist der von einem optimierenden Compiler erzeugte Code oft nur
sehr mĂźhsam menschenlesbar. Zu anderen besitzt ein guter Compiler derart
viel Wissen Ăźber den internen Aufbau der Ziel-CPU und die optimale
Befehlsreihenfolge zur optimalen Ausnutzung der Parallelverarbeitung,
das ein Mensch da nur noch mit Versuch-und-Irrtum mithalten kann.

Man sich das fĂźr kurze, ganz besonders performancekritische
Codeabschnitte antun, aber nicht fßr ein vollständiges, nicht-triviales
Programm.

Hergen

 

[Johannes Bauer]

On 22.08.19 00:38, Hans-Peter Diettrich wrote:

Mein Argument war ja lediglich, daß C keine brauchbare
Entwicklungsumgebung ist.

C ist keine Entwicklungsumgebung.

C ist eine Programmiersprache.

Von jemandem, der Arduino fßr eine Programmiersprache hält, kann man
wohl nicht erwarten, den Unterschied zwischen den Zweien zu kennen.

Viele Grüße,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Johannes Bauer]

On 21.08.19 23:59, Hanno Foest wrote:

Am 21.08.19 um 22:05 schrieb Johannes Bauer:

Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen
IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima
funktioniert.

FĂźr bestimmte Werte von "prima".

Naja, ich habe ja geschrieben "im Großen und Ganzen". Und das stimmt
auch -- die Mehrzahl unserer Geräte läuft auf Linux heutzutage, die
ganzen Android Smartphones, quasi das ganze RĂźckgrat des Internet auch
(sowohl Server als auch Router).

Ja, sicherlich. Es tut irgendwelche Dinge. Ob gut, billig, effektiv,
nebenwirkungsfrei etc. ist vĂśllig egal, wenn man wegen der installierten
Basis, in die sich Änderungen und Erweiterungen einpassen müssen, kaum
Alternativen hat und infolgedessen die Programmierer auch keine kennen:

Naja, das glaube ich nicht so ganz. Im Business-Umfeld, wenn man mal von
embedded absieht, wird ja wohl auf der einen Seite .net gemacht und auf
der anderen Java. Von C und C++ ist da eher wenig zu spĂźren, meine ich.

NatĂźrlich ist es die Schuld des Werkzeugs, wenn es Fehler ermĂśglicht,
die mit einem anderen Werkzeug erst gar nicht vorkommen kĂśnnen. Was ist
das denn fĂźr eine Frage?

Das heißt, wenn ich mich mit einem Messer schneide, ist es die Schuld
des Messers, weil das mit einem anderen Werkzeug, dem LĂśffel, nicht
hätte passieren kÜnnen? Wenn ich mit meinem Auto einen Unfall baue, ist
es die Schuld des Autos, weil das zu Fuß gar nicht möglich gewesen wäre?
Ich bitte dich.

Sind denn dann folgerichtig eigentlich nicht alle Programmiersprachen,
in denen man bugbehafteten Code schreiben kann, deiner Argumentation
folgend, defekt?

Die Argumentation ist mir ein bisschen zu hilflos. Jedes Werkzeug hat
seine Vor- und Nachteile. Eine Kreissäge ist gefährlicher als ein
Fuchsschwanz. Und du wirst im Einzelfall abwägen, was fßr deinen
Anwendungsfall das geeignetere Werkzeug ist. Beides hat seine
Daseinsberechtigung.

und bei den Programmiersprachen mit unsicherem Umgang mit
Arbeitsspeicher ist C nun mal ganz weit vorne.

Klar. Und trotzdem wird C nach wie vor sehr häufig verwendet.

Windows wird auch sehr häufig verwendet. Liegt das an der ßberragenden
Qualität von Windows, oder an der installierten Basis, und daran, daß
die Leute nichts anderes kennen?

Microsoft hat mit Windows einige Sachen echt richtig gemacht: Zum
Beispiel die Abwärtskompatibilität war ein ßberzeugendes Argument. Dass
man sogar in Win95 noch DOS-Programme "einfach so" ausfĂźhren konnte. Das
ist nicht von der Hand zu weisen.

Google macht Chrome. Bei Google arbeiten mit Sicherheit viele der
brilliantesten Software-Designer.

Und trotzdem konnten sie nicht gut genug programmieren, um die 70%
high-risk bugs zu vermeiden, die ihnen C als Fußangel ermöglicht hat.
Bist du sicher, daß das ein Argument für C ist? Rat mal, wie das bei
schlechteren Programmierern aussieht.

Das sollte auch kein Argument fĂźr C sein, sondern, dass die Wahl der
Programmiersprache eben eine Wahl ist, bei der mehrere Dimensionen eine
Rolle spielen. Google-Ingenieure wissen sehr gut, dass korrektes C viel
schwieriger zu schreiben ist, als andere Programmiersprachen. Und
trotzdem sind die Vorteile derart ßberwältigend, dass sie es dennoch
gewählt haben.

Unter anderem, das muss man natĂźrlich auch dazu sagen, weil sie eben den
Tradeoff machen: Schnelle Software und dafĂźr vielleicht den einen oder
anderen Security-Bug in Kauf nehmen -- wohlweislich, dass Google ihre
Security sehr gut im Griff hat und extrem flott Patches ausrollen kann
und auch tut. Es ist halt alles ein Kompromiss, das ist nicht schwarz/weiß.

Oder, was ich fĂźr wahrscheinlicher halte: Es gibt knallharte GrĂźnde,
warum die diese Abwägung getroffen haben.

Natßrlich: Angesichts der Popularität von C bekommst du fßr ein
Großprojekt kaum genügend Programmierer für eine andere
Programmiersprache zusammen.

..net und Java. Ich hatte versucht, auf verschiedenen StellenbĂśrsen mal
Vergleiche anzustellen, aber die Zahlen sind gefaked, die da angezeigt
werden. Ist mir bei Stepstone und jobs.de passiert dass "Java
Entwickler" und ".net Entwickler" diesebe Anzahl an Treffern haben
(irgendwas hohes Vierstelliges), da ist was faul. Und die Seite von der
Arbeitsagentur macht bei 200 Ergebnissen dicht.

Also kann ich's nciht objektiv belegen, aber im Enterprise-Umfeld spielt
C so gut wie keine Rolle.

Und natürlich, daß Bugs nichts kosten (Unter anderem, weil sich die
Leute an sie gewĂśhnt haben. Alles ist kaputt. Isnumalso. Netter Talk zum
Thema: https://www.youtube.com/watch?v=pW-SOdj4Kkk).

Ah, ja den kannte ich schon. Ist ein guter Talk.

Im Augenblick ist es so, daß Softwarehersteller an Bugs Geld verdienen:
Sie sind ein Grund fßr Serviceverträge, Updates, neue Versionen. Ich bin
mit ziemlich sicher, daß die Softwarelandschaft deutlich anders aussehen
wĂźrde, wenn Bugs die Hersteller Geld *kosten* wĂźrden.

Zweifelsfrei. Das ist traurig, aber mittlerweile Realität. Da kann jetzt
aber C nichts dafßr. Die ganze SaaS Mentalität geht mir auch auf den
Senkel. Dass man z.B. Altium Designer nicht mehr kaufen kann, sondern
mieten muss. Ekelhaft.

Das ist genau das undifferenzierte Argument, das mich an der ganzen
Diskussion hier so ärgert: Wer C einsetzt ist einfach nur betriebsblind.

Wenn du hier komplett die Nachteile wegignorierst, bis zu dem Zeitpunkt,
wo ich sie dir an die Stirn tackere, ist das schon irgendwo
betriebsblind. Ich hingegen brauche nicht zu erwähnen, daß Dinge, die in
großem Maße eingesetzt werden, sicher irgendwo auch Vorteile haben: Das
ist selbstverständlich.

Halt, halt! Hier gilt, vÜllig ungelogen, nämlich fßr mich das EXAKT
selbe Gegenargument: Ich finde die Nachteile von C so derart und obszĂśn
offensichtlich (Speichersicherheit, Speicherverwaltung, Typsicherheit,
teilweise obskure Syntax z.B. switch/case) dass ich sie nicht erwähne,
weil sie jeder schon in- und auswendig kennt.

Man stelle sich vor, ich wĂźrde mich in d.s.e hinstellen und sagen:
"Schaut her, das hier ist der BESTE Transistor".

Nur hab ich nichts als bestes bezeichnet. Und auch nicht C als
schlechtestes. Deine Einstellung ist mir lediglich gegenĂźber C zu
undifferenziert kritiklos.

Nein, da hast du mein Argument definitiv in den falschen Hals gekriegt.
Ich plädiere lediglich dafßr, dass man fßr den Anwendungsfall
entscheiden sollte, was das geeignete Werkzeug ist. Damit es halt nicht
immer der Hammer ist, den man verwendet. Auf genau solche dogmatische,
undifferenzierte Einstellungen reagiere ich vĂśllig allergisch.

*Wenn* ich einen Tip fßr eine gute C-AblÜsung nennen sollte, wäre das
wohl Rust. Die Benchmarks sehen ganz brauchbar aus [1].

Rust oder Go, sehe ich ganz ähnlich. Sind mir beide noch zu wenig
"abgehangen" allerdings. Go gefällt mir persÜnlich besser von der Syntax
her, da finde ich Rust teilweise schon sehr anstrengend.

Aber ich kenn
das Dings nicht persĂśnlich, und vielleicht ist es lediglich die neueste
Sau, die durchs Dorf getrieben wird: Man wird es sehen. Nur finde ich es
etwas arm, daß wir seit 40 Jahren oder so die gleichen Fehler machen,
obgleich uns Software helfen kĂśnnte, diese Fehler zu vermeiden. Auf
welchem Wege auch immer.

Neue Programmiersprachen sind in den letzten 10 Jahren wirklich
inflationär erfunden worden. Und ich traue dem nicht so wirklich -- habe
mal vor Jahren D programmiert und fand das wirklich gut, aber wenn da
halt immer das Damoklesschwert "single source" Ăźber dem COmpiler
schwebt, will ich das nicht machen. Mono sieht auch schick aus, aber wer
weiß ob sich Microsoft da nicht irgendwann den Rappel kriegt und einen
Lizenzstreit lostritt, wie es bei Oracle/Java der Fall war.

Man muss aber schon auch dazusagen, dass selbst bei der ganz normalen
alten C-Programmierung sowohl die Werkzeuge extrem viel besser geworden
sind als vor 10-20 Jahren und damit auch die Bugvermeidung deutlich
einfacher ist als frĂźher. Die Diagostics vom Compiler sind so viel
besser, Konstukte die frĂźher Ăźblich/erlaubt waren sind jetzt (in C11)
deprecated, Tool-UnterstĂźtzung zum finden von UB (z.B. ubsan/asan) sind
EXTREM gut.

Aber man muss sie halt nutzen und zu nutzen wissen. Und zwar
idealerweise von Anfang an, weil wenn du erst drauflosentwickelst und
nach 50kLOC dann den ASAN anwirfst, wirst du vermutlich nicht mehr froh.

Viele Grüße,
Johannes

 

[Hanno Foest]

Am 22.08.19 um 00:34 schrieb Johannes Bauer:

Wenn ich Assembler schreibe, kann ich mich immer *jedes* Compilers
bedienen.

Nein. Wenn du Assembler schreibst, dann schreibst du Assembler. Wenn du
einen Compiler Assembler schreiben läßt, dann kompilierst du. Das
Kompilat handzuoptimieren ist dann noch mal was anderes.

Am Ende kommt zwar immer Assembler raus, aber der Vorgang ist ein
anderer. Jedenfalls, wenn man die Bedeutung von "etwas schreiben" nicht
zur Unkenntlichkeit verbiegen mĂśchte.

Fakt ist, dass performance-kritischer Code sich heute immernoch an
Assembler bedient. Sieht man z.B. dutzendfach in OpenSSL. Oder bei djb's
Kryptocode. Oder bei BLAS.

Sicher. Und wie wurde der im Einzelfall erzeugt?

Hanno
--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Alfred Gemsa]

Am 22.08.2019 um 01:17 schrieb Johannes Bauer:

On 22.08.19 00:18, Alfred Gemsa wrote:

Mit Delphi kriegst du halt aber z.B. keinen Kerneltreiber implementiert.
Ist jetzt nur ein Beispiel, aber das habe ich schon gemacht.

Das musst du mir erklären, ich sag mal ins Blaue, das stimmt nicht.

Hmmm. Naja, wie wĂźrdest du das denn machen? Hier hat das mal jemand
gefragt:
https://stackoverflow.com/questions/2263474/can-i-write-windows-drivers-with-delphi-2010

Ok, Standardmäßig geht's wohl nicht, but:

http://www.delphibasics.info/home/delphibasicsprojects/delphidriverdevelopmentkit

Zugegebenermaßen, ein Hack, ob's funktioniert?

Der Wermutstropfen: Delphi kostet richtig viele Ocken, C-GUIs gibt es
meist fĂźr Umme.

Puh, in der Tat. Habe gerade mal nachgesehen, die Professional-Version
fängt bei 1.5kEUR an. Die nehmen's aber auch von den Lebenden. Als ich
Delphi programmiert habe, das war erst Delphi 1 bis Delphi 3 und später
irgendwann glaube ich Delphi 6, da hat das nie mehr als 300. Hm ja Mark
oder EUR? Weiß nicht mehr. Die Delphi 6 Personal glaube ich sogar 100,
ja EUR bestimmt oder.

Dass sich das so krass im Preis erhĂśht hat, ist echt schade. Kann eh
nicht verstehen dass Borland so verscherbelt wurde.

Verstehe ich auch nicht, ich habe Delphi 7 Prof, das ist zwar schon
antik, aber dazu gab's auch noch einige Komponenten fĂźr digitale
Signalverarbeitung, mehr brauchte ich nicht.
(siehe z.B. http://www.gemsa-online.de/perseus/analyzer.html)

Alfred.

 

[Hans-Peter Diettrich]

Am 22.08.2019 um 01:10 schrieb Johannes Bauer:

On 22.08.19 00:38, Hans-Peter Diettrich wrote:

Mein Argument war ja lediglich, daß C keine brauchbare
Entwicklungsumgebung ist.

C ist keine Entwicklungsumgebung.

C ist eine Programmiersprache.

C ist nicht *eine* Programmiersprache, sondern gleich mehrere. Neben der
klassischen Precompiler-Sprache kommen heute aus der Toolchain noch make
und M4 hinzu, mit nochmal eigener Syntax. Zumindest haben mir das
eingefleischte C Programmierer so erklärt, als ich sie auf eine mÜgliche
Verbesserung der Toolchain angesprochen habe.

DoDi

 

[Hanno Foest]

Am 22.08.19 um 01:04 schrieb Johannes Bauer:

Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen
IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima
funktioniert.

FĂźr bestimmte Werte von "prima".

Naja, ich habe ja geschrieben "im Großen und Ganzen". Und das stimmt
auch -- die Mehrzahl unserer Geräte läuft auf Linux heutzutage, die
ganzen Android Smartphones, quasi das ganze RĂźckgrat des Internet auch
(sowohl Server als auch Router).

Ja, sicherlich. Es tut irgendwelche Dinge. Ob gut, billig, effektiv,
nebenwirkungsfrei etc. ist vĂśllig egal, wenn man wegen der installierten
Basis, in die sich Änderungen und Erweiterungen einpassen müssen, kaum
Alternativen hat und infolgedessen die Programmierer auch keine kennen:

Naja, das glaube ich nicht so ganz. Im Business-Umfeld, wenn man mal von
embedded absieht, wird ja wohl auf der einen Seite .net gemacht und auf
der anderen Java.

Allerdings erwähntest du oben konkret Linux, Android, das ganze Rßckgrat
des Internet, insofern ist das ein anderes Thema.

NatĂźrlich ist es die Schuld des Werkzeugs, wenn es Fehler ermĂśglicht,
die mit einem anderen Werkzeug erst gar nicht vorkommen kĂśnnen. Was ist
das denn fĂźr eine Frage?

Das heißt, wenn ich mich mit einem Messer schneide, ist es die Schuld
des Messers, weil das mit einem anderen Werkzeug, dem LĂśffel, nicht
hätte passieren kÜnnen?

Nicht alles, was hinkt, ist ein Vergleich. Wenn du schneiden willst,
wirst du wohl ein Werkzeug zum Schneiden brauchen. Aber wer braucht eine
Programmiersprache zur Erzeugung von Bufferoverflows? - Wenn du
unbedingt einen physischen Vergleich braucht, würde ich eine Schußwaffe
ohne Sicherung, aber dafĂźr mit besonders nervĂśsem Abzug nennen: Mag fĂźr
irgendwen nĂźtzlich sein, ist aber im Allgemeinen keine gute Idee. Auch
wenn sie billig ist, und Django damit noch eine hundertstel Sekunde
schneller.

Die Argumentation ist mir ein bisschen zu hilflos. Jedes Werkzeug hat
seine Vor- und Nachteile. Eine Kreissäge ist gefährlicher als ein
Fuchsschwanz. Und du wirst im Einzelfall abwägen, was fßr deinen
Anwendungsfall das geeignetere Werkzeug ist. Beides hat seine
Daseinsberechtigung.

Aber nur deswegen, weil die Erzeuger der Software nicht die Nebenwirkung
der hunderten Milliarden Schäden, die ich im Vorvorposting ansprach,
tragen muß. Privatwirtschaftlich ist das natürlich super: Die Schäden
trägt die Allgemeinheit, die Gewinne streicht das Softwarehaus ein.
Volkswirtschaftlich dĂźrfte das anders aussehen. Erinnert mich an
Umweltverschmutzung: Ist nicht eingepreist, interessiert uns nicht,
scheiß was drauf.

Wären die Schäden durch Sicherheitsprobleme besser eingepreist, wären
Programmiersprachen, die die weitaus größte Kategorie von Bugs
ermĂśglichen, kein Thema mehr. Software dreimal so langsam (und danach
sieht es nicht aus)? - Egal! Die Patches gegen Meltdown, Spectre, und
der Virenscanner auf dem Rechner schaffen das auch, und das stĂśrt keine Sau.

Insofern bin ich mir bezĂźglich der Daseinsberechtigung, jedenfalls
außerhalb von Nischen, nicht mehr so wirklich sicher.

Hanno
--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Hans-Peter Diettrich]

Am 22.08.2019 um 01:17 schrieb Johannes Bauer:

On 22.08.19 00:18, Alfred Gemsa wrote:

Der Wermutstropfen: Delphi kostet richtig viele Ocken, C-GUIs gibt es
meist fĂźr Umme.

Puh, in der Tat. Habe gerade mal nachgesehen, die Professional-Version
fängt bei 1.5kEUR an. Die nehmen's aber auch von den Lebenden. Als ich
Delphi programmiert habe, das war erst Delphi 1 bis Delphi 3 und später
irgendwann glaube ich Delphi 6, da hat das nie mehr als 300. Hm ja Mark
oder EUR? Weiß nicht mehr. Die Delphi 6 Personal glaube ich sogar 100,
ja EUR bestimmt oder.

Wenn man die Upgrade-Angebote annimmt, bekommt man heute RAD Studio Pro
immer noch für 500€. Oder man nimmt Free Pascal und Lazarus für lau,
wenn man nur OPL braucht.

Dass sich das so krass im Preis erhĂśht hat, ist echt schade. Kann eh
nicht verstehen dass Borland so verscherbelt wurde.

Mit Delphi 7 war der HĂśhepunkt erreicht, danach kam 10 Jahre lang nichts
nach. Das Produkt wurde mehrmals verkauft, und die Chefentwickler wurden
von Microsoft abgeworben. Seitdem weiß ich nicht so richtig, weshalb
sich ein Upgrade fĂźr mich noch lohnen wĂźrde. Die Inhaber wissen das wohl
auch nicht, aber solange sich noch Programmierer und Projekte finden,
die niemand auf andere Sprachen umstellen mĂśchte...

DoDi

 

[Johannes Bauer]

On 22.08.19 00:38, Hans-Peter Diettrich wrote:

Am 22.08.2019 um 00:00 schrieb Johannes Bauer:
[...]
gähn

Messung, Junge, Messung. Mach doch mal selber eine bevor du hier dummes
Geschäwtz ablässt.

Wenn Du meinst, daß Pascal Code mehr als 10% langsamer ist als C Code,
dann mach doch selber einen Benchmark, damit ich Deinen Quelltext
zerpflĂźcken kann.

Na dann zerpflĂźcke mal nach Herzenslust. Freepascal liegt im Bestcase
etwa 50% hinter dem gcc-Kompilat zurĂźck, bei den Keyschedules sogar etwa
350%.

https://github.com/johndoe31415/forthvsc/
https://github.com/johndoe31415/forthvsc/blob/master/rc4test.pas

Und jetzt, ja jetzt kommt garantiert nur heiße Luft von dir. Na, wer hat
das vorausgesagt, das Ergebnis? Kannst dich noch errinern? Tipp: Es
warst nicht du.

Echt so typisch. Immer die Leute die nix liefern können reißen das Maul
am weitesten auf und tönen groß rum. Der Allinger und du, ihr seid schon
echt vom selben Schlag. Pure Schwätzer, ekelhaft.

Alles Liebe,
Dein Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Johannes Bauer]

On 22.08.19 01:46, Hanno Foest wrote:

Naja, das glaube ich nicht so ganz. Im Business-Umfeld, wenn man mal von
embedded absieht, wird ja wohl auf der einen Seite .net gemacht und auf
der anderen Java.

Allerdings erwähntest du oben konkret Linux, Android, das ganze Rßckgrat
des Internet, insofern ist das ein anderes Thema.

Ja aber du schriebst doch, dass man keine Programmierer fĂźr was anderes
als C findet, und das stimmt doch nicht, weil die ganzen
Business-Informatiker eben Java und .net kĂśnnen. Oder hab ich dich da
falsch verstanden?

Die Argumentation ist mir ein bisschen zu hilflos. Jedes Werkzeug hat
seine Vor- und Nachteile. Eine Kreissäge ist gefährlicher als ein
Fuchsschwanz. Und du wirst im Einzelfall abwägen, was fßr deinen
Anwendungsfall das geeignetere Werkzeug ist. Beides hat seine
Daseinsberechtigung.

Aber nur deswegen, weil die Erzeuger der Software nicht die Nebenwirkung
der hunderten Milliarden Schäden, die ich im Vorvorposting ansprach,
tragen muß. Privatwirtschaftlich ist das natürlich super: Die Schäden
trägt die Allgemeinheit, die Gewinne streicht das Softwarehaus ein.
Volkswirtschaftlich dĂźrfte das anders aussehen. Erinnert mich an
Umweltverschmutzung: Ist nicht eingepreist, interessiert uns nicht,
scheiß was drauf.

Das ist ein interessanter und richtiger Punkt. Der ist meines Erachtens
allerdings nicht nur fĂźr sicherheitsrelevante Bugs zutreffend, sondern
fĂźr alle Arten von Softwarefehlern. Es gibt bei allen Produkten, die ich
kaufen kann, eine Gewährleistung nur bei Software ist es gang und gebe,
dass der größte dysfunktionale Rotz an den Konsumenten vertickt wird und
alle finden das okay. Ich bin da 100%ig bei dir, dass wir eben auch
Produkthaftung bräuchten fßr Software. Im Prinzip gibt es die ja schon
in Deutschland, aber in der Praxis ist mir kein Fall bekannt, wo mal
jemand zur Rechenschaft gezogen wĂźrde.

Allerdings, meine ich, kriegt man eben auch C sicher hin, wenn man das
Geld investiert: Zeitaufwand, Testaufwand, Testwerkzeug. Aber klar, wenn
Cisco einfach nur ganz schnell den neusten Router auf den Markt wirft,
dann ist da halt Softwarequalität offenbar nur sekundär. Wenn ßberhaupt.
Das ist wiederum der Gier der Konzerne geschuldet, Kapitalismus im
Endstadium eben.

Wären die Schäden durch Sicherheitsprobleme besser eingepreist, wären
Programmiersprachen, die die weitaus größte Kategorie von Bugs
ermĂśglichen, kein Thema mehr. Software dreimal so langsam (und danach
sieht es nicht aus)? - Egal! Die Patches gegen Meltdown, Spectre, und
der Virenscanner auf dem Rechner schaffen das auch, und das stĂśrt keine
Sau.

Virenscanner sind ja eh die größte Verarsche, die ich je gesehen habe.
So ein totaler MĂźll. Die haben es echt geschafft, die Verantwortung den
NUTZERN in die Schuhe zu schieben und kĂśnnen dieses ekelhafte "Produkt"
Virenscanner sogar noch VERKAUFEN. Das ist echt eine Meisterleistung.

Insofern bin ich mir bezĂźglich der Daseinsberechtigung, jedenfalls
außerhalb von Nischen, nicht mehr so wirklich sicher.

Ja naja, ich mag manche Aspekte von C und andere weniger. Wenn es geht,
programmiere ich mittlerweile am liebsten Python. Ganz ohne C kĂśnnte ich
glaube ich aber nicht, gerade dass es so ubiquitär ist ßber alle
Architekturen und Platformen hinweg, das macht es schon quasi zu einem
extrem guten Makroassembler.

Viele Grüße,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Johannes Bauer]

On 22.08.19 01:37, Hans-Peter Diettrich wrote:

C ist eine Programmiersprache.

C ist nicht *eine* Programmiersprache, sondern gleich mehrere. Neben der
klassischen Precompiler-Sprache kommen heute aus der Toolchain noch make
und M4 hinzu, mit nochmal eigener Syntax.

BWAAAAAAAAHAHAHAHAHAHA!

Und Make und Automake ist also fĂźr dich "C", ja? Spoiler Alert: Das hat
beides rein GAR NICHTS miteinander zu tun.

Make funktioniert ohne Autotools. C kompilieren kann ich mit meinem
Compiler. Nur weil viele Leute Makefiles benutzen, um C zu kompilieren
ist Make noch lange kein C. Genau wie viele Leute einen Editor
verwenden, um C zu schreiben, aber der Editor deswegen trotzdem nicht
zum Sprachumfang gehĂśrt. Das Letztere hast du ja schon bei Arduino nie
wirklich verstanden, weil da fĂźr dich IDE, Compiler und Flash-Tool alles
dasselbe war.

Mein Gott, aber muss man dir das echt erklären? Das ist ja entsetzlich.
Ich bin ehrlich einigermaßen schockiert über das schiere Verhältnis
zwischen dem deinem Unwissen und deiner Selbsteinschätzung ßber deinen
Wissensstand. Das sind locker 70, 80 vielleicht sogar 90 dB.

Zumindest haben mir das
eingefleischte C Programmierer so erklärt, als ich sie auf eine mÜgliche
Verbesserung der Toolchain angesprochen habe.

Ahahahaha oh Mann, ich fall fast vom Stuhl. Wäre ich da gerne dabei
gewesen, wie du deine "Verbessungsvorschläge" garantiert unaufgefordert
zum Besten gibst. Wie gerne hätte ich die Gesicheter der eingefleischten
C-Programmierer gesehen, wenn der KĂśnig der Ahnungslosen seine Perlen
der Weisheit unter's Fußvolk bringt.

Hast du noch mehr so gute Tipps von unschätzbarem Wert? Rechnet der KdA
den vim jetzt auch zu C hinzu? Fragen Ăźber Fragen!

Viele Grüße,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Ole Jansen]

Am 21.08.2019 um 23:14 schrieb Hans-Peter Diettrich:

Am 21.08.2019 um 21:29 schrieb Stefan Engler:

Jede Programmiersprache hat Nachteile und bei Pascal gibt es aufgrund
des Aufbau des Compilers einige wenige Anweisungen, die z.B. als sich
selbst modifizierendes Programm Ăźbersetzt werden.

In Plain Pascal?

> Huh? Sowas ist mir zumindest in Delphi noch nie begegnet.

Dort kÜnnte es schon eher sein. Es wäre eine zu vermutende Eigenschaft
von Compilern welche objektorientiertes Programmieren unterstĂźtzen.

> Kannst Du das belegen?

Konstrukte bei denen Programme mit Object Pascal
Code zur Laufzeit generiert gibt es z.B. in
Delphi Web Script und Innerfuse Pascal Script.
Evtl. ist sowas gemeint?

O.J.

 

[Volker Bartheld]

On Wed, 21 Aug 2019 22:33:16 +0200, Alfred Gemsa wrote:

Meine Lieblings-URL dazu ist
http://www.henning-thielemann.de/CHater.html
Lies das mal in Ruhe, und vielleicht auch einige weiterführende Links.

Welche Programmiersprache bevorzugt denn der C-Hasser? Das war mir bei all
dem Geifer jetzt nicht so gleich augenfällig geworden. "Es gibt etliche
Sprachen, die sich als Fortführung von C verstehen oder die auf
wesentlichen Schwächen von C aufbauen: C++, Java, C# usw. Diese eignen
sich allein aufgrund ihrer Syntax gut zum Hassen." brachte mich leider
auch nicht weiter.

http://www.henning-thielemann.de - ah: "Haskell". OK, keine weiteren
Fragen.

Ich habe 25 Jahre Delphi hinter mir, und es gab kein Problem, was nicht
zu lösen war

Allein die Strichpunkte in Delphi fand ich schon immer niedlich. Eigentlich
schon immer nach jedem Statement. Nach end. aber nicht. Und beim letzten
Statement vor dem end., da darf man, muß aber nicht. Und bei if-then-else
(warum eigentlich "then"?) nur nach dem else-Teil. Aber das sind
Marginalien.

Vol"Kaum, da ich einen Hammer besitze, sieht für mich alles wie ein Nagel
aus"ker

 

[Hans-Peter Diettrich]

Am 22.08.2019 um 03:14 schrieb Johannes Bauer:

> Mein Gott, aber muss man dir das echt erklären? Das ist ja entsetzlich.

Ja, ich finde Deine Einstellung auch entsetzlich :-(

DoDi

 

[Alfred Gemsa]

Am 22.08.2019 um 11:21 schrieb Volker Bartheld:

Allein die Strichpunkte in Delphi fand ich schon immer niedlich. Eigentlich
schon immer nach jedem Statement. Nach end. aber nicht. Und beim letzten
Statement vor dem end., da darf man, muß aber nicht. Und bei if-then-else
(warum eigentlich "then"?) nur nach dem else-Teil. Aber das sind
Marginalien
Du hast die If-Anweisung nicht durchdacht, sie lautet

IF bedingung THEN
anweisung1;

oder

IF bedingung THEN
anweisung1
ELSE
anweisung2;

sonst nichts.

Falls anweisung1/2 aus mehreren Teilen bestehen, sind diese mit BEGIN
und END zu kapseln, also z.B.:

IF bedingung THEN
BEGIN
anweisungen1
...
END;

oder

IF bedingung THEN
BEGIN
anweisungen1
...
END
ELSE
BEGIN
anweisungen2
...
END;

Jedes Konstrukt wird am Ende wie Ăźblich mit einem Strichpunkt
terminiert, also nicht nur der ELSE-Teil.

Da gips nix kryptisches.

Die einzige Ungereimtheit hast du richtigerweise genannt: Vor dem end.
braucht man keinen abschließenden Strichpunkt, aber wenn das alles ist...

Alfred.

 

[Hans-Peter Diettrich]

Am 22.08.2019 um 02:46 schrieb Johannes Bauer:

https://github.com/johndoe31415/forthvsc/
https://github.com/johndoe31415/forthvsc/blob/master/rc4test.pas

Auf den ersten Blick fällt auf, daß in dem Pascal Code ein UND durch
Modulo ersetzt wurde. Vermutlich bĂźgelt der Compiler das aus, es
bestätigt aber meine Meinung: Traue keinem Benchmark, den Du nicht
selbst gefälscht hast. Vielleicht werfe ich gelegentlich einen näheren
Blick auf den Code, was da sonst noch an Bremsen versteckt wurde.

> Der Allinger und du, ihr seid schon echt vom selben Schlag.

Ja, und nicht so hinterfotzig wie Du :-]

DoDi

 

[Johannes Bauer]

On 22.08.19 11:57, Hans-Peter Diettrich wrote:

Am 22.08.2019 um 02:46 schrieb Johannes Bauer:

https://github.com/johndoe31415/forthvsc/
https://github.com/johndoe31415/forthvsc/blob/master/rc4test.pas

Auf den ersten Blick fällt auf, daß in dem Pascal Code ein UND durch
Modulo ersetzt wurde.

Wenn du auch nur die geringste Ahnung von Compilern hättest, wßsstest
du, dass das zu äquivalentem Code fßhrt. Sogar bei Freepascal:

[...]
401165: 0f b6 87 00 01 00 00 movzbl 0x100(%rdi),%eax
40116c: 0f b6 14 07 movzbl (%rdi,%rax,1),%edx
401170: 0f b6 87 01 01 00 00 movzbl 0x101(%rdi),%eax
401177: 0f b6 04 07 movzbl (%rdi,%rax,1),%eax
40117b: 48 8d 04 02 lea (%rdx,%rax,1),%rax
40117f: 48 25 ff 00 00 00 and $0xff,%rax
401185: 8a 04 07 mov (%rdi,%rax,1),%al

Wäre dir auch aufgefallen, wenn du es ausprobiert hättest. Aber dafßr
bist du schlicht nicht in der Lage. Traurig.

Vermutlich bĂźgelt der Compiler das aus, es
bestätigt aber meine Meinung:

LOL, deine Meinung wird von einer falschen Vermutung also bestätigt.
Widdewidde wieeeeee sie mir gefällt...

Vielleicht werfe ich gelegentlich einen näheren
Blick auf den Code, was da sonst noch an Bremsen versteckt wurde.

Ja, mach das doch mal, du Spezialexperte. Ich hab mir im Übrigen das
erzeugte Assembler von sowohl C als auch Pascal angeschaut. Etwas, zu
dem du nicht mal ansatzweise in der Lage wärst.

Schon peinlich, wie einfach es ist, dir immer und immer und immer wieder
hochgradige Inkompetenz nachzuweisen. Mach dich nur noch weiter zum
Brot, damit auch noch der Letzte merkt, was fßr ein erbärmlicher
Schwätzer du bist.

<3
Johannes


--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Wolfgang Allinger]

On 21 Aug 19 at group /de/sci/electronics in article qjkktb$7eg$1@news.albasani.net
<gemsa@gmx.de> (Alfred Gemsa) wrote:

Verstehe ich auch nicht, ich habe Delphi 7 Prof, das ist zwar schon
antik, aber dazu gab's auch noch einige Komponenten für digitale
Signalverarbeitung, mehr brauchte ich nicht.
(siehe z.B. http://www.gemsa-online.de/perseus/analyzer.html)

Da tut sich bei mir nix, PING gemsa-online.de rund 250ms
aber ansonsten kütt nix
Auch nicht von gemsa-online.de, nur leerer screen.

Gruß an den fast neuen Unruheständler


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