Zi3 schrieb:
> Wobei sicher nichts dagegen spricht einfach verschiedene
> Abstraktionsebenen anzubieten.
Diese Ebenen gibt es ja schon und sie werden auch bedient. Es geschieht
nur eben nicht automatisch, wie es sich mancher Träumer vorstellt. Das
Markante an der Problematik ist einfach, das es ja die typischen
"Softwareaspekte" sind, die abstrahiert und "vereinfacht" werden
(sollen).
Wenn da der Fokus liegt, geht das prima.
Es bleibt aber der Umstand, dass eine effektive Softwareentwicklung
immer Kenntnisse der HW erfordert, d.h. eine bekannte Struktur
voraussetzt.
Es läuft also immer wieder auf die Nutzung eines Cores hinaus, weil
keiner ständig eine neu adaptierte HW bauen möchte.
Die über diese Anforderungen darüber hinaus noch zu implementierende
Sonderhardwarefunktion erfordert aber immer wieder eine spezielle
Schaltung, die sich eben nur zum Teil durch ihren Ablauf beschreiben und
sich nicht aus der SW-Beschreibun ableiten lässt.
Das ist nun mal so und grundsätzlich niemals zu ändern.
Was sich nur ändert, ist nur der Fokus, also das Verhältnis von SW und
HW bei einer APP: Man wird sich aus (kosten)technischen Gründen eher mal
mit suboptimaler HW zufrieden geben und mehr in die SW verlagern, wenn
die HW preiswerter wird und man etwas verschwenderischer damit umgehen
kann.
Den Prozess haben wir ja heute schon. Es wird mit mehr Tempo und weniger
Optimierungseinsatz entwickelt und zwar was HDL für FPGAs und auch CPP
für MCUs angeht.
Was das muntere Austauschen von HW-Funktionen in FPGAs in Echtzeit
angeht, sehe Ich da enge Grenzen:
FPGAs sind aufgrund der Universalität letztlich ziemlich langsam und
profitieren von speziellen Strukturen, die nur bei bestimmten
Randbedingungen wirklich effektiv sind. Besonders pipelines und
multithreading FSMs liefern ganz bestimmte Soll-Verhältnisse für
Kanalzahl, Frequenz und Zugriffsoptionen. Da lässt sich nur schwer was
umändern, um dynamisch schneller zu werden.
Die FPGAs im Umfeld der CPUs haben mithin ihre Hauptbedeutung weiterhin
darin, sich gegen Fehler bei Auslieferung zu schützen oder sich auf
mögliche Änderungen der Funktion oder künftige, zum Zeitpunkt der
Entwicklung noch unbekannte Peripherie vorbereiten zu können. Und genau
das macht Intel.
