Hier eine ziemlich gute Zusammenfassung: https://jaycarlson.net/2019/09/06/whats-up-with-these-3-cent-microcontrollers/ Besonders Interessant: Das FPPA Time Slicing Prinzip
> Besonders Interessant: Das FPPA Time Slicing Prinzip
Leider wurde das aber nicht wirklich zuende gedacht. Bei einem Core ist
die Architektur ganz brauchbar, aber sobald man mehrere FPPA hat, werden
die Unzulänglichkeiten deutlich, insbesondere:
* Es fehlt ein Stapelzeiger-relativer Adressierungsmodus (wie ihn z.B.
der STM8 sehr schön hat).
* Es fehlt ein Compare-And-Swap-Befehl (insbesondere mit indirekter
Adressierung) zur Implementierung von lockless atomics, die für einen
Multicore-µC sher nützlich wären, da sie effiziente Kommunikation
zwischen den Cores und Interrupthandlern ermöglichen.
Da lassen sich Workarounds finden, aber die machen den Code groß,
ineffizient und unschön, oder erhöhen den Programieraufwand.
Philipp Klaus K. schrieb: > Leider wurde das aber nicht wirklich zuende gedacht. Ach wo. Der Fehler, den du gedanklich machst, besteht darin, daß du eben nicht in Assembler denkst, sondern eher in C etc. Es war schon mit den PIC16 so, daß all die Leute, die nur mit C herangewachsen waren, deren Architektur als scheußlich empfanden, weil sie sie schlichtweg nicht verstanden haben. Eben weil sie etwas grundsätzlich anderes erwartet hatten. So auch der oben genannte Autor. Diese Padauk's sind genau so wie die PIC16 eben keine Ein-Register-Maschinen mit W als alleinigem Register, sondern sie sind - sofern man das so formulieren will - eher 128 Register-Maschinen. Schließlich wird der überwiegende Teil aller Operationen direkt in den RAM-Bytes erledigt (ohne Benutzung von W). Der softwareseitige Knackpunkt ist deshalb bei den Padauk's wie auch den PIC16, daß sie auf Assembler-Programmierung ausgelegt sind. Deshalb erscheint es mir als ziemlich blöd, daß Padauk mit der Heimlichtuerei zwischen IDE und Programmierer den Pfad versperrt hat, der von einem anderweitigen Assembler über .hex zum Programmieren führt. Ich hab hier ne Stange PFSxxx herumliegen, habe ebenso meinen eigenen PIC-Assembler und -Programmer auf Basis des hier schon mal geposteten Mini-STM32F103-Projektes und wenn ich irgendwann mal dazu komme, die Programmier-Routinen aus dem Github und die Maschinenbefehle der Padauk's dort mit einzubauen, dann schreib ich mein Gleitkommapaket auch auf Padauk um. Mit sowas ist dann durchaus die Liga all der Kleingeräte (PT100-Thermometer, Paneelmeter, Hand-Frequenzzähler usw.) adressiert. W.S.
W.S. schrieb: > Philipp Klaus K. schrieb: >> Leider wurde das aber nicht wirklich zuende gedacht. > > Ach wo. > > Der Fehler, den du gedanklich machst, besteht darin, daß du eben nicht > in Assembler denkst, sondern eher in C etc. > > […] Ich würde eher sagen, es war ein Fehler von Padauk, nicht an c zu denken. C macht die µC zugänglicher und erhöht die Produktivität der Programmierer. Und zumindest die Kritik an fehlendem compare-and-swap ist unabhängig von C: Für parallele Datenstrukturen und Algorithmen mit geringem Overhead will man lockless atomics, wofür man compare-and-swap will, egal in welcher Sprache man programmiert. Möglicherweise könnte man bei Assembler in Einzelfällen (aber bei weitem nicht allen Anwendungen) auch mit einem compare-and-swap mit direkter Adressierung auskommen, wo man für C indirekte bräuchte. Aber Padauk hat einfach gar kein compare-and-swap.
>Ich würde eher sagen, es war ein Fehler von Padauk, nicht an c zu >denken. C macht die µC zugänglicher und erhöht die Produktivität der >Programmierer. Die MCU ist aber ein Ultra-Low-Cost Design für Massenanwendungen. Es geht darum, Chipfläche zu sparen und das wäre mit einem für C angepassten Design nicht möglich. Padauk hat ja eine Art Pseudo-C-Code Compiler, damit die MCU auch Leute benutzen können, die sich nicht an C heran trauen. Allerdings wird man damit sicherlich die Möglichkeiten nutzen können, die der Prozessor wirklich bietet.
chris schrieb: >>Ich würde eher sagen, es war ein Fehler von Padauk, nicht an c zu >>denken. C macht die µC zugänglicher und erhöht die Produktivität der >>Programmierer. > > Die MCU ist aber ein Ultra-Low-Cost Design für Massenanwendungen. Es > geht darum, Chipfläche zu sparen und das wäre mit einem für C > angepassten Design nicht möglich. Ich glaube nicht, dass Stapelzeigerrelative Adressierung viel an der Chipfläche ausmachen würde. Man könnte z.B., wenn die oberen 2 Bits der Adresse 1 sind, die für den neuen Adressierungsmodus verwenden. Damit würde höchstens ¼ des Speichers nicht mehr direkt adressierbar sein, man würde aber die meisten Vorteile erhalten. Selbst wenn die Implementierung einen zusätzlichen 6-Bit-Addierer erfordern sollte, wäre auf dem Chip wohl noch Platz (selbst bei den kleinsten µC mit nur 8 Anschlüssen, ist wohl die Größe nach unten bereits durch diese Anschlüsse begrenzt): https://youtu.be/5jw5D0F008c Wenn ¼ des Adressraums zu viel erscheint (die kleinsten µC haben einen Adressraum von 64 B, und 64 B oder 60 B Speicher - man könnte also 16 B oder 12 B nicht mehr direkt addressieren) würde selbst ein Achtel für c wohl noch helfen. Allerdings zu den kleinen noch keine Experimente durchgeführt. Wenn man beim pdk15 ebenso die oberen 2 Bit verwenden würde um ¼ des Adressraums zu opfern, und zusätzlich einen Befehl zum Addieren einer Konstante auf den Stapelzeiger hätte, würde man bereits mit kleineren Modifikationen am SDCC-Backend bei reentrranten Funktionen die Codegröße um ca 50% senken¹. Wenn man etwas mehr Zeit in SDCC steckt, wohl noch ein Stück mehr. Philipp ¹ Ausprobiert mit Dhrystone, Coremark, stdcbench - die passen zwar nicht auf den µC, da sie alle 3KB - 5KB RAM brauchen, aber man kann ja trotzdem mal schauen, wieviel Code SDCC generieren würde.
Philipp Klaus K. schrieb: > Ich glaube nicht, dass Stapelzeigerrelative Adressierung viel an der > Chipfläche ausmachen würde. glaube ich auch nicht. Aber diese µC-Kategorie ist ganz klar auf niedrigen Preis hin optimiert. Und das schliesst eben auch die Entwicklungskosten des µC mit ein. Wenn sich Padauk zur genauen Planung des Kerns und seiner Funktionen keine ausreichend erfahrenen Entwickler leisten wollte, die solche fehlenden Features rechtzeitig bemerken und dann ausprobieren, ob das mit der selben Die-Größe lösbar ist, dann spart das halt auch Kosten und Entwicklungszeit. Wenn ich mir dieses "Mini-C" so anschaue, dann habe ich auch nicht das Gefühl daß sich die von Padauk hauptsächlich adressierten Kunden viel um derartige Features scheren. Nur die Geschichte mit dem FPPA ohne die passenden Befehle für die Synchronisation leuchtet mir noch nicht so ganz ein. Ich weiß auch nicht ob die FPPA-Modelle wirklich die Renner bei denen sind. Ich könnte mir vorstellen daß auch die Chinesen bei Bedarf lieber einen dickeren µC einsetzen statt sich mit dem FPPA rumzuschlagen. Nuvoton, Gigadevice, Holtek,... haben da genug im Angebot, selbst STM32er sieht man mittlerweile oft in chinesischen Geräten.
Man darf nicht vergessen, dass sich die Architektur vom PIC ableitet. Der PIC hat sein Leben einmal als "Peripheral Interface Controller" begonnen*. Das merkt man daran, dass die Architektur vor allem darauf ausgelegt ist, mit GPIOS effizient umzugehen. Dafür gibt es eine Vielzahl von Bspezialisierten Befehlen wie SETx, SWAPC, TxSN, bitshifts usw. Wenn es darum geht, Daten in einem Array zu bearbeiten, stößt man schnell an Grenzen. Im Gegensatz zu anderen Akku-basierten Architekturen wie 6502 oder STM8 gibt es z.B. keine richtigen Index-Register. Das Handling der Flags ist auch sehr schlecht durchdacht: Spezialisierte Befehle für Schleifen, wie DZSN, IZSN verändern z.B. das Carryflag. Dadurch ist eine carry propagation in einer Schleife nicht möglich. Zusätzlich ergibt sich keinerlei Nutzen daraus, dass diese Befehle alle Flags verändern. Das ist im 6502 deutlich besser gelöst. Im Gegensatz dazu updated der einzige indirekt load-Befehl IDXM gar kein Flag. Ich habe letztens eine größenoptimierte Funktion zum Ausgeben von Dezimalzahlen programmiert² und musste dabei sehr erfinderisch sein, um um die ganzen Limitationen herum zu arbeiten. Btw - schafft es jemand mit weniger Befehlen? :) *https://en.wikipedia.org/wiki/PIC_microcontrollers ²https://github.com/cpldcpu/SimPad/blob/master/Toolchain/examples/pfs1xx_uartsend/softuart.s#L64
Philipp Klaus K. schrieb: > Ich glaube nicht, dass Stapelzeigerrelative Adressierung viel an der > Chipfläche ausmachen würde. > Man könnte z.B.... Ja, was man alles könnte. Mehr Features, mehr Speicher, mehr MHz, kleinere Strukturen und damit teurere Technologie...und eben mehr Preis. Nö, das alles ist gedanklicher Mumpitz. Wer einen dickeren µC partout haben will, der soll sich einen nehmen, es gibt ja genug davon. Hier haben wir es mit µC-Typen zu tun, die für den einmaligen Gebauch aus der Geburtstags-Klapp-Glückwunsch-Karte ein paar mal "happy birthday to you.." dudeln (bzw. fiepsen) sollen und dafür möglichst garnix kosten dürfen. Euer ganzes Problem bsteht darin, daß ihr allesamt aus der C-Ecke nicht heraus kommt. Entweder weil ihr das nicht wollt oder weil ihr das nicht könnt. Solche µC wie diese kleinen Padauks sind dafür gedacht, in Assembler programmiert zu werden und das sollte man dann auch tun wollen, wenn man sich damit befassen will. Und wer das partout NICHT will, für den gibt's eine reichliche Auswahl an anderen µC. Ich wüßte auch nicht, wozu eine stackrelative Adressierung bei so einem Winzling (mit 128 Byte RAM für alles) gut sein sollte. Wer partout Funktionen mit lokalen Daten habe will, muß dafür eines der 128 RAM-Register opfern: "For indirect memory access mechanism, the data memory is used as the data pointer to address the data byte. All the data memory could be the data pointer; it’s quite flexible and useful to do the indirect memory access. All the 128 bytes data memory of PFS154 can be accessed by indirect access mechanism." Also ein Byte opfern als BasePointer, selbiges auf den Stack retten im Funktionskopf, dann selbiges mit aktuellem Stackpointer belegen und voila, man hat seine stackrelativen Daten. Geht etwa genauso wie im Großen am PC, gelle? _ABER_: Die Returnadressen brauchen je 2 Byte - und dann noch aufwendige Datenstrukturen im Stack, die man stackrelativ adressieren will? Wo soll dafür der RAM herkommen? Ich sehe solche Ideen schlichtweg als unangemessen für diese Chips an. W.S.
Meiner Meinung nach ist das FPPA vor allem dazu gedacht, die spartanische Austattung mit Peripheriehardware zu kompensieren. Die Controller sind für den Einsatz in kleinen Gadgets im Massenmarkt gedacht: Fieberthermometer, Funkuhren, Fernbedienungen. Hier kommt es auf niedrige Hardwarekosten an, nicht auf bequeme und schnelle Programmentwicklung. Der Verzicht auf Hardware-Peripherie ermöglicht genau das: Reduzierung der Chipfläche und damit der Kosten. Parallele Algorithmen oder komplexe Datenstrukturen wird hier niemand brauchen. Da es nur eine CPU gibt, laufen parallele Algorithmen ohnehin nicht schneller als serielle. Man kann in den FPPA-Zeitscheiben aber sehr gut zeitkritische Peripherie in Software implementieren, z.B. einen UART mit Bit-Banging, das Multiplexen von Tasten oder LED's oder das Erzeugen von Tönen für einen Piezo-Piepser. Viele Daten müssen da nicht mit dem Hauptprogramm nicht augetauscht werden, als dass man es nicht von Hand über feste, absolute Variablen oder Pufferzeiger erledigen könnte. Klassisch werden solche Funktionen per periodischem Interrupt realisiert. Spätestens bei mehr als einem solchen kommt es aber zu schwer kontrollierbaren Latenzen, die durch das hardwaregetaktete FPPA vermieden werden. Als Beispiel nehme man eine Tonfrequenzerzeugung bei gleichzeitigem Multiplexen einer Anzeige. Entweder stottert die eine oder flackert die andere, wenn die Interrupt Routinen sich ins Gehege kommen.
Mike schrieb: > Meiner Meinung nach ist das FPPA vor allem dazu gedacht, die > spartanische Austattung mit Peripheriehardware zu kompensieren. Die > Controller sind für den Einsatz in kleinen Gadgets im Massenmarkt > gedacht: Fieberthermometer, Funkuhren, Fernbedienungen. Hier kommt es > auf niedrige Hardwarekosten an, nicht auf bequeme und schnelle > Programmentwicklung. Der Verzicht auf Hardware-Peripherie ermöglicht > genau das: Reduzierung der Chipfläche und damit der Kosten. Ja. Das meiste der Peripherie eines STM8 oder STM32 ist in der späteren Anwendung eh nur tote Fläche auf dem Die, weil nahezu jeder nur wenig Peripherie nutzt. Zusätzliche Cores lassen sich dagegen viel flexibler einsetzen. > Parallele > Algorithmen oder komplexe Datenstrukturen wird hier niemand brauchen. Doch. Zur Kommunikation. > Da > es nur eine CPU gibt, laufen parallele Algorithmen ohnehin nicht > schneller als serielle. > Man kann in den FPPA-Zeitscheiben aber sehr gut zeitkritische Peripherie > in Software implementieren, z.B. einen UART mit Bit-Banging, das > Multiplexen von Tasten oder LED's oder das Erzeugen von Tönen für einen > Piezo-Piepser. Viele Daten müssen da nicht mit dem Hauptprogramm nicht > augetauscht werden, als dass man es nicht von Hand über feste, absolute > Variablen oder Pufferzeiger erledigen könnte. Gehen wir mal davon aus, dass wir den UART-Core nicht nur als dummen UART nutzen, der ein Byte irgendwie auf die Leitung bringt, sondern (damit die anderen Cores nicht warten müssen, wenn sie mehrere Bytes schreiben wollen) als leicht intelligenteren, der über eine Datenstruktur Nachrichten erhält, die dann per UART ausgegeben werden. Schon habe wir eine parallele Datenstruktur, die wir am effizientesten mit lockless atomics implementieren könnten, und dazu einen compare-and-swap-Befehl wollen. Und da mehrere Cores Nachrichten in diese Datenstruktur schreiben, haben wir auch schon eine Funktion, die von mehreren Cores aufgerufen wird. Die ließe sich effizient implementieren, wenn wir Stapelzeiger-relative Adressierung hätten. So bleiben uns als Alternativen ein Lock um diese Funktion (Laufzeitineffizient, blockiert also schlecht für Echzeitsysteme), eine Variante pro Core (Codegrößenineffizient), oder Locks um die einzelnen Verwendungen des "Zeigeregisters" (siehe voriger Post, in SDCC entspräche das dem PSeudoregister p) mit idxm für den Stackzugriff (Laufzeit- und Codegrößenineffizient). Welche der drei Lösungen dann die am wengisten schlechte ist, hängt von den Anforderungen ab.
W.S. schrieb: > Philipp Klaus K. schrieb: >> Ich glaube nicht, dass Stapelzeigerrelative Adressierung viel an der >> Chipfläche ausmachen würde. >> Man könnte z.B.... > > Ja, was man alles könnte. Mehr Features, mehr Speicher, mehr MHz, > kleinere Strukturen und damit teurere Technologie...und eben mehr Preis. Die Strukturen sind schon recht klein (z.B. PFC-Reihe < 0,18 µm). Mehr Peripherie ist kaum nötig. Mehr Mhz sollten in der Tat drin sein (die Dinger lassen sich problemlos ca 50% übertakten, und auch dann scheitert es erstmal dran, dass sich kein größerer Wert mehr einstellen lässt; außerdem sind die Strukturen ja schon deutlich kleiner geworden, ohne dass der Takt erhöht wurde). Eventuell wird irgendwann der reservierte Wert für SYSCLK = IHRC bei manchen tatsächlich genutzt werden (bei manchen Tauchte der schon in manchen Datenblatttabellen auf). Es ist noch ein bischen ungenutzter Platz auf dem Die, selbst bei den kleinsten Typen mit nur 8 Pins und einem Die von einem Viertel Quadratmillimeter. Mehr RAM als 512 B wird ohne größere Änderungen der Architektur schwierig, den könnte man dann nur per idxm adressieren, und wäre dann so ineffizient wie beim Stack (siehe unten). Mehr ROM als 8 KW würde ähnlich schwierig. > Nö, das alles ist gedanklicher Mumpitz. Wer einen dickeren µC partout > haben will, der soll sich einen nehmen, es gibt ja genug davon. > > Hier haben wir es mit µC-Typen zu tun, die für den einmaligen Gebauch > aus der Geburtstags-Klapp-Glückwunsch-Karte ein paar mal "happy birthday > to you.." dudeln (bzw. fiepsen) sollen und dafür möglichst garnix kosten > dürfen. > > Euer ganzes Problem bsteht darin, daß ihr allesamt aus der C-Ecke nicht > heraus kommt. Entweder weil ihr das nicht wollt oder weil ihr das nicht > könnt. > > Solche µC wie diese kleinen Padauks sind dafür gedacht, in Assembler > programmiert zu werden und das sollte man dann auch tun wollen, wenn man > sich damit befassen will. > > Und wer das partout NICHT will, für den gibt's eine reichliche Auswahl > an anderen µC. µC, die man in Hochsprachen programmieren kann, sind deutlich leichter zugänglich, die Programmierer sind produktiver. Von daher ist es sinnvoll, µC Hochsprachenfreundlich zu machen, wenn der Aufwand dazu nicht zu groß ist. Padauks Architektur ist bereits nah dran (für Singlecore erzeugt SDCC ja brauchbarne Code), aber mit sehr wenig Mehraufwand könnte deutlich mehr erreicht werden. > Ich wüßte auch nicht, wozu eine stackrelative Adressierung bei so einem > Winzling (mit 128 Byte RAM für alles) gut sein sollte. Wer partout > Funktionen mit lokalen Daten habe will, muß dafür eines der 128 > RAM-Register opfern: > > "For indirect memory access mechanism, the data memory is used as the > data pointer to address the data byte. All the data memory could be the > data pointer; it’s quite flexible and useful to do the indirect memory > access. All the 128 bytes data memory of PFS154 can be accessed by > indirect access mechanism." > > Also ein Byte opfern als BasePointer, selbiges auf den Stack retten im > Funktionskopf, dann selbiges mit aktuellem Stackpointer belegen und > voila, man hat seine stackrelativen Daten. Geht etwa genauso wie im > Großen am PC, gelle? Nein. Man hat (im Gegensatz z.B. zum ix/iy beim Z80) kein vollwertiges Indexregister. Dieser Zeiger lässt sich nur für den Befehl idxm nutzen, der liest oder schreibt. Ohne Offset, so dass für jedes Byte der Wert im "Indexregister" angepasst werden muss. Und man braucht zwei Bytes, da idxm (vermutlich als Vorbereitung auf künftige µC mit mehr Speicher) mit 16-Bit-Adressen arbeitet. Wenn man SDCC mit --stack-auto aufruft, wird eine solcher Zeiger ("p" im generierten Assemblercode) für Zugriffe auf den Stack genutzt. Aber aus den von mir hier genannten Gründen ist der erzeugte Code dann deutlich größer, als bei nichtreentranten Funktionen. > _ABER_: > Die Returnadressen brauchen je 2 Byte - und dann noch aufwendige > Datenstrukturen im Stack, die man stackrelativ adressieren will? Wo soll > dafür der RAM herkommen? Wenn ich eine Datenstruktur verwende, braucht die eben Speicher. Egal, ob sie auf dem Stack, auf einem Heap liegt, oder einfach eine globale Variable ist. > > Ich sehe solche Ideen schlichtweg als unangemessen für diese Chips an. > C ist eine Sprache, die durchaus auch für kleine und kleinste Zielsysteme geeignet ist. Hier gibt es nun ein kleines, paralleles System; es wäre schön, wenn die Parallelität sich möglichst weitgehend mit Standard-C nutzen ließe.
Philipp Klaus K. schrieb: > Schon habe wir eine parallele Datenstruktur, die wir am effizientesten > mit lockless atomics implementieren könnten, und dazu einen > compare-and-swap-Befehl wollen. Du theoretisierst da was zusammen. Die Realität sieht anders aus. ich geb dir mal ein Beispiel anhand des PIC16, den ich im NWT (aka Funkamateur Netzwerk-Analysator aka Wobbler) steken habe und für den ich mir meine eigene Firmware geschrieben hab. Der kann quasi gleichzeitig (hat nur eine CPU): - Meßergebnisse zum PC senden - Kommandos vom PC empfangen - den Meßablauf durchführen (Generator einstellen, Einschwingzeiten per Timer machen, ADC benutzen, Daten der vorherigen Messung normieren und formatieren und zwischenpuffern zum Senden, Frequenzdaten für den Generator für den nächsten Meßpunkt errechnen) - Statusmeldungen zum PC senden - eine IR-Fernbedienung empfangen und dekodieren - IR-Fernbedienungskommandos zum PC senden So, das Teil kann etwa 3..5 Sweeps zu über 1000 Meßpunkten bei 1 bis 5 Meßkanälen - und das alles mit nur einem einzigen kleinen PIC16 - nun, die Padauk's haben ein paar Befehle mehr, sollten also auch ein bissel mehr können. Parallelarbeit funktioniert, wenn man sie nur ordentlich organisiert. Und dazu braucht man weder Compare und Swap noch lockless atomics, sondern bloß ein wenig ordentliche Ingenieursarbeit. Du scheinst mir einfach zu wenig vertraut mit dem, was diese kleinen Dinger können, wenn man sie in Assembler programmiert. W.S.
@W.S. Da bin ich übrigens genau deiner Meinung. Mutlitasking Systeme vernebeln die Sichtweise und ist was für Leute, die sich über das Timing nicht wirklich Gedanken machen wollen und später dann in Dead-Locks und sporadischen, schwer zu findenden Aussetzern landen. ( Das gilt natürlich nur für Systeme mit einer bestimmten Komplexität ).
Philipp Klaus K. schrieb: > Wenn ich eine Datenstruktur verwende, braucht die eben Speicher. Wenn du eine Datenstruktur verwenden willst, dann braucht die eben Speicher, jaja - aber wenn die Plattform den nicht hergibt, dann kannst du dort eben nicht so programmieren, wie du willst. Also hast du die Alternativen: - dir ne andere Plattform zu suchen - anders programmieren als du willst - es bleiben lassen Philipp Klaus K. schrieb: > C ist eine Sprache, die durchaus auch für kleine und kleinste > Zielsysteme geeignet ist. Das ist eine ganz dumme Parole, die ich schon vor gefühlten 100 Jahren gehört habe. Sie ist schlichtweg nicht wahr. Natürlich kann man sich bemühen, einen Compiler für fast alles zu schreiben, um dann wenigstens ein rudimentäres main() hinzubekommen, aber das ist genauso sinnlos wie der hier schon mal gepostete Versuch, ein Linux auf nem Atmel AVR zu implementieren. Kurzum: es geht nicht NICHT, aber es ist so sinnlos wie ein SUV im Wohnzimmer, um schneller von der Couch zur Hausbar in der Schrankwand zu kommen. W.S.
Assemblerfreaks vs. Compilerentwickler. Da lässt es sich vortrefflich Diskutieren, eine rein objektive Sicht wird wahrscheinlich trotzdem nicht heraus kommen... Zur Sache lässt sich sagen, dass die Padauks immerhin eine große Anzahl an untrennbaren (Atomaren) RMW Operationen auf den Speicher zur Verfügung stellen (XCH, INC, DEC, Shift, uws...). Die Situation könnte wesentlich schlimmer sein, wenn die genannten Befehle z.B. über eine multi-cycles state maschine (6502, 680x, Z80) oder pipeline ohne hazard-detection realisiert würden. Von daher lässt sich den Padauk-Entwicklern nicht vorwerfen, sie hätten sich über die Anforderungen an die Synchronisation keinerlei Gedanken gemacht, auch wenn sie keine dedizierten Spezialbefehle (CAS) anbieten. Ich halte die Padauks für eine sehr elegante Minimalimplementation des Simultaneous-Multithreadings-Konzepts. Auch die eher störende Registerarmut hilft dabei, den Thread-Overhead zu minimieren. Mit steigenden Anforderungen stößt man schnell an Grenzen des Konzepts, welche durch Sonderlösungen und Workarounds abgefangen werden müssen. Das wird bereits bei der multi-cycle Multiplikation deutlich. Ich verweise immer wieder gerne auf XMOS, die das Konzept wesentlich weiter getragen haben. Die inter-thread Synchronisation wird über dedizierte Hardware gehandhabt, welche durch proprietäre Erweiterungen in deren C-Dialekt angesteuert wird. Hier merkt man allerdings, wie schwer die Vermarktung in den traditionellen MCU-Market ist. Sie Beschreiben den Ansatz als "Hardware real-time operating system"... https://www.xmos.com/download/xCORE-Architecture-Flyer(1.3).pdf https://www.xmos.com/download/xCORE-200:-The-XMOS-XS2-Architecture-(ISA)(1.1).pdf https://www.xmos.com/documents/xcore/silicon Inzwischen hat man sich auch auf eine Nischenanwendung zurück gezogen, in der die Architektur anscheinend besonders viele Vorteile hat (Audiolösungen).
:
Bearbeitet durch User
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.