Re: Nette Features in C# 3.0

Rainer Weikusat wrote:
> Sebastian Biallas <groups.5.sepp@xxxxxxxxxxxxxxx> writes:
>>Rainer Weikusat wrote:
>>>Sebastian Biallas <groups.5.sepp@xxxxxxxxxxxxxxx> writes:
>>>>Rainer Weikusat wrote:
>>>>
>>[Exception vs. Interrupt]
>>
>>>>Der Unterschied ist marginal und für die Diskussion vollkommen
>>>>irrelevant.
>>>
>>>Es ist eine Frage der korrekten Verwendung technischer
>>>Terminologie.
>>
>>Und wahrscheinlich wirfst Du auch Intel vor, die IDT fälschlicherweise
>>"Interrupt Descriptor Table" und nicht "Interrupt, Exception, Trap,
>>Fault, Double Fault, Triple Fault und was weiß ich Descriptor Table"
>>genannt zu haben.
>
> Ich tue vermutlich bloss aeusserst selten etwas, was Du Dir in Deiner
> Phantasie ausmalst.

Meinetwegen.

>>Und die Jungs von IBM und Motorola sind wahrscheinlich
>>auch unfähig, technische Begriffe korrekt zu verwenden, wenn sie den
>>ganzen Sums unter dem Kapitel "6. Exceptions" abhandeln.
>
> Ich habe das PPC Operating Environment Architecture Book III --
> Version 2.01 zufaelligerweise hier rumliegen.

Und ich habe hier "PowerPC[tm] Microprocessor Family / The Programming
Environments", 1/97, REV.1

> Das relevante Kapitel
> ist Kapitel fuenf, betitelt 'Interrupts' und so wie die beiden
> Begriffe dort gebraucht werden, beschreibt 'exception' die Operation
> der Hardware und 'interrupt' die dadurch ausgeloeste Operation einer
> Software (Beispiel: '[...] External and Decrementer are maskable interrupts
> While MSREE=0, the interrupt mechanism ignores the exceptions that
> generate these interrupts. [...], p. 52).

Die sind halt selber nicht konsistent mit ihren Bezeichnungen:
Kapitel 6 "Exceptions", erster Satz aus obigem Dokument:
| The operating environment architecture (OEA) portion of the PowerPC
| architecture defines the mechanism by which PowerPC processors
| implement exceptions (referred to as interrupts in the architecture
| specification).

In diesem Kapitl wird auch eine Exception mit dem Typ "External
Interrupt" beschrieben.

> Ein weiteres Beispiel fuer
> die unterschiedlichen Bedeutung beider hatte ich fuer eine andere
> Architektur angefuehrt und zwar fuer ARM: Da kennt der Prozessor
> eines gewisse Zahl von 'exceptions', die ihn in bestimmte Modi
> schalten und in einem bestimmten Anfangszustand beginnen, Code an
> einer durch Software definierten Adresse auszufuehren, von denen eine
> als '[device] interrupt' dient und einen weitere als 'fast interrupt'
> (Hauptunterschied: Der FIQ hat einen groesseren Satz eigens fuer ihn
> reservierter Register).
>

Wenn ich das richtig verstehe, dann kann dort eine FPE sogar schneller
als ein externer Interrupt behandelt werden...

>
>>>Jeder interrupt ist ein 'normaler Interrupt' (bis
>>>dorthin hat sich die Kuechenpsychologe noch nicht vorgearbeitet) und
>>>eine 'exception' ist weder ein normaler noch sonst ein Interrupt.
>>
>>Das staunende Publikum fragt sich nun, warum der x86-Prozessor bei einer
>>Exception trotzdem in der Interrupt Descriptor Table nachschlägt, was zu
>>tun ist.
>
> Das waere eine Fragenstellung, die einer Antwort aus dem Bereich der
> technischen Etymologie bedarf.

Vielleicht sieht Intel auch einfach nur, dass man a) sowieso einen
Obergriff für das Unterbrechungsgedöns braucht (wie nennst Du das
eigentlich?) und b) der Unterschied in den meisten Fällen irrelevant ist.

>>>>>Ist Dir schon mal der Gedanke gekommen, dass die weitaus meisten
>>>>>Computer weder PCs sind, noch mit Ghz-CPUs irgendwo als Heizung
>>>>>arbeiten und vor allem, dass das vollkommen ohne Belang ist, weil
>>>>>'sinnlose Verschwendung' als solche kein wuenschenswerter Zustand ist,
>>>>>unabhaengig davon, ob man sie sich zufaellig leisten kann, oder nicht?
>>>>
>>>>Ich verschwende gerne "sinnlos" Prozessorzeit, wenn ich dafür robustere,
>>>>fehlertolerantere oder einfach nur bessere Programme bekomme oder in
>>>>kürzerer Zeit schreiben kann.
>>>
>>>Praktische Erfahrung zeigt allerdings, dass Du das alles nicht
>>>bekommst.
>>
>>Meiner praktische Erfahrung zeigt mir etwas anderes.
>>Der gcc, wohl ein Musterbeispiel an einem robusten Programm, war für
>>mich schon mehrmals ein Indikator für kaputtes RAM (nicht
>>reproduzierbarer ICE -> memtest). Er testet halt an jeder Ecke
>>doppelt und dreifach seine internen Strukturen.
>
> 'gcc' ist aber ein C-Programm, dh er ist gerade nicht in einer Sprache
> mit Ausnahmen als 'primitves' geschrieben.

Solange ein Programm tut, was ich von ihm erwarte, interessiert mich
nicht, in welcher Sprache es geschrieben ist. Ich habe auch nichts gegen
C BTW, das richtige Werkzeug für die richtige Aufgabe. Einen C-Compiler
schreibt man sinnvollerweise immer in C.

> Die Aussage 'gcc ist ein
> Musterbeispiel eines robusten Programmes' solltest Du ausserdem mit
> einer Mindestversionsnummer und einer Architektur verknuepfen, dann
> stimmt sie vielleicht ein bisschen :-> ('internal compiler errors'
> scheinen tatsaechlich seltener geworden zu sein, als sie das mal
> waren, allerdings koennte dieser subjektive Eindruck auch daher
> ruehren, dass ich den C++-Teil fuer nichts mehr benutze).

Die gccs der letzten Jahre fand ich allesamt ziemlich stabil.

> Ueber
> gcc-Crashes bei 'linux kernel Compilation', die Speicherfehler
> aufdecken, gibt es sogar (seit Jahren) eine FAQ-Seite:
> <URL>http://www.bitwizard.nl/sig11/>) [ich kenne die wenigstens seit
> Kernel 1.2.13 und da war sie schon nicht mehr neu]. "Interne
> Konsistenzpruefungen" durch Software macht man ausserdem als 'band
> aid' gegen Software-Fehler und gegen Hardware-Fehler sind sie
> essentiell nutzlos (zB kann sich der Code, der die Ueberpruefung
> macht, genausogut aufgrund eines memory errors spontan aendern, wie
> die Daten, die er ueberprueft).

Dass man mit kaputter Hardware schlecht kaputte Hardware testen kann,
ist klar. Das gilt aber genauso für memtest. Es ist aber oft ein
hinreichendes Kriterium für kaputte Hardware, wenn diese Programme einen
Fehler melden.

Ein Beispiel für ein unrobustes Programm ist übrigens der Mozilla.
Insbesondere weil jedes Drecksplugin da im Speicher rumpfuschen kann.

>
> Fazit: Das Beispiel ist ungeeignet.

Woraus folgst Du das?

>>
>>>Vereinfacht formuliert: Es ist fuer Dich
>>>immer billiger, wenn jemand anderer die Rechung bezahlt.
>>
>>Ich kaufe mir meine private Hardware und Software durchaus selber.
>>
>>>Sie wird aber
>>>dadurch nur relativ kleiner und nicht absolut.
>>
>>Was das alles mit "ich bevorzuge fehlertolerante Software" zu tun hat,
>>ist mir irgendwie schleierhaft.
>
> Nichts. Es bezog sich auf die 'schneller entwickelbare Software'.

Wenn ich mit Programmiersprache A in kürzerer Zeit ein min. gleich gutes
Ergebnis wie die Konkurrenz mit Programmiersprache B erziele, dann ist
das wohl ein klares Kriterium für A.

Gruß,
Sebastian
.