Moin, aus verschiedenen Gründen (weil ich u.a. eine faule Sau bin) beschäftige ich momentan wieder mit Soft cores der etwas speziellen Art. U.a. auch aufgrund einiger Aspekte, die in http://www.fpgarelated.com/showarticle/46.php näher ausgeführt werden. Muss zur Motivation allerdings noch etwas ausholen und einige Eckpunkte festtackern, dazu am besten gleich einige CPU-Architekturen auflisten: - 'general purpose' MIPS-style: lm32, microblaze, usw. (32 bit opcodes, klassisches Register-File): Nur was für grössere und schnellere FPGAs, aber Toolchain perfekt - ZPU: Stack-Maschine, sehr simpel, beste Code-Dichte, aber je nach Variante langsam, Toolchain sehr robust, aber nicht auf dem neuesten Stand. - J1 Forth CPU: Kleiner geht nimmer, aber C Toolchain fehlt, bzw. nicht sinnvoll - Dedizierte superskalare Parallelverwurster (DSP-Pipes) mit VLIW-Microcode: Völlig ohne Toolchain, aber affenschnell und klein Und der Spass beginnt nun dort, wo man anfängt, die verschiedenen Techniken zu kombinieren, insbesondere unter den Randbedingungen von möglichst geringem Resourcenbedarf, aber noch einer vernünftigen Programmierbarkeit, d.h. gcc ist schon mal Muss Nr. 1. Mein persönlicher Trend geht momentan, aufgrund obigen Artikels in Richtung Hybride aus ZPU/MIPS-ähnlich mit einigen micro-code-Erweiterungen (da kann man im FPGA ja dank Schmankerl wie 9-bit-RAMs einige nette Hacks mit dem zusätzlichen Bit machen, ohne die Toolchain mit den "sliding instruction windows" zu verwirren). Aber nun das Thema mit der Toolchain: GCC aufzubohren ist eine Heidensch*** (insbesondere die Wartung) und mit neueren Dingern wie LLVM habe ich mich noch nicht beschäftigt. Falls also jemand sich schon Gedanken zu der realen Implementierung von einem Hybriden aus Register und Stack-Maschine (also sliding register windows) gemacht hat und auch von der Toolchain her etwas dazu sagen könnte, wäre ich "Alle Ohren". So am Rande: Das Killerlimit liegt etwa bei 1200 LUTs/300 Registern. Noch am Rande: SPARC nutzt ja auch Registerfenster, nur macht die MIPS-Architektur mit ihren 32 Registern durch reine Compileroptimierungen die Performance bei typischen C-Programmen wieder wett. Das Contra bei MIPS-Style auf FPGA ist, dass sie gleich 2 RAM-Bänke a 32x32 bit fressen (Tri-Port-RAM, damit Ops wie r0 = r1 + r2 gehen), oder alternativ mit Distributed RAM nur auf den grossen FPGAs synthetisieren. Der SPARC hingegen frisst mit all seiner Hazard-Logik eine Menge Resourcen. Grüsse, - Strubi
hast du den RISC-V schon gesehen? http://riscv.org/ Ist ein aktuelles Projekt der University of California Berkley OpenSource, BSD Lizens, GCC/GDB/LLVM/Clang...
Nur die Berkley Implementierung ist in Chisel geschrieben...
Lattice User schrieb: > hast du den RISC-V schon gesehen? > > http://riscv.org/ > > Ist ein aktuelles Projekt der University of California Berkley > OpenSource, BSD Lizens, GCC/GDB/LLVM/Clang... Ja, wenn's die Sachen aus der CS152-Schmiede sind, hab ich's mir vor ner Weile mal angesehen. Chisel wollte ich mir allerdings nicht auch noch reinziehen, und nur Verilog als HDL-Transfersprache scheidet aufgrund eines Simulatoraspekts momentan noch aus, da hat MyHDL eindeutig die Nase vorn. So weit ich sehen konnte, gehört deren RISC-Ansatz auch wieder eher in die MIPS-Alike schiene, betr. Code-Dichte dürfte das auch etwa bei MIPS16 liegen. Also nach wie vor noch der einigermassen klassische Ansatz (der ohne Zweifel gut funktioniert), nur ob da die Registerfenster-Technik Sinn macht... Ich bin mit den bisherigen Experimenten eher von einer minimalen Stackmaschine ausgegangen, vermute mal, dass sich letztere besser zu fensterlnden Hybriden aufbohren lassen, aber lasse mich gern eines besseren belehren. Hast Du einen der Cores auf Lattice-FPGAs synthetisiert und kannst Aussagen zu den Timings/LUTs gegenüber lm8 oder lm32 machen? Gruss, - Strubi
Nicht ganz das, was du suchst - aber vielleicht auch interessant als Kompromiss zwischen Größe und Kompatibilität zu existierenden Toolchains: es gibt mit der Supersmall CPU der Uni Toronto eine bitserielle Variante einer 32-bit MIPS-I CPU. Die CPU ist unter BSD-Lizenz und in Verilog entworfen. Details unter http://www.eecg.toronto.edu/~jayar/software/SuperSmallProcessor/ Als serielle CPU ist der Supersmall allerdings arg langsam - wäre spannend, die mal gegen die ZPU zu vergleichen. -- Michael
Von den Soft-Cores habe ich mich eigentlich weitgehend verabschiedet. Das tatsächliche Areal, das noch zwischen anwendungoptimierten virtuellen state machines einerseits und hard implementierten CPUs andererseits besteht, wird enger und enger, weil die harten CPUs immer preisgünstiger und schneller werden und die tool chain dafür steht. Sobald etwas ein bischen dynamischer wird, kommt man von den FSMs weg und hat oft sofort Bandbreitenanforderungen, die von den soft cores kaum leistbar sind oder nicht wirtschaftlich sind. Vor allem die Themen Test und Testbarkeit sowie Validierung deuten eindeutig in Richtung einer bekannten, standardisierten CPU mit stabiler tool chain. Funktionielle Tests lassen sich dann z.B. auch auf uC-Plattformen machen, um Fehlerbilder in FPGA-Quelle und CPP-Quelle aufzutrennen. Klar, lassen sich ganze AVRs und ARMS in FPGAs brennen, um davon zu profitieren, aber wozu? Wer validiert und zertifiziert den Core? Wer validiert die spezielle, anwendungspezifische Modifikation, die Grund war, keinen hard core, sondern einen soft core zu nehmen und diesen anzupassen? In welchen Fällen lohnt das?
:
Bearbeitet durch User
Jürgen Schuhmacher schrieb: > > ... > In welchen Fällen lohnt das? Deine Frage ist sachlich und inhaltlich durchaus interessant. Allerdings hat dieser Thread hier gerade zur Voraussetzung, dass es Gründe gibt, sich damit zu beschäftigen. Falls Du diese Gründe in Frage stellen möchtest, was, wie schon gesagt, ja durchaus seine Berechtigung hat, so mache bitte einen neuen Thread dafür auf.
Michael Engel schrieb: > es gibt mit der Supersmall CPU der Uni Toronto eine > bitserielle Variante einer 32-bit MIPS-I CPU. Die Japaner haben das noch etwas weiter getrieben: Ultrasmall http://lis.ei.tum.de/fpl2014/papers/ps1_05.pdf Duke
Klaus schrieb: > Jürgen Schuhmacher schrieb: >> >> ... >> In welchen Fällen lohnt das? > Es gibt FPGAS mit Hardcores. Doch diese sind auch in Bewegung. PowerCPU aktuell sind ARMs verbaut. Nachdem Altera nun Intel ist ist die Frage was als Hardcore vorzu finden sein wird. Wenn du über mehre Jahre oder sogar Jahrzehnte eine Entwicklung FPGA mit internem Hardcore supporten musst, dann muss die Software mehrfach geschrieben werden. Bei einem Softcore wäre das schmerzfreier möglich.
Jürgen S. schrieb: > Vor allem die Themen Test und Testbarkeit sowie Validierung deuten > eindeutig in Richtung einer bekannten, standardisierten CPU mit stabiler > tool chain. Funktionielle Tests lassen sich dann z.B. auch auf > uC-Plattformen machen, um Fehlerbilder in FPGA-Quelle und CPP-Quelle > aufzutrennen. Da haste schon recht. Es gibt da aber inzwischen etwas Fortschritt. Ich habe die Validierung komplett mit Python erschlagen können. Da gibt es auch einige nette OpenSource-Implementierungen wie Cocotb. Mit Co-Simulation lassen sich auch die GCC-Regtests auf das Simulationsmodell abbilden, somit ist die HW schlussendlich nach einem "full PASS" mindestens so gut wie die GCC-Implementierung. Die Gründe, Softcores einzusetzen, liegen für mich eigentlich gerade in möglichst robusten Anwendungen und Debug-Frameworks. Da haben sich die grossen Hersteller nicht gerade mit Ruhm bekleckert, manchmal habe ich mich da auch schon gefragt, ob da erst auf v0.0 silicon vollständig validiert wird (gerüchteweise: Ja :-), siehe ARM7&IRQ.. ). Aber zurück zum ursprünglichen Gedanken: Es soll ein bisschen akademischer Spass für den Sommer dabei sein, vielleicht nicht gerade zum Exzess wie seriell getriebene ALUs, das ist mir jetzt zu praxisfern. 1000 LUTs und 1-4 DMIPS dürfen es schon sein. Vielleicht muss ich da ein bisschen in Vorleistung gehen mit nem konkreten Beispiel: Die ZPU hat 8-Bit-Opcodes von Haus aus mit 16-17 Instruktionen, die sich sehr gut in VLIW-Microcode interpretieren und auch pipelinen lassen. Manche Operationen sind in der Basis-Konfig bloss durch nativen Microcode (also dem Original-Befehlssatz) emuliert, wie z.B. ein *SHIFTLEFT. Da sich auf dem FPGA-BRAM noch ein weiteres Bit nutzen lässt, liegt es nahe, emulierte Befehle noch effizienter durch proprietären Microcode zu erschlagen (der keine weitere Logik frisst). Das Spiel lässt sich noch weiter treiben über die Windowing-Aspekte, die Yurkovski beschreibt, z.B. wenn "syscall" in einen gewissen Programmbereich springt, sagen wir 0x20000, dient das höchstwertige Bit als Opcode-Erweiterung. Innerhalb der OS-Routinen können dann z.B. harte Register genutzt werden, die die CPU sonst gegen aussen gar nicht hat. Dafür muss ein Divisions-Opcode nicht in den Kernel-Space. Auf diese Weise kann man sich eine recht resourcensparende, aber für ihren Zweck leidlich effiziente CPU zusammenstiefeln, die nicht mehr mit jeder Erweiterung validiert werden muss, der interne VLIW-Mikrocode wird genau einmal validiert, und das war's. Der Rest ist nur noch Interpretationssache bzw. Einbinden der erweiterten Funktionalität, wie z.B. Hardware-Schleifen, oder was auch immer. So, und jetzt der Nachteil: Die Sache ist ungut "In Circuit" zu debuggen, sobald man in den Kernel-Space (die obigen 0x20000) gerät, faktisch müssen gegen aussen erweiterte Opcodes definiert werden. Da bin ich mir gerade noch nicht schlüssig, ob es Sinn macht, den nativen Opcodesatz weiter aufzubohren, oder ev. komplett umzudefinieren und schlicht vom Debugger-Backend interpretieren zu lassen um abwärtskompatibel zu bleiben. Tendenz geht zu letzterem, da sich die Opcode-Decode-Logik dadurch weiter vereinfachen lässt. Noch drastischer würde es mit den Register-Windows, wenn man da schlussendlich die GCC-Registeroptimierung implementieren wollte (was ansich sinnvoll klingt, da GCC prinzipiell auf registerbasierende Architekturen getrimmt ist). Da ist dann faktisch jede Kompatibilität für die Katz und man könnte gleich die RTL für eine neue Prozessorarchitektur implementieren (Ich höre schon: "Ohgott, nicht schon wieder.."). Den Schuh wollte ich mir zumindest in der GCC-Domäne nicht mehr anziehen. Bin allerdings der Meinung, dass es in dieser Nische zwischen klassischem MIPS-Register-Stil (der IMHO kaum noch weiter zu optimieren ist) und der puren Stackmaschine einiges auszuloten gäbe, speziell im Bezug auf FPGAs - wie ja Yurkovski schon vorgemacht hat. Soll also auch kein Market-Survey über extrem logiksparsame CPUs werden. Gruss, - Strubi
Martin S. schrieb: > Hast Du einen der Cores auf Lattice-FPGAs synthetisiert und kannst > Aussagen zu den Timings/LUTs gegenüber lm8 oder lm32 machen? > Habe ich nicht. Den lm8 habe ich mir mal sehr genau angeschaut, diesen zu schlagen bezüglich Resourcenverbrauch dürfte sehr schwer werden. Z.B ist der Registerfile als distributed RAM ausgeführt, was Multiplexer spart. Je nach Konfiguration haben ein paar Register auch eine Hardwarefunktion (Pagepointer), diese sind als FF parallel zum Registerfile implementiert. Die CPU liest trotzdem den Shadow aus dem distributed RAM, auch das spart Multiplexer. Um die ALU mit voller Taktrate füttern zu können, ist der Registerfile doppelt ausgeführt, je einer für die beiden Operanden. Im FPGA gilt: distrubuted RAM ist billig, Multiplexer sind teuer.
Martin S. schrieb: > > Noch drastischer würde es mit den Register-Windows, wenn man da > schlussendlich die GCC-Registeroptimierung implementieren wollte (was > ansich sinnvoll klingt, da GCC prinzipiell auf registerbasierende > Architekturen getrimmt ist). Registerwindows ist nichts neues (SPARC), und der GCC kann damit umgehen auch die Registeroptimierung ist kein Problem. Allerdings ist wegen der Registeroptimierung und Inlining der Vorteil des Registerwindows stark geschrumpft. Man kann daher zu Recht fragen ob sich der Aufwand rentiert. > Bin allerdings der Meinung, dass es in dieser Nische zwischen > klassischem MIPS-Register-Stil (der IMHO kaum noch weiter zu optimieren > ist) und der puren Stackmaschine einiges auszuloten gäbe, speziell im > Bezug auf FPGAs - wie ja Yurkovski schon vorgemacht hat. Soll also auch > kein Market-Survey über extrem logiksparsame CPUs werden. Ich habe mir letzte Nacht die ganze Artikelserie von Yurkovski gelesen (Sehr Lesenswert). Seine Idee besteht darin, die Windows vom Programcounter abhängig zu machen, und nicht wie beim klassischen Registerwindow (SPARC) vom Callsstack.
Moin, lm8 will man natürlich nicht schlagen, dürfte auch mit einem 32-Bitter keinen Sinn machen, da ist die ZPU-Architektur schon minimalistisch genug. Die ZPU kann man schon in der Minimal-Konfiguration mit ein paar Tricks auf ca. 450 LUTs auf dem Spartan3 trimmen. Ansonsten ist der lm8 durchaus interessant, und der '(V)LIW-Trick'sicherlich elegant um beim Decodieren Logik zu sparen. Aber bei der Code-Dichte und grösseren Programmen wird's wohl eng gegenüber ZPU. Die Diskussion SPARC/Windows vs MIPS/harte Registerfiles ist natürlich längst hinfällig bei GCC, nur ging es mir primär ums Aufbohren des GCC-Supports von Stack-Machine zu sliding windows (die ZPU ist mit ihren sp-relativen ops wie STORESP/ADDSP schon nah dran). GCC hat so seine Mühe mit Stackmaschinen und optimiert da nicht sonderlich gut, was allerdings in der Praxis nicht so das Thema ist. Insofern lohnt sich der Aufwand auch nie gegenüber der harten Implementierung oder einem Coprozessor für den speziellen Zweck, wo die CPU fast nur noch DMAs ankickt oder Register konfiguriert.
Martin S. schrieb: > Bin allerdings der Meinung, dass es in dieser Nische zwischen > klassischem MIPS-Register-Stil (der IMHO kaum noch weiter zu optimieren > ist) und der puren Stackmaschine einiges auszuloten gäbe, speziell im > Bezug auf FPGAs - wie ja Yurkovski schon vorgemacht hat. Soll also auch > kein Market-Survey über extrem logiksparsame CPUs werden. Ich hab im Netz ein weiters Interessantes Konzept gefunden welches das klassische Mips-Register mit einer Stackmaschine vermischt: http://techwww.in.tu-clausthal.de/site/Personen/Kemnitz/Publikationen/Stack_Architekture.pdf http://techwww.in.tu-clausthal.de/site/Personen/Kemnitz/Publikationen/Stack_Arch_Folien.pdf (http://techwww.in.tu-clausthal.de/site/Personen/Kemnitz/Publikationen/RISC-Situationsanalyse.pdf) Dort werden die Ergebnisse in einem Schieberegister gespeichert auf das man wie auf ein normales Registerfile zugreifen kann. Wird aber wahrscheinlich schwer das effizient in einer FPGA zu realisieren. Mfg -the Stig
Hi, > > Ich hab im Netz ein weiters Interessantes Konzept gefunden welches das > klassische Mips-Register mit einer Stackmaschine vermischt: > Habs mir mal kurz angesehen und muss noch ne Weile drüber brüten, aber der Link ist prima, den kannte ich noch nicht. Danke! > Dort werden die Ergebnisse in einem Schieberegister gespeichert auf das > man wie auf ein normales Registerfile zugreifen kann. > > Wird aber wahrscheinlich schwer das effizient in einer FPGA zu > realisieren. > Wenn es nur Pop()/Push() neben dem Direktzugriff können muss, geht das recht gut, in ner experimentellen Stackmaschine ('Transputer-Style') läuft das schon so, allerdings gibt es da einige Knackpunkte bei Bitbreite und Anzahl Register, die stark abhängig vom eingesetzten FPGA sind (Timing/Verstopfung). Nur lässt sich leider die komplette ZPU damit nicht emulieren, der POPSP-Befehl ('sp.next = [sp]') macht einem da einen Strich durch die Rechnung, bzw. würde man mit einer Menge Clock-Zyklen bestraft, um den 'hard stack' (das Register-Shift-Register) wieder aus dem BRAM-Shadow aufzufrischen. Heisst also, Sprünge im SP liegen bei der Lösung nicht drin, aber genau das will eigentlich GCC für seine lokalen Variablen (dafür wird die Sequenz PUSHSPADD,POPSP typischerweise benutzt). Schade dass die Arbeit nix zu GCC sagt, aber ist auch ein schönes Weilchen her, seither haben sich ja die RTL-Interna ja komplett verändert.
Martin S. schrieb: > Moin, > > lm8 will man natürlich nicht schlagen, dürfte auch mit einem 32-Bitter > keinen Sinn machen, da ist die ZPU-Architektur schon minimalistisch > genug. Die ZPU kann man schon in der Minimal-Konfiguration mit ein paar > Tricks auf ca. 450 LUTs auf dem Spartan3 trimmen. Ansonsten ist der lm8 > durchaus interessant, und der '(V)LIW-Trick'sicherlich elegant um beim > Decodieren Logik zu sparen. Das (V) hat beim lm8 da nichts verloren. Der Befehlsatz ist klassisch mit 5/6 bits Opcodes aufgebaut. Es ist eine MIPS Architektur, mit dem zusätzlichen EFfect dass es alle 2 Operand Befehler (ADD etc) auch in einer immidiate Variante gibt. Geht halt weil die Befehle viel mehr bits haben. > Aber bei der Code-Dichte und grösseren > Programmen wird's wohl eng gegenüber ZPU. Codedichte weniger, aber grosse Programme sind nicht drin, maximal 4096 Instructions. (Aber 4 GByte Daten addressiern können im large Modell.) Das Problem mit all diesen resourcenoptimierten Cores ist. dass man sie schwer aufbohren kann ohne sofort an die Grenzen der Architektur zu stossen. Für den Umgang mit den Wishbone Hardcores auf dem MachXO2 habe ich mir einen extrem kleinen Core gebastelt (25 Slices), aber der taugt nur zum Datenschaufeln. Den aufzubohren macht aber keinen Sinn, denn 1. kommt dann ziemlich schnell in die Regionen des lm8, und 2. braucht es dann mehr als einen mickrigen Assembler als Toolchain. Ähnliches gilt aus FPGA Anwendungsicht für die ZPU. Die ZPU ist eine auf hohe Codedichte getrimmte Stackmaschine und auch sehr kompakt. Aber halt sehr langsam. Ich sehe das nicht unbedingt als Nachteil, d.h. compact beats speed. Man müsste sich mal den J1 Forth im Vergleich zur ZPU anschauen. PS: Mir ist klar, dass es dir nicht um eine konkreten Anwendung geht, sondern um R&D. Und vielleicht kommt ja dabei auch was raus, ohne R&D kein Fortschritt.
> > Ähnliches gilt aus FPGA Anwendungsicht für die ZPU. Die ZPU ist eine auf > hohe Codedichte getrimmte Stackmaschine und auch sehr kompakt. Aber halt > sehr langsam. Ich sehe das nicht unbedingt als Nachteil, d.h. compact > beats speed. > Naja, da gibt's einige Entwicklung...Alvaro Lopez hat einige interessante pipelined-Varianten entworfen (siehe ZPUino) und meine in-house-Varianten haben gegenüber der original-ZPU4 etwa Faktor 3-8, je nach Konfig. Mehr rauszuholen macht keinen Sinn, dann nimmt man für general purpose besser fertig validierte MIPSies. > Man müsste sich mal den J1 Forth im Vergleich zur ZPU anschauen. > Yurkowsky hat dazu auch ein paar nette Optimierungen dokumentiert, und bremsende Hazard-Logik gibts da nicht, ergo kann man sie recht hoch clocken, aber da reine Stackmaschine (nur Push/Pop), ist GCC-RTL dafür nicht praktikabel. Haben sich schon einige die Zähne dran ausgebissen.. Ansonsten ist die J1 eine prima Vorlage für kleine schnelle uCode-Hacks auch im Hinblick auf das obige "Shift Register". Vielleicht findet sich da irgendwo noch eine Brücke Richtung ZPU-Ansatz und GCC. > PS: Mir ist klar, dass es dir nicht um eine konkreten Anwendung geht, > sondern um R&D. Und vielleicht kommt ja dabei auch was raus, ohne R&D > kein Fortschritt. Naja, die Randbedingungen sind durch die konkreten Anwendungen ziemlich festgelegt, aber der Sommer ist zum Spielen da...
Martin S. schrieb: > festgelegt, aber der Sommer ist zum Spielen da... Ein deutliches Anzeichen für fortgeschrittenes Alter, früher hiess es der Sommer ist zum Baden da... :-)
Martin S. schrieb: > Die ZPU kann man schon in der Minimal-Konfiguration mit ein paar > Tricks auf ca. 450 LUTs auf dem Spartan3 trimmen. Kannst du dazu ein paar Details verrraten?
Moin,
> Kannst du dazu ein paar Details verrraten?
Eigentlich nur Fleissarbeit, wenn ich mich recht erinnere:
- MUXeranzahl auf Minimum reduzieren
- Redundante Inkrements/Adds minimieren
- Debug- und Interrupt Logik rausschmeissen
Man kann wohl die ZPU auch mit 16-Bit-Datenbreite betreiben, gut
möglich, dass man da nochmal 30% einspart.
Die weiteren Tricks sind das vereinfachte Parsen der opcodes per 9. Bit,
da kann man auch Logik sparen, dafür muss das ROM anders generiert
werden. Bisschen ein Hack, und man muss das RAM anders organisieren,
oder Program/Datenbereich splitten.
Der Gewinn gegenüber den momentan ~650 LUTs hat sich für mich im
Endeffekt aber nicht gerechnet.
Grüsse,
- Strubi
Hier gibts eine einfache RISC-V Implementierung für FPGA in Verilog: https://github.com/cliffordwolf/picorv32 Das ganze ist vor ein paar Tagen veröffentlicht worden. Es gibt auch Leistungsdaten für Xilinx FPGAs: <pre> Device Speedgrade Clock Period (Freq.) Xilinx Artix-7T -1 5.1 ns (196 MHz) Xilinx Artix-7T -2 4.1 ns (243 MHz) Xilinx Artix-7T -3 3.6 ns (277 MHz) Xilinx Kintex-7T -1 3.3 ns (303 MHz) Xilinx Kintex-7T -2 2.6 ns (384 MHz) Xilinx Kintex-7T -3 2.5 ns (400 MHz) Xilinx Virtex-7T -1 3.1 ns (322 MHz) Xilinx Virtex-7T -2 2.6 ns (384 MHz) Xilinx Virtex-7T -3 2.4 ns (416 MHz) Core Variant Slice LUTs LUTs as Memory PicoRV32 "small" 855 48 PicoRV32 "regular" 996 48 PicoRV32 "large" 1814 88 </pre>
Hi, eine sehr interessante Diskussion, ich kenne ein paar Projekte die mit stack machines arbeiten, aber das problem ist immer bei den Tools. Es gibt eine britische Firma, die alte Transputer konzepte wieder neu-erfindet. Aber da wird viel geheim gehalten oder man findet nur bits and pieces in Patenten. LLVM ist mit stack machines auch nicht so gut. Und bis man als Entwickler damit arbeiten kann lohnen diese Projekten selten und sterben meistens. Leider!
mmacs schrieb: > LLVM ist mit stack machines auch nicht so gut. Und bis man als > Entwickler damit arbeiten kann lohnen diese Projekten selten und sterben > meistens. Leider! Moin, also gestorben ist es nicht, im Gegenteil. Der aktuelle "Hack" versteht ZPU-opcodes, d.h. man kann auch damit arbeiten (GNU tools). Wenn du konkret mithacken willst, (LLVM support wäre echt nett für div. Erweiterungen), melde dich doch mal bei mir. Gruss, - Strubi
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.