AVR C-Compiler Vor- und Nachteile

Full Ack.

Auch hier Full Ack. Gcc ist eventuell als Hobbywerkzeug brauchbar, aber meiner Meinung nach nicht als Compiler um Produktionscode zu erzeugen.

Ich benutze den Codevision AVR und bin mit dem Compiler extrem zufrieden. Habe in den Jahren, die ich den benutze keinen ernsthaften Bug gefunden - hin und wieder tauchen mal Probleme in "exotischen" Bereichen des C Standards auf, wo Programmierer und Compilerentwickler den Standard etwas anders interpretieren - und meistens behaelt der Compilerentwickler recht ;-) Hat viele nette Features, die es insbesondere dem Anfaenger erleichtern leicht einsteigen zu koennen. Die IDE ist sehr stabil und erfuellt ihren Zweck, ist allerdings nicht ganz mein Geschmack. Es gibt leider keine Kommadozeilenversion des CVAVR, das muss jeder selber entscheiden, ob er sich mit der IDE anfreunden kann oder nicht (Demoversion runterladen). Es gibt eine aeusserst aktive Emailliste zum CVAVR, wo auch der Entwickler mitliest und bei Problemen, typischerweise sehr schnell mit Loesungen oder Vorschlaegen kommt. Einziger Nachteil auf der Liste sind viele Anfaenger und Hobbybastler vertreten, das heisst das "Rauschen" ist recht stark.

Gruss Klaus

Reply to
Klaus Bahner
Loading thread data ...

, neu

=FCber

=FCber

das

ufen.

ein

Ist

das h=F6hrt sich so an als w=FCrde es zu mir passen. Ich glaube ich werde mal die Demo-IDE von Imagecraft und Codevision anprobieren um zu sehen welche mir besser steht. F=FCr weitere Pro's und Con's bin dankbar. Mit jeder Falle in die ich weniger tappe ist mein Chef dankbar ;-)

Gru=DF Mark

Reply to
Mark Kreso
*Ruediger Klenner* wrote on Fri, 07-10-19 04:11:

Wie schonmal gesagt, über polnische Notation kann man reden, die kann man aussprechen und denken:

+(3,4) = Summe von drei und vier

Aber (3,4)+ = nehmen wir erstmal irgendwelche Zahlen und überlegen später, was wir damit tun wollen ist in meinen Augen eine reine Konzession an die Harwarepreise von 1970 (es ist kein Zufall, daß es den HP eher gab als die mit Klammerebenen) und vollkommen überholt.

Reply to
Axel Berger

Hab ja nichts dagegen. Nur mir ergeht es anders.

Wenn diese irgendwas sinnvolles aussagen soll, dann sind mir das zu viele Daten für einen Taschenrechner. UPN her oder hin, ich bemerke evtl. nicht mal Tippfehler beim Zahlen eingeben.

Entweder hacke ich die Daten händisch in Excel oder ich gewinne sie über eine Schnittstelle. Dann fallen sie einer C++ Statistikklasse zum Ofer.

3 + 4 =

Da kommt 5 raus.

Viel mehr Operationen in Folge mache ich seit 20 Jahren nicht mehr auf dem Taschenrechner. Den TI, den ich noch länger besitze benutze ich ca.

1 mal im Monat. Und Kopfrechnen geht meist auch noch wenn es eine TR-Aufgabe wäre.
--
Gruß, Raimund
Mein Pfotoalbum 
 Click to see the full signature
Reply to
Raimund Nisius

Ich kann nur UPN-Taschenrechner, aber Forth war mir dennoch ein Graus: Bei Gruppenarbeit muß man anderer Leute Wörter anwenden. Schon deren Namensgebung war für mich schwer erlernbar.

Die gute(*) Nachricht:

Es gibt seit Sommer 2007 wieder Hewlett-Packard-Taschenrechner mit UPN. (Hier kein Link wg. Reklame)

Ich hatte MaWin gebeten, das FAQ-Kapitel "Taschenrechner" nachzurüsten. Hat er noch nicht getan.

(*) gut für mich jedenfalls: Als HP nicht mehr produzierte, schwächelte mein HP32 S II. Der Gedanke an die Umgewöhnung an "normale" TR trieb mir den Angstschweiß ... Zum Glück hat sich mein TR erholt.

Jetzt wäre der Ausfall kein Problem mehr, zumal die Preise der neuen HP-TR gegenüber früher recht zivil sind.

W.Riedel

Reply to
W.Riedel

Wie Johannes Reilhofer (

formatting link
) mal richtig gesagt hat: ein Forth-Programmierer würde von einem anderen Forth-Programmierer eher das gebrauchte Taschentuch als dessen Sourcecode verwenden. Deshalb können alle Forth-Compiler untereinander so schön inkompatibel sein: niemand portiert vorhandenen Code.

MfG JRD

Reply to
Rafael Deliano

snipped-for-privacy@t-online.de schrieb:

Mein HP41CV zeigt keine Schw=E4chen und der noch in gebrauch befindliche HP25 auch nicht ;-)

--=20 mfg hdw

Reply to
Horst-D.Winzler

schrieb:

Ganz einfach: Wenn der Name eines Forth-Wortes irgendwie 'gelernt' werden muss, dann ist es kein Forth-Wort.

Was du beschreibst ist das bedauerliche Ergebnis, das sich einstellt wenn C- oder Pascal- oder sonstige Anhänger des prozeduralen Paradigmas (Mainroutine und ne Handvoll Prozeduren und Funktionen drumrum) Forth missbrauchen. Solche gibts, warum sie dann Forth verwenden entzieht sich meinem Verständnis; sollen sie doch C- oder Pascal oder sonstwas nehmen wenn sie auf diese Art programmieren?

Die Forth-Kunst besteht darin, viele, viele (vielvielmehr als in genannten mainstream-HLLs) Worte festzulegen, aus der Problembeschreibung 'auszufaktorisieren', die dann jeweils nur eine klar umgrenzte Kleinigkeit machen und nicht mehr! Einen adäquaten Namen für das Wort zu finden ist dabei essentiell fürs Programmieren in Forth; der Wortname soll exakt ausdrücken was das Wort macht. Programmiert wird dann, indem eine sprachliche Repräsentation des Problems und seiner Lösung gefunden wird.

So wie unsere Sprache es ja auch macht, viele, viele Vokabeln mit begrenztem Sinn und eine Handvoll Regeln (Syntax = Die Stackabarbeitungsreihenfolge) werden benutzt, um ganze Bücher zu füllen, die dann wiederum Problemlösungen darstellen (application notes z.B.) und Anderes, Unterhaltung u.s.w.

Die Anhänger der reinprozeduralen Lehre benutzen nicht 'Worte' als grundlegende Bausteine ihres Tuns sondern deklarieren Variablen, Konstanten, und basteln dann Prozeduren und Wasimmersiebrauchen unter Verwendung einer schwächlichen, vorhandenen Sprache (deren BNF-Form sie vorab verinnerlichen). Die Listings werden dann natürlich entsprechend lang. Da der Sprachrumpf nebst Vokabular festliegt (Pascal, C) sehen die erstellten Problemlösungsbausteine (Prozeduren, Funktionen) auch schon rein optisch wie hilfloses Gestammel aus...

Ein hoffentlich anschauliches Beispiel:

% --- %Post-Brief-Paket-Behandlungsroutine, ein prozedurales Programmierwunderwerk % ---

-/ Konstantendeklaration

Normbriefmax = bla; % *Obergrenzen* für Normbrief Normpaketmax = blubb; % *Ober*grenzen für Normpaket

Normtarifmarke = val; Übertarifmarke = val; Normpaketporto = val; Übertarifporto = val;

begin wenn (Brief oder Paket) = TRUE dann Zur-Post-Gehen; % Ort der Behandlungsprozedur begin wenn Brief = TRUE dann % hier Brief wenn Brief < Normbriefmax dann % zu gross oder zu schwer? aufkleben(Normtarifmarke); aufgeben(Brief); % aufgeben = einwerfen andernfalls % Vermeidung 'Nachgebühren' aufkleben(Übertarifmarke); aufgeben(Brief); % aufgeben = auch abgeben endevonwenn % Brief.typ-wenn,ohnewennundaber andernfalls wenn Paket = TRUE dann % nun Paket wenn Paket < Normpaketmax dann% Test: zu gross oder zu schwer zahlen(Normpaketporto); aufgeben(Paket); % aufgeben = weg damit andernfalls % siehe 'Strafporto' zahlen(Übertarifporto); % monetärer Ressoucencheck?? aufgeben(Paket); % Paketmensch übergeben endevonwenn % vom Paket.typ-wenn endevonwenn % vom Brief-oder-Paket-wenn andernfalls Ins-Bett-Gehen; % der Tag war lang genug endevonwenn % vom überhaupt-alles-wenn end

aber es geht auch anders, indem man sich passende Worte (Begriffe) definiert und 'natürlichsprachlich' zusammensetzt, hier mal top-down:

Postauftrag : Brief oder Paket vorhanden? Wenn ja dann Post andernfalls Bett;

Post: Wenn Brief dann Briefschalter andernfalls Paketschalter;

Briefschalter : Wenn Normbrief dann Normbriefmarke andernfalls Übertarifmarke. Briefschlitzeinwerfen;

Paketschalter: Wenn Normpaket dann Normporto andernfalls Überporto. Paketschalterabgeben;

und das war's schon. Irgendwas vergessen? Die Prozedurale Routine hat ein Problem mit aufgeben(Objekt), das im sprachlichen Ansatz schon gelöst ist (zwei Worte statt einer Prozedur mit Fallunterscheidung) und was Kompaktheit, Les- barkeit und Verständlichkeit angeht...

Und jetzt erweitern wir das ganze mal schnell um Nah- und Ferntarif und Einschreibemöglichkeiten... welcher Ansatz lässt sich wohl rascher erweitern, die 'sprachliche Repräsentation' oder der 'reinprozedurale Ansatz'?

In Forth würde man einfach ein paar Worte neu schreiben (Worte verwerfen und neuschreiben ist dort üblich, geht fix) und ruckzuck hat man eine neue, differenziertere 'natürlichsprachliche' Beschreibung des Problems und seiner Lösung während man in prozeduralem Kontext weitere Fallunterscheidungen, ifs und cases einfummeln müsste bis dann endgültig keiner mehr durchblickt.

Fazit: Der Forthprogrammierer definiert sich erstmal die Worte, die er braucht um das Problem zu beschreiben und dann durch die Beschreibung zu lösen während der prozedurale Kollege noch seitenlang Gestammel eintippt und sich im Programmfluss verheddert wie Laokoon nebst Söhnen dazumals... So gesehen gibt es keine 'Sprache Forth', nur eine 'Programmiermethode Forth' (die ich in PIC-Assembler gerne verwende); in Forth gibt nur ein paar elementare Stackoperatoren (Syntaxmechanismus); die Sprache, d.h. Vokablen bzw. 'Worte', erschafft der Programmierer dann jedesmal neu und anders, nämlich passend problembezogen. Wie beim Verfassen von Texten ja auch!

Wir wiederverwenden doch auch nicht jedesmal per copy&paste, was Andere geschrieben haben, wir drücken es doch auch gerne mit eigenen Worten (und um eigenen Ideen und Lösungsansätzen bereichert) aus.

Ausserdem steht schon in der Bibel: "Am Anfang war das Wort" und nicht: "Am Anfang waren Variablen- und Konstantendeklarationen"! *g*

Reply to
Ruediger Klenner

"Axel Berger" schrieb:

Typisches Vorgehen wäre deiner Meinung nach also: "Bilden wir erstmal die Summenfunktion und überlegen später, welche Zahlen wir addieren und warum"?

Gehst du in die Küche mit dem Gedanken "ich will unbedingt kneten, mal gucken was sich an Verknetbarem findet" und wählst dir dann verknetbare Dinge aus (Eier, Mehl, Salz, Senf, Marmelade, Toastbrot) oder gehst du in die Küche mit dem Gedanken "ich will nen Kuchen backen, also nehme ich die zu 'Kuchen' passenden Elemente 'Eier, Mehl, Milch, Hefe, Zucker, Rosinen' und wende dann die Operatoren 'kneten', 'aufgehen lassen', 'backen' darauf an"?

Es steht doch nicht im Pflichtenheft: "Sie müssen unbedingt den Euklidalgorithmus da unterbringen" sondern da steht: "Vom Eingabegerät kommen Zahlen und Zeichen von dieserundjener Art, bla bla bla, und sie müssen irgendwas tun (Algorithmus passend auswählen) damit dasunddas rauskommt. Was rauskommen soll, hätten wir gerne soundso: bla bla bla"

Also, 'irgendwelche' Zahlen und Zeichen sind tatsächlich zuerst da und wir überlegen danach und in Abhängigkeit von Datentyp, Informationsgehalt u.s.w. dieser Zeichen, wie wir diese passend vernudeln müssen damit das Gewünschte rauskommt. Oder ob wir erst noch weitere, zusätzliche Zeichen brauchen, bevor wir anfangen können.

Also doch exakt so, wie du oben formulierst.

EVA hiess das mal früher, also (3,4)+=>7 und nicht VEA, +(3,4)=>7 :)

VEA ist auch möglich aber bei VEA muss man 'rückwärts' denken und sprechen: "Verarbeitung der Eingabe zur Ausgabe"; scheint mir umständlicher als "Aus der Analyse von Eingabezeichen und Anforderungsprofil erfolgt (Wahl der) Verarbeitung(sregeln) zur Ausgabe"; so folgt es doch auch dem Programmierfluss.

Und auch eher dem Denken im 'richtigen Leben': Die Reste bestimmen wie der Eintopf schmeckt (oder ob es eine Pizza wird, d.h. gekocht oder gebacken werden muss)! Oder umgekehrt, Spaghetti waren bestellt... also erst die Zutaten einkaufen, und dann die Verarbeitungsoperatoren drauf anwenden...

Das verstehe ich nicht, kannst du das etwas erläutern? Beides braucht zwei Speicherplätze, egal ob +(a,b) oder (a,b)+, stack benötigen sie beide nicht.

Reply to
Ruediger Klenner

Am Sat, 20 Oct 2007 19:32:19 +0200 schrieb Ruediger Klenner:

Hi!

was macht Forth dann "codetechnisch" aus den Wörtern? Etwas, das man in anderen Sprachen "Prozeduraufrufe" nennen würde?

Oder eher inline-code?

Ersteres fände ich wäre eine extreme Spaßbremse.

Liebe Grüße, Thorsten

Reply to
Thorsten Oesterlein

Moin!

Und beide schicken jemanden, der mit einem Brief und einem Paket zur Post geht, mit dem Paket wieder nach hause. Und während der prozedurale Programmierer nur schlafen kann, wenn er vorher zur Post gelaufen ist, verläuft sich der Forth-Programmierer wohl auf dem Rückweg, daß er danach gar nicht mehr ins Bett kommt. :-)

Gruß, Michael.

Reply to
Michael Eggert

indem man vernünftig prozedural programmiert:

procdure main begin if brief or paket then post end

procdure post begin if brief then briefschalter else paketschalter end

procdure paketschalter begin if Normbrief then Normporto else Sonderporto end

usw.

Topdown fehlen die Definitionen von Brief, Paket, Bett, Normbrief, Normbriefmarke, Übertarifmarke, Briefschlitzeinwerfen, Normpaket, Normporto, Überporto, Paketschalterabgeben. Dein Forthcode ist nur deswegen so kurz weil Du das meiste unterschlagen hast.

--
Gruß, Raimund
Mein Pfotoalbum 
 Click to see the full signature
Reply to
Raimund Nisius

"Thorsten Oesterlein" schrieb:

Es gibt natürlich beides, hängt von der Implementation des Forth-Systems ab.

(Gerade Forth-Implementationen gibts doch wie Sand am Meer, für alle möglichen und unmöglichen Zielsysteme. PForth für den gameboy z.B. :)

Für 'rapid prototyping' auf sehr, sehr kleinen Systemen wäre eine Implementation, die sich superkompakten 'gefädelten code' setzt, m.E. geeigneter als eine, die sich direkt Assemblercode setzt. 'Gefädelt' ist zur Laufzeit hinreichend schnell, aber, was Speicheranforderungen angeht wesentlich kompakter (kompakter als Assemblate) und in der Handhabung, d.h. im Prozess des Prototyping auch 'reagibler', u.U. Gibt aber sicher auch Implementationen auf gleicher Zielhardware, denen man keinen oder kaum einen Unterschied anmerkt, könnte ich mir denken.

Die Bewertung, was von Beidem nun "Spassbremse" ist, würde ich also umgekehrt vornehmen wollen :) Aber das ist sicher Geschmackssache. Wie gesagt, es gibt mindestens beides, sogar vieles...

Vielleicht noch ein Wort zu deiner ersten Frage... was macht Forth eigentlich. Das ist sehr einfach und simpel, darum im Ergebnis sowohl kompakt als auch zur Laufzeit schnell: Ein Forthsystem implementiert zwei LIFO (stack, Kellerspeicher) falls auf der Zielhardware nicht eh schon vorhanden und jedes 'Wort' macht dann nichts anderes, als sich Daten von einem der stacks (oder beiden) holen, sie vernudeln und das Ergebnis wieder draufzulegen. Die Worte sind also die Täter!

Die kleinsten Elemente sind in Forth jedenfalls (selbsterstellte) Worte, drum verwendet man in Forth nur eine den Worten zugeordnete Stacknotation, das ist praktisch das Einzige, worauf der Programmierer sprachbedingt achten muss. Der Rest an Programmiererei besteht darin, eine 'natürlichsprachliche' Repräsentation und Lösung der gestellten Aufgabe zu finden.

Man kann mit(hilfe von) Diagrammen programmieren, man kann aber auch mit(hilfe von) Sprache programmieren. Macht beides Spass!

Worte definieren, testen, verwerfen; dann andere, treffendere Worte finden... sehr reagibel das Ganze in der Praxis, sagte ich schon.

Reagibel hat in meinem Sinne nix mit 'Compilezeiten' oder Wartezeiten fürs 'bootloaden' zu tun sondern mit oben Gesagtem... Konstruieren mit Worten ist eben flexibler, reagibler als konstruieren mit festen Satz- oder Textbausteinen (sprich grösseren Funktionseinheiten, Prozeduren)...

Beispielansatz: Funktionen sind Verben, die tun was und werden auf Nomen angewandt. Nomen können wir für Variablen verwenden (z.B. "Kreis" legt Mittelpunkt, Radius, Farbwert auf den stack). Adjektive nehmen wir für Attribute und ein kleines Sätzchen ergibt dann erst eine Prozedur. ("Kreis grün malen".) Man jongliert hier im Prozess des prototyping mit den kleinsten vorhandenen Elementen, also den Worten und nicht mit sperrigen prozeduralen Einheiten als kleinste Grösse. Das bewirkt einen wichtigen Unterschied, für mich jedenfalls.

Nachdem wir nun in der ad-hoc Spielerei noch "rot" und "blau" definiert und genügend rote, grüne und blaue Kreise gemalt haben, definieren wir "weg" als Hintergrundfarbe und testen "Kreis weg malen". Geht auch, aber klingt doof, also noch schnell definiert: "löschen = weg malen" und schon kann man "Kreis löschen". Soweit ganz gut.

Jetzt ändern sich die Anforderungen, Rechtecke sollen her, und plötzlich ist alles gar nicht mehr so gut, es ist schlecht!

Neuansatz: Wir werfen "malen" einfach weg! "Grüner Kreis" zu formulieren wäre vielleicht viel besser gewesen, d.h. "Kreis" soll Täter sein, nicht "malen". Das ermöglicht dann auch sofort die Implementation anderer geometrische Objekte die beim ersten Ansatz so nicht möglich waren;, "Kreis" bresenhamt und "Rechteck" zeichnet Linien zu Eckpunkten und "Dreieck" verbindet drei Punkte, also wieder Bresenham... --- gleich mal ausprobieren und testen, diese sprachliche Umformulierung und ihre praktischen Folgen.

Üblicher Programmieransatz wäre jedoch gewesen: 'sukzessive Verfeinerung" des Moduls "malen" und zusätzliche Einführung eines neuen geometrischen Datentyps, Fallunterscheidungen dann im Modul "malen"... und SO wirds ja auch dann auch oft gemacht, statt alles umzuwerfen und geeignet, problemgerecht neu zu formulieren und die kompakte, richtige Lösung zu finden.

Ich will nun nicht behaupten, dass man in C nicht auch öfter mal alles verwerfen und komplett neu anfangen kann. Man kann sicherlich, in Forth wäre es aber kein unübliches Vorgehen.

Und ich möchte das Augenmerk lenken auf das, was Nach-Änderung-der Anforderungen geschieht! Denn "Man kann es ja von Anfang an richtig machen" kann jeder, aber interessant ist, was *nach* der ersten und zweiten Anforderungsänderung geschieht und solche kommen ja bekanntlich mit Sicherheit. 'rapid prototyping' heisst ja auch, dass gerade auch der Auftraggeber im Prozess des prototyping seine Anforderungen erst erkennt und vernünftig formuliert.

Stichwort rapid prototyping: Man kann sich in Forth sehr schnell an verschiedene Lösungen eines Problems rantasten und testen. Vorteil gegenüber Pascal, C würde ich mit dem Unterschied zwischen Holzbauklötzen und Legosteinen vergleichen wollen. Hier (Bauklotz) vergleichsweise sperrig, träge, geringe vorgegebene Variationen und wenn man 'sein Türmchen' herzhaft umbaut muss man immer etwas Angst haben dass es einfällt --- und dort (Lego) diese kleinen praktischen Steinchen, leicht zusammensteckbar in tausenderlei Variationen, gesteckt hinreichend stabil, auch leicht wieder trennbar (wie die Sprache selbst eben). Keine Hemmungen, schnell alles wieder zu lösen und ruckzuck anders zusammenzustecken. 'Reagibler'?

Und Forth ist sogar noch besser als Lego *g* denn bei Lego muss man sich Spezialbausteine (Räder oder Fenster, Türen) teuer kaufen, in Forth macht man sich auch Spezialkonstrukte (exotische Datentypen) natürlich selbst.

So, jetzt reicht's aber. Alles Gesagte natürlich meine subjektive Sichtweise, klar. Andere Forthler mögen andere Ansichten haben und wer Forth nicht mag, soll es eben nicht nehmen, ist meine Ansicht :)

Reply to
Ruediger Klenner

klingt wie die 1:1 Übertragung meiner Forthansatzskizze :)

Aber stimmt, man kann auch... dann besteht kein Unterschied. Wie gesagt, ich programmiere so in PIC-Assembler. Aus diesem Grund meinte ich auch, Forth wäre vor allem ein Programmierstil.

Ein Forth-System mit Interpreter/Compiler unterstützt diese Art des Programmierens allerdings ausgezeichnet, besonders, wenn spätere Änderungen einfliessen (Beispiel: Erweiterung auf Nah- Ferntarife, Einschreiben und 1000 Postabsonderlichkeiten mehr), drum ausgezeichnet für 'rapid prototyping' geeignet. Was man von prozeduralen Sprachen wie C und Pascal nicht sagen kann, die sind sozusagen 'sperriger'.

Die 'Prozedur' bzw. 'Funktion' ist an sich schon so sperrig, dass die meisten Leute sie vermutlich nicht einfach wegwerfen können (steckt soviel Arbeit drin) wenn sich Anforderungen ändern (sprich, neuschreiben angesagt wäre) sondern anfangen, ihre Module 'sukzessiv zu verfeinern', mit immer sperrigeren Konstrukten und Fallunterscheidungen. Bis zur Unleserlichkeit und Unverstehbarkeit des gesamten Programms.

Ich denke mal, solche Programme hat jeder schon gesehen...

'Worte' hingegen sind 'kleiner', weniger sperrig und funktional einfacher, man kann sie leicht aufgeben und einen Satz, einen Ausdruck, eine Problemlösung auch komplett anders anfangen, mit anderen, der geänderten Problemstellung angemesseren Worten. Es stehen ja genug Worte zu Verfügung! Der Forth-Programmierer braucht sozusagen nur einen Duden, wenn er nicht genug Sprachgefühl oder Wortschatz oder Phantasie hat.

Und darum ist 'Wiederverwendbarkeit' in Forth auch überhaupt kein Thema. Jeder hat seinen eigenen Schnabel und ist stolz drauf *gg*

Nein, das ist es nicht! Die fehlen, ohne Ausnahme, oben beim prozeduralen Codeschnipsel genauso, wenn du genauer hinguckst.

Geht auch gar nicht um die Kürze: geht um die Verstehbarkeit, leichte Abänderbarkeit u.s.w. gerade dann, wenn das Programm schon zahlreiche Änderungen erfahren musste.

Reply to
Ruediger Klenner

"Michael Eggert" schrieb:

Das stimmt. Soll er doch ruhig nochmal latschen... :) Das ist doch alles wirklich schon schrecklich kompliziert und hässlich genug, willst du es etwa noch komplizierter machen? Noch weitere Fallunterscheidungen?

*g*

seh' ich jetzt zwar grad nicht, ich meine er geht ohne (Brief oder Paket) sofort ins Bett denn das 'äusserste', unterste else trifft ihn; aber wenn es doch so sein sollte unterstreicht es meine These:" man kann sich mit Leichtigkeit in prozeduralem Code verheddern' ja vorzüglichst.

Dochdoch, der wandert per Postauftrag ruckzuck ins Bett wie es sich gehört. Da bin ich mir halbwegs-ziemlich sicher :))

(Na ja: In Forth wäre das ein if - else - then Konstrukt: 'Bett' würde schon aufgerufen werden wenn der Vergleich der beiden oberen stackwerte false liefert. (und fehlende Klammern gibbet in Forth nicht, falls du darauf hinauswillst, die fehlen nämlich immer:). Ist aber eh alles Ad-hoc-pseudocode was ich getippst hatte, richtiges Forth oder auch Pascal ist das offensichtlicherweise ja nicht, sollte nur der Illustration dessen dienen was ich - ganz subjektiv - für einen wichtigen Unterschied zwischen Forth-programmiertechnik und prozeduralem Ansatz halte.)

Reply to
Ruediger Klenner

C kann den Code in Assembler umwandeln ( effizient ) oder es baut Stackframe auf ( Pech gehabt ). FORTH hat seine "lokalen Variablen" alle auf Stack, es benötigt also keine Stackframes. In einem JSR,-threaded System ist dann der Aufruf eines Befehls ein Unterprogrammaufruf wie man ihn in Assembler auch machen würde. Auf der ersten Seite im Anhang zum GP32-Manual sind die Interna eines JSR,-Systems kurz angesprochen:

formatting link

FORTH kann also nur deshalb alles modular in Unterprogramme zerstückeln weil die wenig Laufzeitprobleme machen. Die Sprache ist aber typisch etwas langsamer als C. Ausnahme können alte 8 Bit CPUs sein die dem C-Compiler die Optimierung erschweren bzw. wo dort niemand den Compiler angepaßt hat. Bzw. Forth-Crosscompiler für neuere CPUs die alle möglichen Optimierungen genau wie C auch machen. Die Frage ist für viele Anwender nicht wie schnell das Programm läuft sondern wie schnell man das Programm am Laufen hat. Zeitkritische Teile kann man ja immer in Assembler codieren.

MfG JRD

Reply to
Rafael Deliano

Moin!

Ääh - nee - doch andersrum...

|begin | wenn (Brief oder Paket) = TRUE | dann | Zur-Post-Gehen; | andernfalls | Ins-Bett-Gehen; | endevonwenn |end

Nach Post gehts ohne Bett zum end.

Nunja, in diesem Beispiel lässt sich das klar erkennen, wenn auch nicht unbedingt um 2 Uhr früh... aber lassen wir das. :-)

Wie oft wird...

|Postauftrag : Brief oder Paket vorhanden? Wenn ja dann Post andernfalls Bett;

...den aufgerufen? Hier gibts ja keine while-Schleife oder so. Insofern würde ich "Wenn ... andernfalls" genauso interpretieren wie im ersten Programmschnipsel: Bett gibts nur _andernfalls_, also wenn _keine_ Post zu erledigen ist/war.

Gruß, Michael.

Reply to
Michael Eggert

Nö, wieso? "3 4 +" liest man als "drei und vier addieren". "3 4 + 5 *" entsprechend als "drei und vier addieren, mit fünf multiplizieren".

Stefan

Reply to
Stefan Reuther
[UPN]

Kaufmännische Tischrechner arbeiten auch so ähnlich und ich finde das nicht unlogisch:

Ist-Stand der Kasse erfassen: 100,00 + Lebensmittelbon abziehen: 12,50 - Rückgeld für Pfand dazuzählen: 0,75 +

usw. Man tippt einen Wert ein und sagt dann, was damit gemacht werden soll. Im Display steht sofort das Ergebnis, ohne dass man Klammern schließen oder die '='-Taste drücken muss.

Weiß jemand, ob dieses Verfahren bei kaufmännischen Taschenrechnern auch als UPN bezeichnet wird? Oder ist das etwas anderes?

Reply to
Martin Klaiber

Ah, jetzt sehe ich erst was du meinst. Ja, das ist für beide Postläufer der Fall.

Das sollte so! Andere Bettgehmöglichkeiten werden ausserhalb dieser Prozedur abgehandelt, z.B. in proc KNEIPE im Abschnitt: if (übergeben.anz > 3 or Wirt.mode = böse or Umwelt.mode = rotierend) then Heimweg(Bett). Oder u.U. auch im gänzlich fehlenden MAIN.

Na ja, ich wollte jetzt nicht tatsächlich etwas anfangen, was sich später der Post andrehen liesse *gg*. Wie Raimund richtig anmerkte, "...fehlen die Definitionen von Brief, Paket, Bett, Normbrief, Normbriefmarke, Übertarifmarke, Briefschlitzeinwerfen, Normpaket, Normporto, Überporto, Paketschalterabgeben" und vieles mehr, insbesondere fehlt in beiden Fällen die MAIN-routine in der man dann eine Endlosschleife vermuten würde.

Das stimmt ja auch, ist beidesmal gleich gedacht gewesen. Es gibt noch soviele andere Aktionen, nach denen man unbedingt ins Bett muss und die natürlich alle in anderen Prozeduren behandelt werden. Ein generelles Ins-Bett-gehen erzwingen in der Postbehandlungsroutine wäre also ein schwerer Fehler gewesen, wie du einsehen musst :)

Es sollte ein Beispiel sein, dass eine Prozedur in Forth in mehrere Worte ausfaktorisiert werden kann und (was im Beispiel noch nicht war, um es einfach zumachen) die Worte selbst können präprozedural sein, bilden selbst nicht unbedingt abgeschlossene funktionale Einheiten sondern tragen nur eine Bedeutung, genau wie es Worte in der Sprache tun. (Was ist der funktionale Sinn von "grün"?)

Prozeduren sind in Forth Sätzchen, die aus vorzugsweise wenigen Worten bestehen und selbst wieder als Wort belabelt werden. Und man ist dann nicht auf die Wahl Variable/Konstante oder Prozedur/Funktion beschränkt ("grün" ist Prozedur die Farbwert rückgibt oder doch besser deklarierte Konstante) sondern es gibt viele weitere Möglichkeiten auf elementarerer Wortebene; Wahl von Tempus (grün, war grün, wird grün u.U. für etwas elaboriertere Ampelsteuerungen), Modus; Verwendung von Konstrukten wie Komposita oder Kausativbildung, nomina agentis verwenden (Täter, Motor, Tokenifizierer...) also genau das, was wir sprachlich sowieso schon tun! Dazu muss man nicht Grammatiker werden, die Muttersprache halbwegs beherrschen genügt. Sprache benutzen reicht.

Oder wie ich auch schon mal schrieb: Jeder benutzt einfach seinen Schnabel so, wie er gewachsen ist...

Wie schon mehrfach gesagt: Programmieren in Forth beschränkt sich dann also darauf, eine sprachliche Repräsentation (oder Abbild, Modell) eines Problems und seiner Lösung zu finden. In Muttersprache, sozusagen. Das ist alles.

Klingt das einfach?

Es ist vielleicht genauso einfach, wie eine sagenwirmal application note zu schreiben ... also nicht einfach sondern sehr schwer! Ringen um Worte, um Präzision und Anschaulichkeit, verwerfen von Sätzen und Textpassagen und Neuschreiben dieser gehört dann zum Handwerk dazu. Ein iterativer Prozess, der sich nicht nur auf "sukzessives Verfeinern von Modulen" beschränkt, das wäre zuwenig.)

Raimund hat drauf hingewiesen dass 'ausfaktorisieren' prinzipiell in anderen Sprachen auch geht, aber der Forthprogrammierer jongliert damit. Forth unterstützt es, prozedurale Sprachen behindern es eher.

Reply to
Ruediger Klenner

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.