FreeBSD setzt komplett auf Clang/LLVM

  • https://www.golem.de/news/gplv…uptzweig-2003-147020.html


    nach dem Infoteil da geht das leider aber einher mit einer kompletten Einstellung der SPARC64 Unterstützung. Damit fallen dann alle alten und neuen SUNs dort raus und es bleibt für diese Geräte eigentlich kein modernes System übrig - wenn man mal von den nicht so richtig maximal aktiv gepflegten OpenSolaris [WikiP] Abkömmlingen absieht ( wie Illumos oder den deutschen OpenSXCE [/2] ).

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Es steht jedem frei selbst etwas aus Illumos (os/net) zu machen. Persönlich fand ich den Weg von OpenSXCE gut u.a. auch ältere Systeme zu unterstützen.


    Ob SPARC wirklich tot ist, bleibt abzuwarten. SPARC ist ein ISA-Standard und klar sollte sein, dass eine Registerfenster-Architektur (Registerdatei-Stack) gegenüber regulären Registerdatei-Realisierungen einen zusätzlichen Grad an Komplexität mit sich bringt. Nach meinem Ermessen hätte man zwei, separate Register- oder gar Registerfenster-Sätze realisieren sollen, einfach um Supervisor- (Betriebssystem/e) und User-Instruktionen (Applikationen) "sauber" zu trennen. Es werden bei der aktuellen Implementierung und im Standard bzw aus ökonomischen Gesichtspunkten beide Arten von Instruktionen in einem RF-Satz genutzt, was die tatsächliche Anzahl an zu Verfügung stehenden Registern immer einschränkt, aufgrund Nutzung von Sprüngen und für die Reservierung vom OS. Auch wird nicht zwingend bei jedem Func/Proc-Call ein SAVE bzw beim Verlassen dieser ein RESTORE ausgeführt. Es sind noch so viel mehr Details. Da empfehle ich dann die einschlägige Fachliteratur, bspw. dieses Buch hier ist ganz passabel, sowohl für SPARC als auch x86+AMD64:


  • Vermutlich kommt das mit den Registerfenstern eigentlich aus der "rekursiven" Programmierung. Das hat man ja anscheinend in den 70er Jahren gerne gemacht. Wahrscheinlich einfach, weil man den Stack als eine sehr gute Speicherstruktur angesehen hat und/oder gar nicht so große Daten hatte. Da ist dann ein Registerfenster irgendwie eine ganz konsequente Fortsetzung des Ansatzes und "muß" auch einige Stufen haben, damit es sinnvoll wird.


    Der RISC Ansatz mit vielen einzelnen Registern und großen Caches kommt m.E. nachdem bzw. überlappend zum SPARC Entwurf. Bei den ARMs kenn ich das von den frühen zumindest genau so, wie Du es beschreibst: Es gibt einen User-Mode, der eine Handvoll Register (16) einblendet und einen SuperVisor Mode, bei dem einige dieser Register mit anderen "überblendet" werden. Das ist quasi der geforderte doppelte Satz. Daneben gibt es dann noch so einen extra Registersatz, der nur bei der Interruptbehandlung benutzt wird, damit auch das schnell geht.


    Sinnvoll wäre sicher sowas mal auf aktuelle Software abzustimmen - evtl. macht das RISC V ja genau das. Da benötigt man evtl. eine Tiefe von ca. 3-4 Funktionsaufrufen hintereinander. Keine Ahnung, ob ein aktueller Compiler sowas nicht auch einfach auf Nachbarregister verteilt (vermutlich). Was aber bei wenigen Registern und viel Multitasking und haufenweise Extrazeugs, was man so laufen hat, weils geht, aber wohl gar keinen Sinn mehr hat, sind z.B. die "register" Anweisungen in C. Das ist ja wohl vmtl. mal ein sehr cooles und sinnvolles Tool gewesen, bei dem man jetzt überhaupt nicht mehr sagen kann, ob und was es so macht.


    Ich fand, so rein theoretisch, die Register-Fenster immer großartig - keine Ahnung, ob man das von Hochsprachen aus überhaupt gemerkt hat, z.B. im Vergleich zu einer HP oder MIPS Maschine. Noch besser an SPARC war aber wahrscheinlich, daß die ja quasi das Wort Superskalarität erfunden haben. DAS hat wohl richtig merklich was gebracht.



    Irgendwie schade, aber so haben sie von 2010 bis 2020 nochmal 10 Jahre überdauert.


    Apropos: Das coole Violett ist damit als Firmenfarbe wieder benutzbar. Vielleicht hat ja jemand Ambitionen eine deutsche SUN zu gründen. Müßte dann einfach SONNE heißen.


    z.B. Stuttgarter Operatives Neural Network Enhancement ... :)

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Apropos: Das coole Violett ist damit als Firmenfarbe wieder benutzbar. Vielleicht hat ja jemand Ambitionen eine deutsche SUN zu gründen. Müßte dann einfach SONNE heißen.


    z.B. Stuttgarter Operatives Neural Network Enhancement ... :)

    Stuttgart weil Andreas von B. seinen Ursprung im Bundesland Baden-Württemberg hat? :sunny: - Nice!


    Das ursprüngliche, quadratische Logo (U's) war u.a. auch Orange und noch nicht um 45° rotiert, der Schriftzug SUN noch mit Kleinbuchstaben realisiert.


    Superskalarität bei SPARC kam m.W. aus der Forschung und war kommerziell bei SPARC erst mit dem Viking (SuperSPARC-I) ab '91 vertreten.