News Historischer Support wird gestrichen: Linux verabschiedet sich endgültig vom Intel 486

[|L1n3]

Ich glaube hier herrscht etwas Verwirrung was das bedeutet: Gestrichen wird nur die offizielle Unterstützung für 486er Systeme. Das heißt nur: Bei neuen Releases wird der Kernel nicht mehr auf (emulierten) 486er Systemen getestet und dementsprechend wird der Code auch nichtmehr so angepasst, dass er auf 486er Systemen läuft. Es steht jedem weiterhin offen den Kernel auf ein 486er Zielsystem zu kompilieren, ob das dann Fehlerfrei funktioniert ist aber offen. Je weiter die Kernel Entwicklung vorranschreitet desto wahrscheinlicher wird, dass man selbst nacharbeiten muss. Die speziell für den 486er eingefügten Codepfade werden entfernt, denn die wären absolut obsolet in den Sources mitzuschleppen wenn ein kompilieren auf diese Architektur nichtmehr vorgesehen ist. Genau wie beim 386er Support Ende kann es hier eine Gruppe von Menschen geben, die Willens sind diese Aufgabe weiterzuverfolgen. Es heißt einfach nur, dass sich ab hier die Wege der Linux-Kernel Entwicklung und der 486er trennen. Wenn es einen 486er Fork gibt, dann werden diese die letzte Version mit 486er Unterstützung als Basis nehmen und zukünftige neuerungen im Kernel selbst in ihren Fork einpflegen müssen, das kann einfach sein, wenns ohne Anpassungen funktioniert, das kann kompliziert werden wenn Anpassungen extra für den 486er notwendig sind. Und genau um diese Arbeitszeit gehts, die will man weg von den offiziellen Kernel Maintainern nehmen. (aktuelles) Linux auf 486er CPUs stirbt erst dann wenn niemand mehr gewillt ist das weiterzupflegen, solange es noch Menschen gibt, die da ein Interesse dran haben wird sich daran aber erstmal nichts ändern, nur, dass es eben nichtmehr auf der offiziellen Ebene passiert, sondern auf der Seite derer, die am Fortbestehen irgendein Interesse haben. Das kann eben auch bedeuten, dass eben Entwickler das zukünftig stemmen müssen, die dafür von denen bezahlt werden, die ein finanzielles Interesse am Fortbestehen haben, aktuell wird dafür mitunter aber eben auch Geld der Linux-Foundation und anderen Geldgebern genutzt, die die bezahlten Kernel-Entwickler finanzieren, die wiederum dann Zeit aufbringen müssen ein Codepfad für ein System zu pflegen, dass nur sehr sehr sehr wenige überhaupt noch nutzen.

 

[KevinSimulinski]

Vermutlich weniger aus Effizienz als aus Sicherheitsgründen (Speicherschutz)

In dem von dir genannten Link findet sich im BIld mit dem cmpxchg8b_emu ein wichtiger Kommentar:
Emulate 'cmpxchg8b (%esi)' on UP ...'

Der cmpxchg8b kann nämlich mit einem Lock-Präfix versehen werden, ist dann atomar und das dient in in Multi-Core-Umgebungen, wie wir sie heute haben, zum Verwalten von Mutex (Prozess-Synchronisation). Man bedenke: der 486 war ein Uniprozessor, der hat so was nicht benötigt!

Aber die Liste geht weiter: 486 ohne 487 kein natives Floating Point, Pentium Paging-Erweiterungen und und und.
Sicher kann man so etwas ersetzen, das ist allerdings aufwändig, fehleranfällig und dürfte sich aber durch viele Module und Libraries ziehen.

werden. Wenn man dem Compiler sagt, dass die CPU, für die man kompiliert kein AVX-512 kann, dann werden diese Aufrufe halt durch sequentielle Berechnungen ersetzt.

SSE und AVX werden nicht nur zum Rechnen, sondern auch zum schnellen Kopieren von Speicher verwendet, beides hatte der 486 nicht. Und es gibt sicher Programme, die SSE bzw. AVX inline haben, wenn es schnell gehen muss. Auch müssen diese "Workarounds" in zig Libraries mitgepflegt (und getestet) werden.

Ich denke, der Hauptgrund - wie ich das auch von anderen Plattformen kenne - ist die mangelnde Verfügbarkeit von Sytemen mit 486 Prozessoren. Wer kann da noch Kernel-Modifikationen testen?

Und was soll ein der Kernel-Entwickler (oder Redhat oder SLES, die ja bezahlten Support anbieten) machen, wenn ein professioneller Kunde Kunde mit einem Bug kommt, der auf einem 486-System und nur dort auftritt?

Wenn es einen 486er Fork gibt, dann werden diese die letzte Version mit 486er Unterstützung als Basis nehmen und zukünftige neuerungen im Kernel selbst in ihren Fork einpflegen müssen, das kann einfach sein, wenns ohne Anpassungen funktioniert, das kann kompliziert werden wenn Anpassungen extra für den 486er notwendig sind.

Ich nehm mal an, dass es vor allem im kommerziellen Umfeld nicht sehr viele 486-Besitzer geben werden, die ihr "Schätzchen" auf einen neuen Kernel bringen wollen. Und vermutlich noch weniger, die an so einem Fork arbeiten. Aber immerhin hat man mit Open Software ja diese Möglichkeit.

 

[|L1n3]

Ich nehm mal an, dass es vor allem im kommerziellen Umfeld nicht sehr viele 486-Besitzer geben werden, die ihr "Schätzchen" auf einen neuen Kernel bringen wollen. Und vermutlich noch weniger, die an so einem Fork arbeiten. Aber immerhin hat man mit Open Software ja diese Möglichkeit.

Laut Foristen sind die ja noch sooo verbreitet und überall wo man es nicht vermutet steckt ein 486er drin
Unter der Prämisse, müsste es ja Betreiber dieser Systeme geben, die wieso auch immer ein Interesse daran haben hier Arbeitszeit reinzustecken.
Ich sehe es aber wie du, die Abkündigung kommt ja nicht aus dem Nichts, es ist ja seit Jahren bekannt, dass es irgendwann kommen wird, selbst für die edge Cases, wo man evtl. noch solche Systeme einsetzt, war Zeit genug sich um eine entsprechende Strategie zu bemühen, wie man damit umgeht.
Selbst wenn jetzt Kernel 7.1 damit um die Ecke kommt: Es gibt ja noch offiziell unterstützte Kernel-LTS Versionen, dafür werden ja weiterhin erstmal Patches backported, die dann zwangsweise auch erstmal 486-Kompatibel bleiben müssen. Und falls es ein kommerzielles Linux mit i486 Support gibt (die, die ich kenne haben seit Jahren wenn überhaupt noch nur i686 angeboten), dann haben die ja auch womöglich langfristige Supportfenster ihren Kunden eingeräumt und müssen das selbst pflegen.

Auf irgendwelchen isolierten Geräten, die vermeintlich seit fast 40 Jahren einfach ihren Dienst tun, seh ich sowieso keinen Sinn, das da jemand ständig einen Kernel für kompiliert und raufschaufelt, solang es das was es tun soll zuverlässig macht: Pfoten weg!

 

[empy]

Abwärtstransformationen könnte man auch ausgehend von Assembler leicht vornehmen. Die Übersetzung in Maschinencode erfolgt weiterhin automatisch und wenn man das von joecnstr verlinkte Beispiel mit einer fehlenden 8-Byte-Vergleichsfunktion bei vorhandener 1-Byte-Vergleichsfunktion nimmt, dann kann der in Assembler geschriebene, zu neue Befehl, in einen fixen Satz Maschinencode überführt werden.

Ja, das stimmt natürlich.

Dass dieser dann aus acht Befehlswiederholungen besteht, geht etwas über pure Assemblierung hinaus, bringt mich aber zu obiger Frage zurück: Macht man das nicht schon seit Jahren genau so und könnte es ohne Mehraufwand weitermachen?

Ich denke mal, dass das in aller Regel eben nicht in Assembler geschrieben wurde und dann vom Compiler erledigt wurde.

Wenn ein neues Kernelfragment von AVX512 profitieren soll und man händisch erstmals ein Assembler-Fallback von AVX512 auf AVX2 und AVX1 entwickeln muss, dann hat man einen ordentlichen Batzen Legacy-Arbeit vor sich. Aber die verschwindet halt nicht, in dem man CPUs aus der Kompatibilitätsliste streicht, die zum Teil nicht einmal x87 geschweige denn MMX kennen.

Das nicht, aber es ist halt unter Umständen noch eine Menge Code und ich denke mal, dass auch dieser Code immer mal wieder von irgendwelchen Regressionen betroffen ist.

Klar geht das und vermutlich wird es auch irgendetwas geben. So, wie das schon bei den 386ern der Fall war. Der Punkt ist, dass das dann nicht mehr das Problem des Kernelteams ist, sondern derjenigen, die sich dem Problem annehmen werden/wollen.

Ich meinte ja auch nicht, dass es nicht prinzipiell möglich ist, aber es muss ja einen Grund dafür geben, dass es für die Kompatibilität nötigen Code im Kernel gibt.

Ich glaube hier herrscht etwas Verwirrung was das bedeutet: Gestrichen wird nur die offizielle Unterstützung für 486er Systeme. Das heißt nur: Bei neuen Releases wird der Kernel nicht mehr auf (emulierten) 486er Systemen getestet und dementsprechend wird der Code auch nichtmehr so angepasst, dass er auf 486er Systemen läuft. Es steht jedem weiterhin offen den Kernel auf ein 486er Zielsystem zu kompilieren, ob das dann Fehlerfrei funktioniert ist aber offen.

Dadurch, dass da jede Menge Code rausfliegt, der da vorher sicher nicht zum Spaß noch mitgeschleppt wurde, würde ich das anders verstehen. Dann müsste man schon einen Kernel vor 7.1 forken und eventuelle Patches dahin übernehmen oder halt einen Patch entwickeln, den man auf die neueren Kernel anwenden kann.

Aber bevor ich mich als Betreiber von einem oder mehreren 486ern in solche Kapriolen stürzen würde, würde ich schauen, ob der Support bis 2035 den die Kernel-Version 6.12 bekommen soll, nicht doch einfach noch reicht.

Der cmpxchg8b kann nämlich mit einem Lock-Präfix versehen werden, ist dann atomar und das dient in in Multi-Core-Umgebungen, wie wir sie heute haben, zum Verwalten von Mutex (Prozess-Synchronisation). Man bedenke: der 486 war ein Uniprozessor, der hat so was nicht benötigt!

Hieße das, dass der Code gar nicht 1:1 umgesetzt wird, weil man diesen Befehl, bzw. dessen Atomizität gar nicht anders abbilden kann und man stattdessen einen Ersatzablauf hat, der nur auf Single-Cores läuft und eben einfach ohne den Befehl auskommt?

SSE und AVX werden nicht nur zum Rechnen, sondern auch zum schnellen Kopieren von Speicher verwendet, beides hatte der 486 nicht. Und es gibt sicher Programme, die SSE bzw. AVX inline haben, wenn es schnell gehen muss. Auch müssen diese "Workarounds" in zig Libraries mitgepflegt (und getestet) werden.

Wenn der Compiler das halt nicht übernimmt. Aber vielleicht der Abwärtssupport da auch nicht so groß. SSE statt AVX geht vielleicht noch, aber eine FP-Emulation ist an der Stelle einfach nicht vorgesehen.

Und was soll ein der Kernel-Entwickler (oder Redhat oder SLES, die ja bezahlten Support anbieten) machen, wenn ein professioneller Kunde Kunde mit einem Bug kommt, der auf einem 486-System und nur dort auftritt?

Naja, die meisten Distros haben den Support so alter CPUs doch eh schon längst abgekündigt.

 

[|L1n3]

Dadurch, dass da jede Menge Code rausfliegt, der da vorher sicher nicht zum Spaß noch mitgeschleppt wurde, würde ich das anders verstehen. Dann müsste man schon einen Kernel vor 7.1 forken und eventuelle Patches dahin übernehmen oder halt einen Patch entwickeln, den man auf die neueren Kernel anwenden kann.

Genau so wirds auch gemacht: Wenn nicht schon längst irgendwo geschehen, nimmt man den letzten offiziellen release mit meinem Wunsch-Pflicht-Feature (hier 486-Support) und pflegt ab da einen völlig neuen Codezweig. Wird in den offiziellen Code Änderungen eingepflegt, den ich übernehmen möchte für meinen Fork, dann muss ich diesen backporten, also so anpassen, dass dieser in meinem Fork, der ja auf viel älterem Code basiert, funktioniert.
Das ist ja gang und gäbe bei jeder Art von Distribution, die pflegen ja alle ihren eigenen Kernel, bei RedHat unter anderem 10 Jahre. Sobald da ein Major-Release erscheint wird die darin enthaltene Kernel Version als Basis "festgesetzt", bei RHEL10 ist das Kernel 6.12.0. Und ab hier verantwortet RedHat selbst welche weiteren Änderungen hier einfließen, das kann eigener Code sein, aber vielfach auch einfach Patches, die in die offiziellen Kernel Quellen eingepflegt worden, diese müssen dann eben backported werden, z.b. Sicherheitspatches sofern der eigene Kernel dafür anfällig war. RHEL10 wurde 2025 released und sie versprechen 10 Jahre Support, darüber hinaus sogar einen extra paid extended support. Es wird also auch im Jahre 2035+ vorraussichtlich noch einen neuen Kernel für RHEL10 systeme geben mit der Versionsnummer 6.12.0-xxx.el10
Nur wenige Distributionen basieren wirklich auf dem sogenannten Mainline Kernel, selbst die, die es tun pflegen oft eigene Patches ein.

 

[Registrierzwang]

[...]
Aber die Liste geht weiter: 486 ohne 487 kein natives Floating Point, Pentium Paging-Erweiterungen und und und.
[...]

Nein. Der 486 (nicht der 486SX) hatte bereits eine integrierte FPU. Was die Möglichkeiten eines Pentiums bzgl. PAE angeht, hast Du natürlich recht, auch wenn PAE Unterstützung inzwischen auch wieder obsolet ist.

 

[KleinerLoeschZwerg]

R.I.P. aus dem offiziellen Bereich.

 

[Poulton]

In der Praxis wird es wahrscheinlich irgendeinen Fork geben, der sich weiterhin darum kümmert.

In dem Fall Port. Gibt es auch für Motorolla 68k in seinen ganzen Varianten, was im Embedded Bereich auch seine Verbreitung hat.

Wobei da meist im industriellen Bereich ein BSD verwendet wird.

Da fängt es schon an eng zu werden. DragonflyBSD hat keine Unterstützung mehr für und FreeBSD hat die mit Version 15 gestrichen. Bleiben noch NetBSD und OpenBSD.

 

[KevinSimulinski]

Nein. Der 486 (nicht der 486SX) hatte bereits eine integrierte FPU.

Einen "486" Prozessor an sich gab es nie, das ist eine Klasse von Prozessoren.
Wenn ich es richtig verstanden habe, geht es nicht nur um den von dir erwähnten 486DX, sondern auch um den 486SX, zumindest nach Phoronix:
Ingo Molnar took action and authored a patch that initially gets rid of the CONFIG_M486SX, CONFIG_M486, and CONFIG_MELAN Kconfig build options.
...
The M486SX Kconfig option is for 486-class CPUs without an FPU like the AMD/Cyrix/IBM/Intel SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5S. The M486 Kconfig option is for 486-class CPUs such as the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 and UMC U5D.

Hieße das, dass der Code gar nicht 1:1 umgesetzt wird, weil man diesen Befehl, bzw. dessen Atomizität gar nicht anders abbilden kann und man stattdessen einen Ersatzablauf hat, der nur auf Single-Cores läuft und eben einfach ohne den Befehl auskommt?

Der Befehl muss schon durch den im Link aufgeführten Ablauf umgesetzt werden.
Im Prinzip werden zwei Prozessorregister (EDX:EAX) mit einem Hauptspeicherwert der Länge 8 oder 16 verglichen.
Ein Vergleich ist quasi eine Subtraktion und setzt das Zero-Flag (also gleich/ungleich).
Bei Gleichheit ersetzen zwei andere Prozessorregister (ECX:EBX) den Wert im Hauptspeicher,
bei Ungleichheit wird der Hauptspeicherwert in die zuvor verglichenen Prozessorregister (EDX:EAX) geladen.

Angenommen, ich brauche eine Sperre und definiere: 0 = Sperre offen, Prozess-ID = Sperre zu,
dann lade ich EDX:EAX mit 0 und ECX:EBX mit meiner Prozess-ID und führe die Instruktion aus.
Ist Zero gesetzt, weiß ich, dass im Hauptspeicher die Null stand (0=0 -> Zeroflag gesetzt) und nun meine Prozess-ID in diesem Hauptspeicher steht.
Ist Zero nicht gesetzt, weiß ich das im Hauptspeicher keine Null stand und EDX:EAX enthalten eine andere Prozess-ID, die gerade in diesem Hauptspeicher steht.

Im genannten Ersatz-Ablauf werden Interrupts (dieses Cores/Threads) durch CLI ausmaskiert,
das würde sich in Multi-Core/Thread Umgebungen aber nicht auf die anderen Cores/Threads auswirken.

Bei Compare-and-Swap Instruktionen wird das den Lock-Präfix vermieden, die Instruktion wird atomar:
das Beschreiben dieses Hauptspeicherbereichs durch andere Cores/Threads wird geblockt.

Lange Rede, schwacher Sinn...auf einem Single-Core/Single-Thread Prozessor ersetzt die angegebene Routine den Befehl (abgesehen vom Nonmaskable Interrupt).

In Multi-Core/Thread Umgebungen (erst nach 486SX/DX) ist aber nicht sichergestellt, dass zwischen den beiden CMPL (Compare) und den vier MOVL (Schreiben/Lesen des Speichers) kein anderer Core/Thread ebenfalls seine MOVLs absetzt.
Und damit wäre mein Prozess bzgl. des Inhalts des Hauptspeichers und/oder der EDX.EAX Register in die Irre geführt.

 

[GreenBlue19]

Mir ist auch nicht ganz klar, wie das mit "Um CPUs wie den 486 weiterhin zu unterstützen, sind komplexe Emulationen und spezielle Codepfade nötig" gemeint ist. Erstmal ist der Befehlssatz der 486er CPU kompatibel zu neueren Versionen, es fehlen halt etliche neueren Befehle. Daher muss man nichts emulieren, sondern man muss den Code quasi "unoptimiert" mit ggfls. mehr Befehlen mit dem Compiler generieren.
Spezielle Codepfade sind auch nur dann nötig, wenn man zur Laufzeit entscheiden will, was für eine Library oder was für ein Code generell ausgeführt werden soll. Ich hätte also einfach es so beschrieben, dass der Code mit modernen CPUs ineffizienter ausgeführt wird, weil viele spätere, optimierte CPU Befehle fehlen.

Kann es sein das es dabei noch am ehesten um MMX und SSE1 geht ?

Im Falle von SSE1 müssten dann ja theoretisch auch irgendwann die erheblich schnelleren first Gen Athlon CPUs (argon, pluto/orion und Thunderbird cores) irgendwann mal an der Reihe sein... auch wenn ich mir eher weniger vorstellen kann das sowas irgendwo in nem öffentlichen Automaten sitzt, weil sowas dann wohl viel zu groß und Stromhungrig wäre ...

 

[Titanultra]

Welchen Support den bitte? Da wird ein schlechter Support gestrichen, wow.

 

[EM_EN]

486er Support gestrichen, ja unproblematisch. Verstehe jetzt warum das Thema groß aufgehängt wird. Windows hat dies in den letzten Irritationen selbst nicht mehr unterstützt. Letztendlich verwendet man einen älteren Kernel sofern es sein muss.

 

[T-MAXX]

Wie lange hat Windows eigentlich den 486 unterstützt?

Die i486-Architektur war der Standard für Windows 3.x, Windows 95, Windows 98 und Windows NT 3.x/4.0. Ab Windows XP war dann das Aus mit dem Support.

 

[KevinSimulinski]

Verstehe jetzt <nicht> warum das Thema groß aufgehängt wird.

Weil Ferien sind?

Ab Windows XP war dann das Aus mit dem Support.

Anscheinend haben es aber welche trotzdem zum Laufen gebracht

 

[RiverWolf]

Ich habe die XP Images für 486er auch mal runtergeladen, jetzt fehlt nur noch der 486er..aber die Preise für etwas was nur einstaubt ist es mir nicht wert.

 

[T-MAXX]

Anscheinend haben es aber welche trotzdem zum Laufen gebracht

Ja, aber es ist eben nicht offiziell seitens Microsofts...

 

[KevinSimulinski]

Ja, aber es ist eben nicht offiziell seitens Microsofts...

Da bin ich falsch verstanden worden.
Ich finde es einfach irre, was Menschen zustande bringen, weil der Wille ihr Himmelreich ist.

Ein Windows XP auf 486 im Jahr 2024 macht doch eigentlich keinen rechten Sinn,
auch wenn es sich um "eines der besten Mainboards, die jemals produziert wurden" handelt

Und der Aufwand dafür lässt sich in einem Forenthread ablesen.
Das Ganze lief wohl unter dem Motto "Spaß an der Freude".

 

[PCGH_Torsten]

Nein. Der 486 (nicht der 486SX) hatte bereits eine integrierte FPU. Was die Möglichkeiten eines Pentiums bzgl. PAE angeht, hast Du natürlich recht, auch wenn PAE Unterstützung inzwischen auch wieder obsolet ist.

PAE dürfte keine Rolle spielen, oder?
Entweder ein System hat sowieso nicht genug RAM verbaut, um die Befehle aufrufen zu wollen, oder aber es unterstützt PAE. Im Gegensatz zu vielen anderen neueren Instruktionen, die eine alternative Lösung für immer auftretende Aufgaben sein können, ist PAE ziemlich einseitig und dadurch vor Bedarfs-Fähigkeiten-Mismatch geschützt.

Kann es sein das es dabei noch am ehesten um MMX und SSE1 geht ?

Im Falle von SSE1 müssten dann ja theoretisch auch irgendwann die erheblich schnelleren first Gen Athlon CPUs (argon, pluto/orion und Thunderbird cores) irgendwann mal an der Reihe sein... auch wenn ich mir eher weniger vorstellen kann das sowas irgendwo in nem öffentlichen Automaten sitzt, weil sowas dann wohl viel zu groß und Stromhungrig wäre ...

Irgendwann kommt man immer an einen Entwicklungspunkt, ab dem gewisse Standards vorausgesetzt werden. "Mindestens SSE2" wird genauso kommen, wie Linux aktuell schon bei "mindestens 486" ist und jetzt zu "mindestens 686" wechselt. Und auch dann könnte es ein paar sehr alte Automaten erwischen – nicht mit Athlons, deren Chipsätze wollte damals sicherlich niemand in Systemen mit höchsten Zuverlässigkeitsanforderungen sehen, aber mit Pentium III auf gleichem Tech-Level. (Welche zudem deutlich leichter zu kühlen waren.)
Das ist aber weniger kritisch, denn Pentium III und Athlon waren eben konkrete Prozessoren von Intel und AMD, die beide ihre Produktion lange eingestellt haben und zudem schlimmstenfalls Märkte wie Automaten/Digital Signage bedient haben, wo die Anforderungen schon lange jenseits der Möglichkeiten dieser Chips liegen. Falls sich Linux 2030 von Pentium, 2035 von MMX und dann 2040 von SSE1 verabschiedet, dürften damit ausgestattete Embedded-Systeme 25-30 Jahre alt sein. So alte Automaten sind selten und dann vermutlich längst in der vierte Hand, wo eh niemand mehr neue Software einspielt.

486 dagegen wurde an unzählige Hersteller lizensiert und die Architektur hat nach ihrem Einsatz als PC-Prozessor ein zweites und drittes Leben in zahlreichen Nischen gefunden. Hier mal ein Beispiel für ein schon relativ großes Industrie-Computer-Modul mit DDR2 und einem 800 MHz 486er, dass laut Handbuch-Revisionsdatum 2018 vorgestellt wurde. Hochintegrierte Single-Chip-Lösungen könnten noch deutlich jünger sein und, Stichwort IoT, durchaus auf moderne Betriebssysteme angewiesen sein. Aber auch bei den Lebenszyklen, die SBC-Lösungen und vor allem die damit von anderen Firmen aufgebauten Maschinen haben, ist es sehr wahrscheinlich, dass irgendwo in der Welt letztes Jahr noch ein System mit der verlinkten Technik neu verkauft wurde. Hoffentlich keins, dass auf Linux-Mainline-Support angewiesen ist. Die letzten 486er sind ein, wenn nicht zwei Jahrzehnte jünger als die letzten Thunderbirds.

 

[Registrierzwang]

Ähhh... nur mal so als Hinweis, wie lange Technik (in "embedded systems") eingesetzt wird - die Deutsche Bahn hat ab ca. 1975 Fahrkahrtenautomaten mit Intel 4004 CPUs ausgestattet, die sind bis 1986 gebaut worden, und bis Mitte der 90er Jahre in Betrieb gewesen. Kenne leider kein äquivalentes Beispiel mit der 486er CPU, aber das Prinzip sollte damit klar sein...

 

[PCGH_Torsten]

Produktion 5-15 Jahre nach Chip-Vorstellung, Ausmusterung 25 Jahre danach – ist das Beispiel jetzt ein Wider- oder ein Zuspruch zum gesagten?