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

Am 15.08.2019 um 23:45 schrieb Wolfgang Allinger:

es um Echtzeit auf einem Mikrocontroller geht, bei dem selbst die

reinrassigen Maschinencode laufen lassen. Bis dahin unterscheidet sich FORTH kaum von BASIC, was die Laufzeit betrifft.

DoDi

Also vermutlich auch eines der am besten optimiertesten.

Deine Argumente sind, zusammenfassend, etwa:

1. Forth ist einfach zu schreiben, weil skriptbar

Das sind beides subjektive und qualitative Argumente. Auf meine Frage im

das nicht testen.

Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den

implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia folgende.

Dann Gforth, dass du oben empfohlen hast, als Benchmarking verwendet. Resultate hier:

Datenstrom Faktor 655. Also im Mittel, sagen wir, Faktor 500 lansgsamer.

MHz clocke und auf dem System B denselben Code von 32 kHz Uhrenquarz laufen lasse. Es sind WELTEN.

nur unbenutzbar. Ich kann das Argument ja gut verstehen, dass du die

Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann muss man aber halt auch so ehrlich sein und die Nachteile (totale Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich.

Johannes

Am 16.08.2019 um 20:55 schrieb Johannes Bauer:

darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded)

sowas sicher nicht zu schaffen, nicht nur mangels Dokumentation der Hardware, sondern auch mangels direktem Zugriff darauf. Da hilft sogar ein RT-OS wenig, wenn es um interaktive Programme und ihre Entwicklung geht.

Kommt drauf an, welche Geschwindigkeit die Anwendung erfordert. Typische Controller Programme verbringen ihre Zeit fast nur mit Warten auf Ereignisse, und reagieren dann mit dem Setzen von ein paar Bits der

einem langsamen 8-Bit Mikrocontroller betreiben, da geht auch mit

500000-facher Rechengeschwindigkeit nicht mehr (Takt:100-1000 + Maschinencode:5-500).

Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen

wurde, dann ist ein Crash vorprogrammiert :-(

Oft liegt es aber einfach in der Natur der Controller. Was verdammt nochmal bedeutet es, wenn das Programm dieses oder jenes Bitmuster in

eines anderen Controllers anders funktioniert.

DoDi

Naja, ich kann halt kein Forth. Und das Wikipedia-Beispielprogramm ist das einzige das ich hatte und es ist auch echt Embedded-tauglich. RC4 ist so klein, dass man ihn einfach runterimplementieren kann.

machen, Testprogramme zu liefern, die weniger Overhead haben (damit man

ich halt wenigstens harte Zahlen, wo vorher nur rumgewiesel war. Jeder ist herzlich eingeladen neue Zahlen zu liefern, aber diese qualitativen Aussagen gehen mir auf den Keks.

digitale Signalverarbeitung gemacht, Multiply/Accumulate, Fixpointarithmetik. Da ist RC4 eigentlich gar nicht weit davon entfernt. Und Krypto mach heutzutage jeder IoT-Controller (das sind allerdings

Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert, sondern immer interpretiert? Das hatte ich anders verstanden.

sagen wir im letzten Jahr wirklich Kopfzerbrechen gemacht haben, das waren allesamt welche bei denen kein Debugger, kein Interpreter-Commandline oder irgendwas mehr hilft, weil das in der

rausgekriegt hab, was das Problem war. Ich glaube Frank Buss hat mir damals geholfen und mich auf den richtigen Trichter gebracht.

Naja, kommt drauf an. Bei einem HMI will ich halt nicht 100ms Warten,

Stimmt.

Neeeh, im Leben nicht. Schrittgenaue Schrittmotorsteuerung, die dann auch noch durch ordertliches (x16) Microstepping schwieriger gemacht wird und bei der die Speed-Ramps ordentlich (Sinus) aussehen ist auf

schnellen (16 MHz AVR) eventuell gerade so, wenn du nicht viel anderes machen musst.

Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand linken muss, ne, das muss echt nicht sein.

Johannes

nicht.

Die Anlage wurde dann nochmal in 3facher Ausfertigung gebaut, also 768

Jeder Kanal kam mit 20kHz IFF rein, jeweils 16bit Laufzeit und 8bit

IRs irgendwann asynchron in dem bis 20kHz Grundtakt.

Und nicht ein einziger IR durfte verschlabbert werden.

unterschiedlichen Tiefen, Richtungen und wehe man hat eine Bohrung am Ende der Anlage nicht mit Farbpistolen angespritzt und markiert.

Der Kunde fands auch nicht lustig, wenn die Compuster mal son ganzes Rohr komplett lackiert haben. Fehlersuche war etwas stressig :)

Die Rohre wurden gerne an Rheinmetall geliefert und die mochten absolut keine Farbe auf den Rohren, nur ihr Testrohr musste in der Farbe des Tages

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Son gequirlter Quatsch. Im parallelen Posting beschreibe ich zwei Monster

30.000g aus. Auch Flugabwehrraketen werden mit Forth in Echtzeit autonom nachgesteuert. Rechne mal nach, wie genau man da alles erfassen muss, wenn bei Ankunft das programmierte Ende der SW auf 2m+-20cm genau eingehalten werden muss. Ja Luftdruck, Temperatur und noch so ein paar

Es kommst mir so vor, wie ein Oberprimaner, der einer alten Bahnhofnutte

Noch ganz zum Schluss: beim RTX2000 hab ich einen IR Eingang mit 2MHz getriggert und auf einem weiteren mich mich 9600Bd seriell mit dem Kerlchen unterhalten, ohne das man da was von der Grundlast merkte. und das in den 1980ern.

Ah ich vergass, die C166 mussten die Forth engine erst noch beigebogen bekommen. Auch kein Akt.

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

[...]

[...]

siehst, ist das Programm kompiliert.

Ist nicht wie bei Basic!

Ja auch in FORTH kann man schlechte Programme schreiben, geht sogar viel schneller.

Schuld. Und wer keine klare Trennung zwischen HW und Anwendung hinkriegt,

Motherboard ausgewechselt, ohne dass die 2 anderen Programmierer irgendwas

oder gar Probleme hatten. Ausser dass das ganze dann viel schneller lief.

Ich hab den Kern und die IR angepasst und gut wars.

Forth hat keinen Linker und braucht auch keinen. Ein Riesen Vorteil.

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

vielleicht 5 Minuten, ein "hello world" in C braucht 10. Go waren auch

ist.

Auch wenn du die RPN gut findest, mir stellen sich die Nackenhaare auf

Okay, dann hat sogar "kompiliertes" Forth eine Performance-Penalty

Ja sehr einsteigerfreundlich, wenn man erstmal den Compiler/Interpreter auf das Target portieren muss.

Ohne Linker ist offenbar 500 Mal besser als mit.

Johannes

LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts entgegenzusetzen hast, hast du das Argument in dem Bereich verloren.

Behauptungen sind krude, dann zeig doch mal Messungen von angeblichem

Dann ist es nur Geschwurbel.

Butter bei die Fische! Zeigen, nicht Labern. Zeig doch mal wie performant das sein kann. Der Faktor 500 ist jetzt schonmal eine Zahl,

Kann durchaus sein, dass in irgendwelchen Spezialanwendungen Hardware gebaut wurde, die das performant interpretiert. Aber auf einem

Anekdoten keinerlei Evidenz liefern kann oder will. Und dann ins

Also deine Behauptung und neuerliche Anekdote ist, dass du eine Interruptfrequenz von 2 MHz in den 80ern so "nebenbei" hattest? Das ist schlicht und ergreifend gelogen und wenn du nur halb der Ingenieur

durchschaut. Rechne mal bei einen minimalen ISR (nicht in Hardware

Instruktionen, um was sinnvolles zu machen durch.

Johannes

Am 17.08.2019 um 08:27 schrieb Johannes Bauer:

immer gleiche FORTH Code. Ich habe heute noch den Karteikasten mit den Implementierungen der Worte zu meinem Lieblingsforth.

ist schon passiert.

DoDi

Am 17.08.2019 um 05:34 schrieb Wolfgang Allinger:

viel bringt, wenn dort ein VARIANT Datentyp verwendet wird - siehe VisualBasic.

FORTH erlaubt Compilierung bei der Eingabe, was aber nicht Compilierung in Maschinencode bedeutet, und auch nicht unbedingt in anderweitig

IMMEDIATE Mode (bei der Eingabe) normal abgespeichert wird, aber direkt weiteren FORTH Code erzeugt, wenn es in der abgespeicherten Version

Parser wird ja von FORTH geliefert.

Schau Dir mal die Stack-Beschreibung an, die zu jedem Wort angegeben

so ein Mechanismus nicht bekannt.

Ich habe mir seinerzeit etliche Bibliotheken angeschaut, die ohne

es so eine Dokumentation, aber wenn die nicht auf den Disketten mitgeliefert wurde, war man in der Zeit vor dem Internet mit dem Quelltext alleine einfach nur aufgeschmissen :-(

DoDi

Da war die Arithmetik aber sicher nicht mit den FORTH Primitives

HMI?

Schlechtes Beispiel, wenn das Entprellen eines Knopfes schon 10-20ms kostet, egal wie schnell der Prozessor oder die Programmiersprache ist. Und auf Interrupts kann man auch in FORTH direkt reagieren, wieso nicht?

man das so machen? Motortreiber braucht man sowieso, und die gibt es passend mit Microstepping, Strombegrenzung etc.

DoDi

Johannes Bauer :

entgegennimmt, im Fehlerfall ein Standard-THROW exekutiert, als ABORT, womit alle Schachtelungen aufgehoben werden und der Text-Interpreter wieder neu beginnt.

INCLUDED nimmt Text aus einer zeilenorientierten Datei entgegen. THRU macht

mit einer Zeile, die als String-Parameter gegeben wird.

Eine Schicht darunter wird man eher von Code reden, da nicht mehr Textfolgen abgearbeitet werden, sondern kompilierte Folgen im Speicher. Dass dennoch das Wort Interpreter ins Spiel kommt, liegt daran, dass die Modelle, wie

zu der Zeit etwa bis MItte der 1990er, dem kundigen Nutzer das mitzuteilen, wie die Schacthelung von Code im Speicher organisiert ist.

Nunmehr ist der kundige Nutzer auch nurmehr ein braver Konsument und fragt nicht mehr nach so etwas, bzw. ist eher irritiert.

die das korrespondiert, dass der Code aus einer Abfolge von Tokens besteht. Und die Tokens, wenn sie zur Abarbeitung angesprungen werden, sind dann wiederum Abfolgen von Tokens.

Erst die unterste Schicht von Tokens sind dann in Assembler kodiert.

Noch in den Forth-79 und -83 wurde das fein kultiviert, mitzuteilen, auf welche Art die Tokens angesprungen wurden. Im kompaktesten Fall besteht selbst noch der Beginn eines Tokens aus einem Verweis auf ein Token, dem die Kette der folgenden Tokens mitgeteilt wird, und startet den Mechanismus des Schachtelns und Weiterschaltens (typischerweise ein kleines Code-Schnipsel, mit dem Namen NEXT).

Das ist die kompakteste und dann auch zugleich langsamste Form, wie der Code

Hardware-Architektur vor sich hat, wo der letztliche Assmember strikt

implementieren. Die kann dann, mit ein wenig Forth-Assembler-Code im ROM, rein vom RAM laufen.

minimale Forth-Assembler im ROM als Maschinen-Monitor dient, mittels dem per ad hoc dazukompilierten Routinen die Maschine auf ihr Befinden hin abfragt

Stadium weg am Objekt selbst modellieren kann, ohne dass man eine Emulation

Wenn der Zeittakt der Umgebung aber eher in Sekunden misst, ohne Milli oder Mikro, dann braucht es keinen weiteren Luxus zur Beschleunigung.

die kleinen Prozessoren dann im emulierten ROM per Assembler-kompiliertem Forth.

Letzteres ist dan schon die dritte Variante des Interpretierens von Assembler-Code auf Maschinenebene, indem eben der Compiler alles, was im

schlau mit dem Code zuvor und danach verkettet. Es muss ja weiterhin die

Verschachtelung erreicht werden.

Tokens nicht selbst wiederum einen Zeiger auf das Token verweist, mit dem Verschachtelung und Weiterschalten im Code organisiert ist, sondern diese kleine Standard-Routine steht dann in Assembler zu Beginn von jedem Token.

wird. Oder auch nicht. Aus letzterem wird zwar auch eine lustige Maschine, aber viel machen kann man damit nicht wirklich, oder nur bei ausnehmend

***

wird angenommen dass jemand der mit dieser Maschine arbeitet, genug

Routinen auf, und deren Schnittstellen sollten dann doch wohl auch weiterhin stabil bleiben. Wer dann nachher an den Schnittstellen herumdreht, bzw. das dann nicht im Griff hat, wenn er es trotzden macht, dem ist dann wohl nicht zu helfen. Es gibt da keinen reichen Onkel, als wie ein solcher sich die

locker dahin.

kompiliertem Code nicht entwickelt. Das ist keine Frage des Systems sondern der Historie. Man kann das auch in Fortg einbauen, dass es kompilierten Code

Das Modell des Open-Boot-Systems hat dann die Tokens normiert ... was ebenso

mit dem Handling von APDUs im Mittelpunkt, wie mit der ISO 7816 begonnen,

Wenn dann Folgen von Tokens ausgetauscht werden, ist man bereits auf

Und das ist dann schon die Schicht, wie Libraries gestrickt sind.

abklopfen, was denn gemeint ist, wenn Libraries ausgetauscht werden. Die Architekturen sind weniger technisch als auch historisch bedingt.

Wenn es darum ginge, sich des Mainstreams zu bedienen, wo massenweise die

in Forth eine harte Klippe, das ist die Konstruktion des Aufbaus mit

Auch das ist wohl nur historisch bedingt - wahrscheinlich auf die

das Personal zu seiner Zeit etwas stringenter in analytischen Dimensionen

bedingten Erfordernisse viel naheliegender.

Der Vorteil, den Forth in dieser Hinsicht hat, ist immens, als da Verschachtelungen viel bililiger zu haben sind, wenn nicht bei jedem Sprung im Code zugleich der Zusanmenhang der Daten zwuschengesichert werden muss. Das erspart man sich, wenn die Parameter transparent auf einem gemeinsamen Stack durchgereicht werden. Von daher wurde typischerweise in Forth stets mit kleinen Routinen kodiert, mit den anonymen Parametern auf dem Stack.

parallel dazu, dass Unix-Maschinen sich verbreiteten. C verbreitete sich erst einmal ganz spezifisch mit letzteren - aber auch ist hier die Tradition aufrecht geblieben, dass, auch in C, Quelltexte korrespondiert werden, es

Das Interesse, dass nur kompilierte Libraries im Umlauf sind, ist eher

uneinsehbaren kryptischen Datenhaufen in Plastik zu verpacken und teuer

Normierung auskungelte, von allzu konkreten Implementierungsdetails Abschied zu nehmen und abstraktere Prinzipien stattdessen aufzunehmen, sodass unter

Ist eben genau ein gutes Beispiel: Das Entprellen dauert schon die

auch schon eher 50-75ms ansetzen. Und dann willst du dem Benutzer

*sofort* signalisieren, was passiert ist.

Wenn du da ein LCD oder sowas dran hast, das bissl mehr braucht als nur GPIO LED an/aus, dann merkst du das sehrwohl. Und es gibt genug

langsam, 16 MHz als schnell und 48 MHz als superschnell bezeichnen.

Motortreiber mit Microstepping machen aber halt nur das, was der Name

dieselbe Geschwindigkeit.

angeflanscht direkt an den Stepper und der nimmt z.B. via RS232 Kommandos entgegen, die ihn wie einen Servo aussehen lassen).

Johannes

Hello World dauert in FORTH nur solange, wie man tippen muss :p

OK> : Hello ." Hello World, hello Johannes" ; Hello

Quatsch mit Sosse, auf neuen Kern anpassen (1-3d Manntage) muss man nur, wenn man FORTH auf einen neuen Processor bringen will und man im Netz

FORTH Programme laufen lassen, die mit Standard I/O auskommen. Mach das mal in einer anderen Sprache oder versuch mal andere Interpreter auf eine

es kein FORTH gibt, die eine waren die Ur-PICs, und dann war da noch

mit der Art des Speicherzugriffs (Harvard Ecke?).

Als grobe Faustformeln:

1. Eine FORTH Anwendung oberhalb des Kernels braucht nur 1/10 des Platzes

passte in 2kB.

1. FORTH Geschwindigkeit liegt auf der Scala ASM = 1 und Basic = 100, etwa bei 10. Mit Gewalt auch weit niedriger, bis an

Keine Ahnung, was Du da mit RC4 gemacht hast, hab weder Zeit noch Lust das nachzugroffeln.

aus?

Wenn FORTH fertig mit dem Lesen einer Quelle ist, ist wenige

rumdrehen!

Ich hab ja nicht gesagt, dass die 2MHz was besonders sinnvolles gemacht

incrementieren 100ns. In diesen 100ns konnte der bis zu 4 (5?) Befehle

SW!

und Physikern :p

Und tut mir leid, dass der RTX2000 keinen Assembler als Maschinencode hat. Nur FORTH :p Er besteht IIRC aus etwas mehr als 4.000 Gattern. Der

auch egal, die RTX2000 waren ja schon mal ne Hausnummer.

Mercedes, hatten einen MARC 4 (4!!! bit FORTH Processor) von Temic (ex Telefunken) drin. Nein, MERCEDES hat das nicht besonders geschickt und vorbildlich implementiert, sitzen auf zu hohem Ross :) Einer der MIL Wegwerfartikel hatte auch nen MARC4 drin, im Gegensatz zu

Desterwegen sind die Dinger inzwischen auch sehr rar geworden.

(armer Johannes), sowie mit Video und Radar im Kopf gesteuert wurden. Anfangsbeschleunigung umme 30.000g :o Und ich glaube nicht, dass das eine langsame Anwendung war :p Oder die FORTH wegen Lahmheit genommen haben.

Es wurde seinerzeit gemunkelt, dass die Patriots auch mit RTX2000 flogen,

Hard). Hab da mal die restlichen 10 aus meinem Handlager gut versilbert :)

Die Honks bei Harris haben alle Entwickler gefeuert und wollten so richtig Absahnen, als dann der Nachschub klemmte, und die Entwickler in aller Welt

noch gibt. Gier frisst Hirn!

selber gemacht um das auch mal probiert zu haben. Wieviel C Kerne hast Du schon geschrieben?

nicht verstanden?

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Nein, BASIC interpretiert immer wieder, erst ein BASCOM setzt das als (p-

Bei FORTH die sog. META Compiler.

Das eine sind die COLON (HLL) Definitionen, das andere die CODE (ASM) Teile.

So isset, ein Beispiel, u.a. mit IMMEDIATE unten dran gepappt.

Und wem das nicht reicht, es gibt auch noch CREATE DOES> , was Unterschiede zur Compile und zur Laufzeit macht. Hab ich u.a. gerne

sind elegant mit CREATE DOES> .

Kann mir auch keinen Reim drauf machen.

Wenn irgendwer halt ne andere Reihenfolge oder Menge braucht, soll er hat ein neues Wort definieren, dann crasht nix.

Doof ist allerdings, wer die Warnung "... is redifined" in den Wind

sofort sichtbar.

Ich hab nie behauptet, dass alle FORTH Programme oder Programmierer gut

Das Dicke Ende, also das interessanteste ist der Abschluss mit "Feueralarm_bearbeiten", siehe ziemlich letzter Abschnitt.

----x8---

\ FEUER Demo FEUERMELDER Anwendung ALL 11:26 14MAY93 \ Last changed screen # 000 ALL 11:26 14MAY93

\ (C) 1993 by Dipl.-Ing. Wolfgang Allinger 'ALL0593' \ c/o Ingenieurbuero Allinger \ Brander Weg 6 Tel/FAX: (+49)+212/66811 \ D-42699 Solingen Germany \ noncommercial use granted !!!

\ selbstdokumentierende Sprache am Beispiel eines FEUERMELDER \ aussieht. Hinweis: alles in "( )" und nach "\" ist Kommentar. \ ":" ... ";" sind neue Definitionen. \ "Feueralarm?" und "Feueralarm_bearbeiten" sind 2!! Programme. \ Diese Demo belegt weniger als 700 byte Programmspeicher und

\ HISTORY MASTER LOAD SCREEN ALL 11:19 14MAY93

DECIMAL \ default base

000 CONSTANT $VFEUER \ Version Kontrolle

: -FEUER FORGET $VFEUER ; \ entfernt dieses Programm wieder

2 ?SCREENS THRU \ 1 LOAD l"dt dann die Anwendungsbl"cke \ bei SEQ file system auskommentieren !

\ ALL0593 v0.00 first release

\ .VFEUER ... constants ... USER Interface ALL 10:16 14MAY93

: .VFEUER $VFEUER CR . ; \ zeige Versionsnr.

-1 CONSTANT ja

VARIABLE Meldung \ bits gesetzt wenns qualmt, n. Zeile setzt 5 Meldung ! \ zB: bit0 = Melder1, bit2 = Melder3 : Melder@ ( a -- u ) @ ; \ liefert Datum aus Adresse Meldung CONSTANT Melder0 \ liefert Adresse der 1. Meldung

16 CONSTANT bits/Meldung \ zB 16bit oder was auch immer 16 CONSTANT alle \ Anzahl Melder

VARIABLE Rauchmelder \ 1 ... n

: abfragen ( a -- uMASKE uDATA )

@ 1- bits/Meldung /MOD ( -- rem qot ) Melder0 + Melder@ ( -- rem uDATA ) 1 ROT ( -- uDATA 1 rem ) SHIFT ( -- uDATA uMASKE ) \ rem -> MASKE SWAP ; ( -- uMASKE uDATA )

: entdeckt? ( uMASKE uDATA -- t=RAUCH) AND 0> ;

: Feueralarm ( -- ^string nMelder )

" Rauch an Melder Nr.: " ( -- ^string ) Rauchmelder @ ;

: melden ( ^string n -- ) CR SWAP COUNT TYPE . 7 EMIT ;

: abgefragt? ( n a -- ? ) @ 1-

[...]

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Harte Fakten werden nicht gemocht, weil sie alle 'Optionen' ersticken.

Ich habe auch mal einen Test gemacht, auf ein und derselben Plattform, mit gleichen Mitteln und Aufgaben auf Software-Ebene.

Ergebnisse des jeweiligen Zeitbedarfs (1996): C 1 Pascal 5 COBOL 80

C ist nicht zu toppen! Das bewahrheitet sich immer wieder.

--

Helmut Schellong   var@schellong.biz 
www.schellong.de   www.schellong.com   www.schellong.biz 
http://www.schellong.de/c.htm