Am 17.08.2019 um 13:53 schrieb Wolfgang Allinger:
diskutieren :-(
DoDi
Am 17.08.2019 um 13:53 schrieb Wolfgang Allinger:
diskutieren :-(
DoDi
Ja wie in jeder Skriptsprache halt. Dass du das so besonders findest, wundert mich.
nur C sondern eben auch alle anderen Programmiersprachen, die llvm beherrscht (C++, go, Haskell, Fortran, Rust, Javascript, Ruby, C# um nur
dass 30 Jahre Programmiersprachenentwicklung scheinbar spurlos an dir
Standard-Sprachumfang verwendest. Ziemlich unglaublich, dass du das
kann.
Nein.
Deine groben zusammengelogenen Faustformeln interessiert kein Mensch.
und sag wie viel der braucht. Stattdessen schwadronierst du nur rum, kriegst es aber nicht gebacken auch nur EINE belegte Zahl zu nennen.
Noch mehr dahergefibertes Gelaber. Ich habe gemessen: C = 1, Forth =
500. Alles dokumentiert, der Code offen, die Messmethode dazu. Und du kriegst es nicht widerlegt. Komisch, oder? [mehr fibriges Gelaber gesnippt]Ich habe nie behauptet, dass jemand, der Forth verwendet, ein
demonstriert und objektiv belegt, dass Forth deutlich langsamer (Faktor
Johannes
Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA!
Respekt, Respekt, du bist ja ein echter Spezialexperte.
Glaub es mir einfach!!!1111elf
Aaaaaaaaah ja klar, der NDA hindert dich daran, ein Hello World
Das kommt ja wohl aufs Target an. Du erzeugst Bytecode und der wird
Bytecode von Interpretation.
Na dann faktenchecken wir doch mal deine Behauptungen. Der RTX2000 ist
ISR auch wieder verlassen, da geht deine letzte Instruktion hin.
FORTH halt nun mal ohne Spezialhardware (Forth im Core) langsam ist, deutlich langsamer sogar manchmal (Faktor 500...) als C.
Niemand bei Verstand erwartet etwas anderes. Nur du tust so, als ob Forth die eierlegende Wollmichsau ist. In der Gruppe hier sind quasi nur Ingenieure. Die durchschauen dein Zelotentum ALLE.
gibt halt intellektuell grundlegend unehrliche Leute wie du, die einfach Fakten wegignorieren, die ihnen nicht passen.
Joa das war ja auch meine Aussage. Zitat "irgendwelchen Spezialanwendungen Hardware gebaut wurde, die das performant interpretiert".
Nur ist die Welt halt nicht so: Alle modernen Prozessoren sind eben
sich durchaus weiterentwickelt. Dann hat man halt auch mehr Auswahl an Hardware als nur n Paar obskure Spezialprozessoren.
Was soll denn ein "C Kern" sein? Hast du auch nur die leisteste Ahnung
mal retargetiert, ja, und der kann dann u.a. C kompilieren. Ist nicht
die weder "zukaufen" muss noch selber machen.
einen C Compiler gibt, ohne dass man was erstellen muss?
Johannes
Wolfgang
-- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
Dummbatz.
nicht... wg. NDA sabbelst Du was von Hello World und Geschwurbel?
Nein, ist Eigenheit von Forth
Und Forth hat zwei Interpreter, den inner und den outer interpreter. Der
nennen, obwohl das bei FORTH noch wal wieder was ganz anderes ist.
Wenn ich das noch richtig im Kopf habe, macht der RTX den 'RETI' ohne
25a her, dass ich das zuletzt gemacht habe.Au, jetzt legste aber dreist zu. Ich les noch ein bischen, aber...
[...] [...][...] [...]
einzelne Seele in 1-3 Tagen.
Nochmal ...leck mich und hasta la vista
Wolfgang
-- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
aus den Augen und mach dich nicht doch nicht weiter zum Brot. Und die
weder interessant noch relevant.
Du laberst und laberst und laberst und laberst, aber kriegst es nicht gebacken, ein WINZIGES Programm zu testen und die objektive Messung,
um dich. Du warst bestimmt auch schon immer jemand, der bei "Mensch
Niemand hat bestritten dass FORTH auf Spezialhardware (z.B. RTX20xx)
geeigent sein kann. Niemand hat bestritten, dass es Leute gibt, die RPN
bedienen ist.
Das EINZIGE Argument war, dass FORTH auf einer 08/15 Architektur (z.B.
tut. Und das Argument war dir sogar extensiv belegt worden.
Und nichtmal damit kommst du klar und interpretierst jegliche objektive
einem so unsachlich argumentierenden, hochnotpeinlichen Choleriker nicht zusammenarbeiten muss.
Gute Besserung und alles Liebe, Dein Johannes
Johannes Bauer :
Eure Stilfragen beiseite, sei festgehalten, dass die obige Prozedur nicht korrekt ist.
selbst auch miserablen Stil zelebriert. Wahrscheinlich, weil der Blick nur
ein C-Compiler irgendwo mitlief, das scheint immer noch so zu sein. Offenbar sehr zu ungunsten der Resultate. Akademische Spielkiste.
Der Unterschied: Subroutinen in Forth verbrauchen wenig Overhead, indem
jede Forth-Routine (Forth-Wort) einen neuen Stackframe einrichtet, dann ist die Brauchbarkeit ziemlich im Eimer.
auf den Hardware-Bus und die Devices des Rechners.
darf der eigentlich kindlichen Bindung an ein ewiges ozeanisches Wogen gern der Rest der Welt als entweder bedrohlich oder verabscheuungswert vorkommen.
Kannma schon. Wenn es nur darum geht, muss man das nicht weiter ernstnehmen.
Hmm, naja wie gesagt, wenn es etwas besseres gibt auf FORTH-Seite, dann
10 langsamer als C), aber der Faktor 500 hat mich schon sehr erschreckt. Insbesondere weil gforth von Wolfgang selbst als reife Implementierungaufstellt. Wenn der aber keine Aussage machen kann oder will, dann muss er sich nicht wundern wenn ein Fachfremder Messungen macht, die halt (aus purem Unwissen heraus) nicht das Optimum herauskitzeln aus der Implementierung.
Welcher Overhead wird wo gespart? Und gilt das dann nur bei Unterroutinenaufrufen? Da wird in der Regel bei einem modernen, guten C Compiler auch kein Stackframe erzeugt, wenn das nicht notwendig ist.
Auf dem kann ich aber nicht testen :-)
Hm, ne, darum geht's nicht. Allgemein sind das keine Kategorien
Eine Technologie (z.B. Programmiersprache) hat Vorteile und Nachteile. Es ist gemeinhin klar, dass *alles* ein Kompromiss darstellt.
der Werkzeuge und Hardware, Gehalt der Ingenieure die man braucht, usw usf. Das gilt ganz allgemein.
Wenn sich jetzt einer hinstellt und sagt, Technologie X ist in ALLEN
nehme sie halt in Kauf, weil ich im Embedded-Bereich meistens eben damit insgesamt noch am besten fahre.
Johannes
Nun ja, Forth ist eher schon eine Lebensanschauung und der bin ich in weiten
bei Desktopzeugs einfach bessere Karten. Aber zu Zeiten, als ich auch noch die Stringroutinen des awk je nach Bedarf in Forth nachgestellt habe, ging das so, dass der Mensch eben mit seinem Werkzeug zienlich eng verwachsen
z.B. Primzahlen rechnen lassen, das ging dann mehr und mehr in Assembler.
Secondaries stehen (also in Forth-Worten, die aus Tokens bestehen).
Output eines Compilers konsumiert als wie eine Service-Leistung.
Ebene ist das auch eher die Vorstellung von ihrem Zielpublikum, siehe die
Payware mit etwas Vorlaufzeit zum Evaluieren und Kennenlernen (und dann gibt es zumindest noch weitere Elaborate, etwa aus Southampton).
von kurzen Routinen, plus die Wirkung des Optimizers.
Derart langsam finde ich das auch inakzeptabel. Hatte einst eine Idee von Langsamkeit, als bei mir ein Forth-Interpreter, mit sehr wenig Assembler
500 langsamer - vielleicht, hab's nicht gemessen. Hab mich nur dabei nettDunkel nebelt durch die Erinnerung ein Modell heran, wo ad hoc je ein Forth-Wort per C zu einer Sammlung von anderen kompiliert wurde, und dann eben brav die Maschine mit zwei Stacks auf der Maschine mit nur einem Stack
Laufzeitumgebung an die Parameter, die auf dem Forth-Stack liegen sollten, der aber erst einmal zu emulieren ist, wenn der eine Stack zugleich der
Wollte jetzt nicht die gefinkelten C-Compiler dagegenhalten.
Wenn man das nicht will, schreibt man mit Variablen (oder Local Values) und
ROT TUCK OVER usw.
Denkweise ist ein wenig anders als beim Algebra-fixierten Mainstream.
Andersherum, ein paar Variablen, dann werden die Parameter nicht mehr anonym auf dem Stack herumgeschoben, weil dann die Namen im Quelltext stehen.
Solange man aber mit dem Stack auskommt, ist vor allem einmal ein Vorteil, dass der Code nach Belieben reentrant ist, es also keine Nebenwirkungen bei
Local Values, aber die gehen dann in die Richtung, dass ein Frame bei Aufruf zwischengesichert werden und beim Verlassen wieder restauriert werden muss -
der Zwischenzeit, nicht mehr geschaut habe solches dann mehr).
Abarbeitung der Tokens eben keine andere Instanz, die quasi hinter dem
laufzeittechnisch.
weiterschaltet. Und das ist schnell: den reservierten IP inkrementieren,
reserviert, sonst wird der Ablauf wieder ineffizient. Landet man bei einer Token-Liste, dann wird der IP gesichert und umgeladen, und gleich mit NEXT wieder in der neuen Liste begonnen, auch das geht flott. Und all dies
ziemlich eisernes Regime, wie die Resourcen der CPU zu verbraten sind. Die beiden Stacks als SP, RP, den Instruction Pointer IP plus ein Umladeregister, eventuell dazu Top-Of-Stack in einem Register.
gestrickt, also von Assembler weg hochgezogen. Diese Denkweise ist auf den Desktops nun aber eher rar geworden, wenn man nicht in Richtung Redmond schaut, wo Intel mit sozusagen einbetonierter 80x86-Historie das Fahrwasser vorgibt.
lowlevel-Umgebung des Open-Boot im BIOS von Desktops.
Modell jedes kurze Forthwort ein eigenes C-Kompilat darstellen soll, hat der
weniger zu tun.
Zuletzt dass ich damit herumgetan hatte (also schon lange nicht mehr), waren bei meinem Leib- und Magen-Werkzeug die Optimierungen Forth-intern, d.h.,
darstellen lassen, wurden aufgefunden und zusammengefasst.
strikten One-Pass-Compilers. Es ist ja nicht traditionellerweise das Kompilat das Ziel, weswegen ein Quelltet geladen wird, sondern, abstrakter,
Passagen wiederauftaucht.
Man kann sich aber, seit dem ANS/ISO-Modell, mit den Mitteln zur Interpretersteuerung unterwegs gern seinen Mehr-Pass-Compiler stricken. Das
monokausal gestrickte Denkweise, wozu der Quelltext und wozu der Compiler
kann.
reloziierbaren Objektcode zu generieren, als externes Modul gesichert, um es ohne Quelltext ein andermal zu laden.
Aber aus der Arbeitsteilung, wie die Werkzeuge nun, wenige Jahrzehnte
Bei vielfach andersartiger Sichtweise muss das Ding ja nicht auf jedes
man mit dem Werkzeug umgeht, nicht auf dem Radar aufscheinen wird. Sprich,
der eigenen Ideen, noch bevor der geplagte Programmierer dann sein Werk beginnen will. Letzteres hat der Mainstream nicht vorgesehen. Die Welt bestehe aus Algorithmen und die schreibe man in Algebra.
Am 18.08.19 um 20:43 schrieb Ewald Pfau:
Keine Maschine, die (Rx++) und (--Ry) kann muss an Stacks Mangel leiden. Sagen wir alle nach der PDP-11.
Nein, das war mal relativ schnell zu 6502-Zeiten. Auf heutiger Hardware ist das der direkte Weg zum Untergang. Wenn man alle 5 Maschinen-instruktionen die Pipeline flusht, noch dazu mit unbekanntem Sprungziel,
folgerichtig ausgestorben. (Und eine 16 bit Stackmaschine in Hardware in HP's dynamischen NMOS, das war eben der Zeitgeist, damals.)
Und die 500 Renaming-Register kann man auch wegwerfen, wenn sich das ganze Programm immer nur mit dem TopOfStack und den NextOnStack
ein Hauptspeicherzugriff > 100.
einen da nicht weiter. Eine Instruktion pro Takt ist heute nichts mehr wert.
sind jetzt multiskalare RISCs mit Hunderten von Registern und
riecht noch etwas streng nach X86. Das hat aber mit dem, was nach der Decodierung abgearbeit wird, absolut
Gerhard
Wie Spectre und Meltdown zeigen hat INTeL das mit der spekulativen
mehr warum sie immer schneller als AMD waren. Wenn man an der Sicherheit spart ist es leichter schneller als die Konkurrenz zu sein.
Gerrit
Dabei ist der 86 gar nicht so link gewesen, wenn man erst mal eingesehen hat, dass die Segmentregister eine MMU sind und nix mit der CPU zu tun haben.
Aber, was hatten die $(ANDEREN) immer so tolle CPUs!!11elf!!
Da war der 32032 von National (startete als 16032) super-duper-symmetrisch, sogar Arrays in den Registern. Erstickt an seinen Bugs.
Micro-VAX.
Die 68000-Familie.
sich dann gezeigt hat, dass es Instruktionen gibt die niemals terminieren, weil immer noch ein page fault / exeption/ wasauchimmer reinpasst. Beim 68060 war Schluss mit lustig. Nicht mehr zu verstehen. Auch nicht richtig schnell, irgendwie.
Z8000/Z80000. Kam nie in die Puschen.
Transputer.
war ehrlich gesagt auch nicht mehr sehr dahinter her.
Fairchild Clipper.
rauf oder runterzuschieben konnte eine enge Schleife beschleunigen
IBM Power PC. Ja, hatten wir embedded in einem Virtex. Es gab nie einen Nachfolger von Xilinx, von IBM irgendwie auch nicht.
DEC Alpha.
HP700 / Snakes / KingKobra War schnarch-langsam. Ich hab' noch so ein Teil unter HP-UX in einem Agilent 16702B-Logikanalyzer. War schon damals schlimm. Das HP-Nachfolgedesign haben sie geschaft Intel unterzuschieben. Taugte auch auf Intel's Prozess nix und war dann irgendwie Intel's Fehler.
SUN.
MIPS. Soll jetzt open source sein. Hat nicht gereicht. Ich fand sie eigentlich ganz angenehm.
Ja, der ARM hat's geschafft. Der hatte den Bonus, die wirklich
Und AMD steht im Augenblick ganz gut da. Treuer Intel-Vasall seit dem 8080, abgesehen von dem Seitensprung mit dem Z8000.
Vermutlich habe ich den ein oder anderen Intel-Roadkill vergessen.
Am 18.08.2019 um 21:57 schrieb Gerhard Hoffmann:
sich da die Frage, was davon bei Steuerungsprogrammen besonders
hatte ich ja schon angemerkt.
DoDi
Als der Alpha 21064 1992 rauskam - 64 Bit! 200 MHz! - zitterten der Konkurrenz die Knie. Intel machte damals noch 486er, Sun den
und das waren alles 32-Bit-Chips.
Ein Doktorand von unserem Institut ging ca. '94 zu Intel und wurde ein,
Pleite, Compaq war nicht an Prozessoren interessiert und die Alpha-Ingenieure gingen zu Hunderten zu Intel, HP oder AMD. 1999 meinte der Kollege: "Angst? Wir haben vor keinem mehr Angst".
- Andi
Technisch sicher nicht, in der Vermarktung schon: Man stelle sich
/ralph
-- ----------------------------------------------------------------------------- https://aisg.at
Das war das zentrale Problem von DEC - lauter Ingenieure, die Null Ahnung vom Business hatten...
Und weiter: Es gibt 2 Arten der Geheimhaltung:
Es verging zu meinen DEC user Tagen, nicht ein Tag, wo ich in den meterlangen AKtenordnern zu PDP11, RSX11M, RT02, RT11, LSI11... DECUS
dort waren u.a. viele Gurus von DECUS. Internet gabs nicht, und Telefon reichte nicht. Haben uns auch gegenseitig HW und SW (jau, die lustigen
Und um wieder OT zu werden :)
Anlage ging. Jeder zeigte auf den anderen und ich sass in der Patsche bei
interaktiv die Sache erfolgreich debugged und hatte am Ende eine gute Sammlung von Test 'Worten' in FORTH, die dann von unseren Serviceleuten,
Doku, die sich auf dem Controller durch eine aufgekratzte Leiterbahn, eine
1n914 und etwas Wrapdraht flicken lies. Hab danach FORTH vergessen bis zu einem grossen Projekt mit zuwenig Manpower, zuviel Rotstiften, Chaotischem oberen Damagement und unglaublich knappen Zeitrahmen...: Herr Allinger,waren und absolut nix lief. Die HW Lieblinge der GL fielen nicht in
Ich hatte gerade Berichte von Mitch Bradley (SUN) gelesen, wo er
neue CPU (die er einfach mit FORTH emuliert hat) fertiggestellt hatte. Er
sein, dass der Controller im Plan lag, wo doch die CPU noch garnicht
der spinnt, der Hardwarenix!
Als dann die CPU lief und der Controller samt HDD und Treiber auf Anhieb auch, war grosses Theater im Management. Mitch musste dann tausendmal
das Open-Boot (s.h. ebenda) und von da an gabs Open-Boot auf allen SUN.
interessiert und Dein Labor dauernd voller Fremder ist :)
auf die 2 Stack Architektur von FORTH verzichtete, ist (mir)
Andere Berichte sagten, dass FORTH Programmierer 3-30x produktiver als in allen anderen Programmiersprachen sind. Wenn das stimmte, dann sah ich da meine einzige Chance. Ich erinnerte mich an meine Erfahrungen, hab dann mich und 2 weitere Ings verschworen, es mit FORTH zu probieren. Wenige Tage vor dem Projektstart, war ich mit 3 meiner MA auf einem DEC
Ich engagierte Flesch Forth Systeme um uns auf den Pott zu bringen und 3 Wochen zu pampern, bis wir mit dem LMI Forth samt Metacompiler alleine weiter arbeiten konnten. Wir benutzen 3 Mostek Z80 Entwicklungssysteme die an unserer PDP11/34 per CL (20mA 9600Bd) hingen. Ein Flesch Mann war immer zugegen um als wandelndes Lexicon und Bezaubernde Jeannie (ok, Barbara Eden war sexier :) auf Fingerschnipp zu helfen.
Projekt hab ich dann noch von dem zu klein werdenden Z80 auf 64180 umgestellt, die beiden anderen haben nichts bemerkt, ausser dass alles
mitten im Projekt auch noch die Pferde gewechselt (z80 -> 64180) Ich war erstaunt, was Wut (auf die GL) an Energien und Motivation (auch bei den anderen Beiden) freisetzen konnte.
Aber statt Lob aus der GL kam nur: Siehste, man muss die Softies nur ordentlich treten, dann klappt das auch!
mitbekamen (und noch ein weiterer), wollten sie mit mir gehen.
ordentlich Projekte von dem alten AG mitbekommen. War ne prima Starthilfe.
Der einzige Fehler war, dass wir alle 4 gleichberechtige Partner waren.
Hat mich meine Einlage von 20.000DM gekostet und den 924S hat dann einer
und dann an einen Zahnarzt weiterverkauft) :o
Ein jap. Sprichwort sagt: Wer von der Hoffnung lebt, wird wenigstens nicht dick!
Hat bei mir gefunzt, nur noch FORTH und embedded HW+SW, ordentlich an Umfang (nicht nur Bankkonto) zugelegt :) und mich und meine Frau und meine
finanziert.
inzwischen in Rente gegangen.
Wolfgang
-- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
Am 19.08.2019 um 14:11 schrieb Wolfgang Allinger:
ich konnte ihr nie was abgewinnen und RPN finde ich schlichtweg abartig.
-- Ich muss nicht kultiviert *aussehen* - ich bin es. Profiklaus in d.r.f.
.
Die polnische Notation selbst, +(3,4) statt 3+4, hat was.
-- / \ Mail | -- No unannounced, large, binary attachments, please! --
Tja, ich fahre heute auch nicht mehr mit der Kutsche ins Amt.
Stellt sich nur die Frage, was?
-- Ich muss nicht kultiviert *aussehen* - ich bin es. Profiklaus in d.r.f.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.