Re: Nette Features in C# 3.0

Sebastian Biallas <groups.5.sepp@xxxxxxxxxxxxxxx> writes:
> 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.

> 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. 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). 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).

>> 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.

[...]

>>>>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. 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). 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).

Fazit: Das Beispiel ist ungeeignet.

>> Ferner ist es eine technische Fehlannahme, das der letztlich
>> konstante Aufwand zur Erstellung einer Software auf Kosten des
>> Aufwands, der fuer die Benutzung dieser Software notwendig ist,
>> minimiert werden sollte.
>
> Richtig. Hab ich allerdings weder behauptet noch angedeutet noch
> unterstellt.
>
>> 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'.
.