Vom PIC zum AVR

[Holm Tiffe]

In article <40A1E725.1000201@mew.uni-erlangen.de>,
Uwe Hercksen <hercksen@mew.uni-erlangen.de> writes:

Holger Klabunde schrieb:

das ist der größte Schwachsinn den ich je gehört habe. Ich kann ein Programm mit Absturzgarantie
in C, Assembler, Pascal , Basic oder Fortran und was es da sonst noch gibt schreiben.
Hallo,
die Gefährlichkeiten eines Pointers scheinen Dir nicht klar zu sein.
In Sprachen die keinen Pointer haben und alle Feldgrenzen auf Einhaltung > überprüfen kann man nicht einen Absturz provozieren indem man an einer
Adresse schreibt wo man nichts verloren hat.
Bye

Aber Hallo,

was denkst Du macht eine Portausgabe unter Pascal?

Die schreibt z.B. 0x08 auf 0x378. Was denkst Du, was 0x378 in
diesem Falle ist? Richtig, ein Pointer auf eine IO Adresse im (IO) Adreßraum
des Prozessors.

Ein Pointer ist also böhhse.

Mit einer Sprache, die das nicht ermöglicht, möchte ich nicht programmieren,
denn der Bildschirm wird wohl dunkel bleiben, wenn man das OS damit schreibt.
Oder ist C als darunter liegende Sprache für das Betriebssystem und die
Laufzeitbibliotheken plötzlich gut genug?
Dazu war C mit seinen Pointern mal gedacht, um hardwarenah und schnell
programmieren zu können, dazu braucht man Pointer auf Adressen.
Alternativ kannst Du in Assembler programmieren, das ist noch hardwarenäher
und noch schneller und noch fehlerträchtiger und noch pointriger...

Holm

--
L&P::Kommunikation GbR Holm Tiffe * Administration, Development
FreibergNet.de Internet Systems phone +49 3731 41930
Bereich Server & Technik fax +49 3731 4196026
D-09599 Freiberg * Nonnengasse 31a http://www.freibergnet.de

 

[Rolf Bombach]

Holger Klabunde wrote:

das ist aber kein Fehler von C sondern der Fehler der Programmierer.

Na sicher ist das ein Fehler der Programmierer. Aber die Eigenschaften von C
provozieren diese Probleme.

das ist der größte Schwachsinn den ich je gehört habe.
Ich kann ein Programm mit Absturzgarantie
in C, Assembler, Pascal , Basic oder Fortran
und was es da sonst noch gibt schreiben.
Das liegt nicht an der Hochsprache sondern am Programmierer. ...

Mach's mal 1/2-lang. Etwa die Hälfte bezog sich ja auf
die (Menschen-)Lesbarkeit des Programms und nicht auf
die Stabilität oder Fehlertoleranz von Prog oder System.

Hobbyfroschprogrammierer, ich schliess jetzt mal von
mir auf andere, haben ja Mühe mit der Einsicht, dass
ein klarer Programmierstil a) nicht für den Compiler
einfacher ist ;-), sondern für den nächsten Programmierer
(üblicherweise man selber)und dass b) so was dann schnell
10x mehr Zeit braucht als Hack-run-crash-alter Produkte.
Nunja, Vorgesetzte kapieren das idR auch nicht.

Unleserlicher Stil wird nun aber mal ermöglicht durch
stark nicht-orthogonale Sprachen wie C. Und von ermöglicht
zu gefördert ist nicht weit bei dem allgemeinen Mangel
an Selbstdisziplin :-]

--
mfg Rolf Bombach

 

[Rolf Bombach]

Hergen Lehmann wrote:

Die weitaus meisten Softwareprojekte haben nur einen winzigen
Bruchteil des Etats und der Entwicklungszeit im Vergleich zu einem
Raumfahrtprojekt. Du vergleichst Äpfel mit Birnen.

Naja, ein Raumfahrtprojekt als Vergleich zu nehmen, find ich
ziemlich happig. BTW, ich hoffe, man hat eine Vorstellung,
wie gross der Aufwand heutzutage allen für ein reichlich
dämliches Computerspiel ist.

Btw.: Bei den Mondlande-Programmen der Amis und Russen ist so manches
wild zusammengeschustert worden, nach Plänen, die höchstens in den
Köpfen von einer Handvoll Genies existierten. Deshalb kann man diese
Trägersysteme heute auch nicht mehr nachbauen, selbst wenn man wollte.

Da wurde wol noch viel von Wernie übernommen...
Ausserdem ging es um bemannte Raumfahrt. Da wird so
gut wie nichts neu erforscht, so wenig wie möglich
entwickelt und so weit wie möglich auf Sachen zu-
rückgegriffen, die seit 20 Jahren funktionieren.

Man braucht Pläne um große Systeme zu erstellen.

Nicht zwingend.

Gerade bei *wirklich* umfangreichen Systemen, die man nicht mehr als
Ganzes überschauen kann und bei denen die Projektleitung gar nicht
weiß, ob sie überhaupt in die richtige Richtung denkt, sind konkrete
Pläne sogar eher schädlich. Denn sie schränken die Kreaktivität der
Spezialisten massiv ein, und verhindern damit zweckmäßige Lösungen.

Klar, bei unfähiger Projektleitung muss ja jemand anders
das Denken übernehmen...

Wenn die Raketenentwicklung mit dem Ziel begonnen hätte, das
Sonnensystem zu erforschen, hätte vermutlich nie ein Mensch diesen
Planeten verlassen.

Toll, zufälligerweise hat jetzt aber die Raketenentwicklung
damit begonnen, die Atmosphäre und den Weltraum zu erforschen.
Hat sich dann allerdings auf die Bombardierung Londons verlagert.

Wenn die Elektronik mit dem Ziel begonnen hätte, eine Maschine zu
konstruieren, die sich gleichermaßen als Schreibmaschine, als Archiv,
als Analysewerkzeug, als Kommunikationsmittel, und zur Unterhaltung
eignet und auf einen Schreibtisch paßt, hätten wir wohl heute keine
Computer.

In die Richtung ging aber die Entwicklung der Computer und
Systeme. Die Verarschung fing erst damit an, dass IBM&Co
behaupteten, sie hätten so ein Ding wie du es oben beschrieben
hast, und hat den Leuten den PC, dann den XT, AT, usw...
angedreht. Jetzt steht die 7. Generation dieser Blechkisten
auf/unter dem Schreibtisch und langsam scheinen sie das
zu können, was seit eher behauptet wurde. Und so wirklich
überzeugen tun die Produkte des selbsternannten SW-Markt-
führers eigentlich auch nich richtig ;-]

Einfach weil beides aus damaliger Sicht nicht greifbar und damit nicht
planbar war.

Die Abzocke war geplant und hat eine zeitlang funktioniert.
Jetzt schwenkt's um Richtung profitloser Prosperität. Das es
funktionieren könnte, war bekannt; abgesehen von den Unter-
haltungsfunktionen gab's alles schon von 30 Jahren mit Mainframe/
Terminal-Systemen. Viele Sachen wurden auch zwei mal erfunden,
etwa die Maus.

bottom-up (also das Entwickeln und Kombinieren von Bausteinen mit
einem nicht oder nur vage formulierten Endziel) ist eine durchaus
anerkannte Entwicklungsphilosophie, die zwar nicht immer exakt zu dem
Ergebnis führt, was man anfangs im Sinn hatte, aber doch meist zu
etwas, das irgendwie nützlich und verkäuflich ist. Oft sogar weit
mehr, als die anfängliche Idee.

SW vielleicht, aber du hast das Thema auf Raumfahrt gebracht.
Mit obigem Prinzip baust du sicher kein Verkehrsflugzeug, AKW,
Synchrotron, ....
....

Anders als bei mechanischen Produkten ist es bei Software nicht
erforderlich, der Fertigungsweg jederzeit mit identischem Ergebnis
nachvollziehen zu können.

Das erklärt einiges :-]

--
mfg Rolf Bombach