gegenüber solchen mit 8, 16 oder 32 Bit? Bzw. von wie vielen mA sprechen wir hier? Wie stark macht sich die Bitbreite beim Stromverbrauch bemerkbar und könnte man auch sparsame 64 Bit Mikrocontroller bauen, die sich für Kleinstaufgaben eignen, wie sie auch von einem MSP430 (16 Bit) oder PICmicro (8 Bit) oder ATtiny (8 Bit) erfüllt werden? Grund meiner Frage bezieht sich insbesondere auf so Meldungen wie diese hier: https://www.heise.de/developer/meldung/Rust-faehrt-die-Unterstuetzung-fuer-32-Bit-Apple-Plattformen-zurueck-4628635.html Wenn man Programmierfehler, wie sie in C möglich sind, vermeiden möchte, wären Sprachen wie Rust hilfreich. Wenn die Entwickler dieser Sprache aber nicht einmal die Unterstützung von 32 Bit CPUs einplanen, dann bliebe im Mikrocontrollerbereich nur noch ein Verzicht auf diese Sprache oder eine Vergrößerung der Bitbreite bei Mikrocontrollern übrig. Insofern stellt sich die Frage, ob eine Vergrößerung der Bitbreite bei akzeptablem Mehrverbrauch an Strom machbar ist. Texas Instrument gibt bspw. für ihren 16 Bit breiten MPS430 einen Stromvebrauch von 100 uA/MHz unter Last bzw. aktiv an. Würde man so einen µC auf 64 Bit auslegen, würde der Stromverbrauch dann linear, quadratisch oder gar logarithmisch ansteigen?
Nano schrieb: > wären Sprachen wie Rust hilfreich. Wenn die Entwickler dieser Sprache > aber nicht einmal die Unterstützung von 32 Bit CPUs einplanen, dann > bliebe im Mikrocontrollerbereich nur noch ein Verzicht auf diese Sprache > oder eine Vergrößerung der Bitbreite bei Mikrocontrollern übrig. Na, da fällt die Wahl dann doch echt leicht ;o)
Nano schrieb: > Wenn die Entwickler dieser Sprache aber nicht einmal die Unterstützung > von 32 Bit CPUs einplanen, Das steht nirgends geschrieben. Es ist ausdrücklich die Rede von 32-Bit-APPLE-Plattformen. Und auch diese werden nach wie vor unterstützt, nur eben nicht mehr in gleichem Umfang wie bspw. 32-Bit-x86-Linux und -Windows.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Das steht nirgends geschrieben. Es ist ausdrücklich die Rede von > 32-Bit-APPLE-Plattformen. Und auch diese werden nach wie vor > unterstützt, nur eben nicht mehr in gleichem Umfang wie bspw. > 32-Bit-Linux und -Windows. Genau und das liegt hauptsächlich an Apple, weil sich auf neuen MacOS Versionen weder 32-bit Programme ausführe n noch mit XCode bauen lassen...
Yalu X. schrieb: > Das steht nirgends geschrieben. Es ist ausdrücklich die Rede von > 32-Bit-APPLE-Plattformen. Ja, der Grund ist allerdings sicherlich nicht Apple, sondern die Einschränkungen durch 32 Bit. D.h. die anderen Plattformen werden folgen, wenn der Markt nur klein genug dafür geworden ist.
> gegenüber solchen mit 8, 16 oder 32 Bit? > Bzw. von wie vielen mA sprechen wir hier? Da gibt es keinerlei Zusammenhang. Der Stromverbrauch haengt stark von der Faehigkeit der Hardware ab, der Faehigkeit der Entwickler und der Aufgabe die damit geloest werden soll. Stark vereinfachend kann man aber sagen das moderne 32Bit Controller weniger Strom brauchen weil man bei deren Entwicklung staerker auf Stromsparen geachtet hat. Das geht sogar soweit das Renesas jetzt mit den SOTBs einen komplett neuen Prozess vorgestellt hat. > Wenn man Programmierfehler, wie sie in C möglich sind, vermeiden möchte, Naja, man kann Programmierfehler effizienter vermeiden wenn der Entwickler faehiger ist. > wären Sprachen wie Rust hilfreich. Wenn die Entwickler dieser Sprache > aber nicht einmal die Unterstützung von 32 Bit CPUs einplanen, dann > bliebe im Mikrocontrollerbereich nur noch ein Verzicht auf diese Sprache Es ist fuer eine Sprache vollkommen irrelevant wieviel Bit der Zielprozessor hat. Das interessiert allein den Compilerbauer und der koennte den Compiler vermutlich fuer so ziemlich jeden Prozessor bauen wenn er nur Bock drauf hat. > Texas Instrument gibt bspw. für ihren 16 Bit breiten MPS430 einen > Stromvebrauch von 100 uA/MHz unter Last bzw. aktiv an. Wenn ich das richtig im Kopf habe dann liegen die aktuellen SOTBs bei 30uA/Mhz und sind 32Bit. Den Zusammenhang den du zu sehen glaubst denn gibt es so nicht. Olaf
Nano schrieb: > Ja, der Grund ist allerdings sicherlich nicht Apple, sondern die > Einschränkungen durch 32 Bit. Da die Frage im Kontext von ATtiny und MSP430 steht: Worin bestehen bei Mikrocontrollern dieser Anwendungsklasse die Einschränkungen durch 32 Bits gegenüber 64 Bits?
:
Bearbeitet durch User
Olaf schrieb: >> Wenn man Programmierfehler, wie sie in C möglich sind, vermeiden möchte, > > Naja, man kann Programmierfehler effizienter vermeiden wenn der > Entwickler faehiger ist. Das ist weder eine gute Argumentation noch eine gute Basis. Irgendwo habe ich mal einen Vortrag gesehen, wo genau diese Argumentation zerstört wurde, ich finde sie allerdings gerade nicht. Im Kern geht es aber darum, dass selbst gestandene Projekte, die herausragende Entwickler haben, sich solche durch die Programmiersprache bedingte vermeidbare Fehler einschleichen, weil Entwickler eben auch Menschen sind und auch nicht in jedem Augenblick absolut fit sind. Man kann also ledig sagen, dass fähigere Entwickler weniger Fehler machen als Anfänger, aber Fehler machen die auch und sie machen sie selbst aufgrund ihrer Erfahrung trotzdem. >> wären Sprachen wie Rust hilfreich. Wenn die Entwickler dieser Sprache >> aber nicht einmal die Unterstützung von 32 Bit CPUs einplanen, dann >> bliebe im Mikrocontrollerbereich nur noch ein Verzicht auf diese Sprache > > Es ist fuer eine Sprache vollkommen irrelevant wieviel Bit der > Zielprozessor hat. Das interessiert allein den Compilerbauer und der > koennte den Compiler vermutlich fuer so ziemlich jeden Prozessor bauen > wenn er nur Bock drauf hat. Der offizielle Rust Compiler verwendet sogar LLVM bzw. baut darauf auf und trotzdem scheint man diese 32 Bit Apple CPUs nicht mehr unterstützen zu wollen. >> Texas Instrument gibt bspw. für ihren 16 Bit breiten MPS430 einen >> Stromvebrauch von 100 uA/MHz unter Last bzw. aktiv an. > > Wenn ich das richtig im Kopf habe dann liegen die aktuellen SOTBs bei > 30uA/Mhz und sind 32Bit. Interessante Technik, kannte ich noch nicht. > Den Zusammenhang den du zu sehen glaubst denn > gibt es so nicht. > > Olaf Ich hoffe mal du hast recht. Es wäre echt schade, wenn man Rust nicht auf 8 oder 16 Bit µC zukunftsfähig einsetzen könnte.
A. K. schrieb: > Nano schrieb: >> Ja, der Grund ist allerdings sicherlich nicht Apple, sondern die >> Einschränkungen durch 32 Bit. > > Da die Frage im Kontext von ATtiny und MSP430 steht: Worin bestehen bei > Mikrocontrollern dieser Anwendungsklasse die Einschränkungen durch 32 > Bits gegenüber 64 Bits? Vielleicht breitere Register, die man für den Compiler haben will?
Olaf schrieb: > Es ist fuer eine Sprache vollkommen irrelevant wieviel Bit der > Zielprozessor hat Es ist sehr wohl relevant, ob alle Daten + Code in einen linearen Adressraum passen oder nicht. Der AVR-GCC muss ja diverse Verrenkungen machen um die getrennten Flash/RAM Bereiche zu verwalten (__flash und so). Bei einem Zeiger muss man immer wissen, wozu er gehört, weshalb man von Standard C Funktionen mehrere Varianten braucht. Bei 32bit (z.B. ARM) passt alles in einen linearen Adressraum, und man kann alles einheitlich adressieren (passt viel besser zu C). Für Mikrocontroller reichen die 32bit weitgehend aus, weshalb es nicht so viel Bedarf für 64bit gibt. 16bit sind schon wenig, selbst AVRs haben teilweise mehr Speicher als 64kB und müssen mit Bankswitching arbeiten (Krücke - verkompliziert Compiler und C-Programmierung). 24bit reicht für 16 MB, was zwar für vieles reichen würde aber als nicht-2er-Potenz einfach komisch ist... Für 64bit-uC könnte man die ALU und den Bus so bauen, dass 64bit Operationen als 2 sequentielle 32bit Operationen gemacht werden. So würde man weniger Gatter und weniger Strom brauchen, aber die 64bit Operationen werden natürlich langsamer - was nicht ganz so schlimm ist wenn man davon nicht so viele braucht.
Nano schrieb: > Yalu X. schrieb: > >> Das steht nirgends geschrieben. Es ist ausdrücklich die Rede von >> 32-Bit-APPLE-Plattformen. > > Ja, der Grund ist allerdings sicherlich nicht Apple, sondern die > Einschränkungen durch 32 Bit. Sowohl amd64 als auch AArch64 aka arm64 aka avrmv8 haben nicht nur breitere Register, sondern auch mehr davon sowie weitere Architekturverbesserungen, und allein das hilft den Compilern, effizienteren Code zu erzeugen. Das war auch bei IOS die treibende Kraft, auf 64 Bit zu gehen. Rein vom Adressraum her wäre es da zumindest bis jetzt nicht unbedingt nötig gewesen, selbst das iPhone 11 hat nur 4GB RAM. Das Streichen der 32 Bit Untersützung hat bei Apple vor allem das Ziel gehabt, alte APIs nicht mehr pflegen zu müssen (nicht alles wirde auf 64 Bit migriert, vor allem bei Carbon nicht) und zu vermeiden, dass Libs doppelt im Speicher liegen (als 32 und 64 Bit Version). fchk
Nano schrieb: > Vielleicht breitere Register, die man für den Compiler haben will? Immer noch: Wozu soll das gut sein? Die meisten Daten auf 64-Bittern sind 32 Bits breit, weil das LLP64- oder LP64-Modell genutzt wird, bei den Ints 32 Bits breit sind. Lediglich die Pointer sind routinemässig 64 Bit breit, was aber unterhalb einiger GB Adressraum absolut nichts bringt. Willst du den Compiler auf einem 64-Bit ATtiny laufen lassen? Oder willst du dem als Ersatz eines NE555 programmierten ATtiny eine 64 Bit Datenverarbeitung zukommen lassen?
Programmierer schrieb: > Es ist sehr wohl relevant, ob alle Daten + Code in einen linearen > Adressraum passen oder nicht. Der AVR-GCC muss ja diverse Verrenkungen > machen um die getrennten Flash/RAM Bereiche zu verwalten (__flash und > so). Das ist so. Hat aber absolut nix mit der "Bittigkeit" des Controllers zu tun. Sonst könnten 8Bit-Controller nämlich nur 256Byte adressieren, 16Bit-Controller nur 64kB usw... Relevant ist vielmehr erstens die Breite von Indexregistern, denn das ist, worüber Hochsprachen ihr Konzept von Zeigern oder Referenzen umsetzen. Und zweitens, ob es überhaupt einen einheitlichen Addressraum für alle Arten von "Speicher" gibt. Das ist bei praktisch keinem µC und bei praktisch keiner CPU der Fall. Weil es eben oft einen Sinn ergibt, die Adressräume unterschiedlicher "Speicher"arten getrennt zu halten. Wenn die Speichermodelle von Hochsprachen ein Problem damit haben, ist nicht die Hardware schuld, sondern das unvollkommene Sprachkonzept der Hochsprachen. So einfach ist das.
Programmierer schrieb: > 16bit sind schon wenig, selbst AVRs haben teilweise mehr Speicher als > 64kB und müssen mit Bankswitching arbeiten Und TI hat die sehr elegante MSP430 Architektur zu MSP430X vergewaltigt. Wobei das in der Dimension ATtiny nicht wirklich unter den Nägeln brennt. Will man alle µC-Aufgaben mit einer Architektur angehen, egal ob Treppenhauslicht oder Heimautomation, nimmt man 32-Bit ARM und die Sache hat sich. Ein Motiv für 64 Bits sehe ich nicht.
Programmierer schrieb: > Olaf schrieb: >> Es ist fuer eine Sprache vollkommen irrelevant wieviel Bit der >> Zielprozessor hat > > Es ist sehr wohl relevant, ob alle Daten + Code in einen linearen > Adressraum passen oder nicht. Der AVR-GCC muss ja diverse Verrenkungen > machen um die getrennten Flash/RAM Bereiche zu verwalten (__flash und > so). Bei einem Zeiger muss man immer wissen, wozu er gehört, weshalb man > von Standard C Funktionen mehrere Varianten braucht. Bei 32bit (z.B. > ARM) passt alles in einen linearen Adressraum, und man kann alles > einheitlich adressieren (passt viel besser zu C). Für Mikrocontroller > reichen die 32bit weitgehend aus, weshalb es nicht so viel Bedarf für > 64bit gibt. Naja, nur weil der Mikrocontroller einen 8bit Kern hat, heißt das nicht, dass er nur 8bit Adressen hat. Die STM8 Controller z.B. haben einen linearen Adressraum und dafür 3 Addressierungsmodi (short mem mit 8bit, long mem mit 16bit und extended mem mit 24bit Adressen). Aber ein 32bit Kern hat noch mehr Vorteile, es ist beispielsweise recht aufwendig eine Multiplikation von breiteren Datentypen durchzuführen. Eine 16bit*16bit -> 32bit Multiplikation ist bei jeder 8bit Architektur deutlich aufwendiger als 8bit*8bit, bei 32 bit Architekturen aber trivial in meist 1-2 Zyklen machbar.
c-hater schrieb: > Und zweitens, ob es überhaupt einen einheitlichen Addressraum für alle > Arten von "Speicher" gibt. Das ist bei praktisch keinem µC und bei > praktisch keiner CPU der Fall. Weil es eben oft einen Sinn ergibt, die > Adressräume unterschiedlicher "Speicher"arten getrennt zu halten. Doch, viele Mikrocontroller haben einen linearen Adressraum in dem Flash, RAM und Peripherieregister enthalten sind. Dadurch können Konstanten im Flash gespeichert werden, und trotzdem funktioniert ein Zugriff darauf genau gleich, es kann also ein normaler Pointer verwendet werden, um diese zu Adressieren.
> Der offizielle Rust Compiler verwendet sogar LLVM bzw. baut darauf auf > und trotzdem scheint man diese 32 Bit Apple CPUs nicht mehr unterstützen > zu wollen. Das ist dann aber wohl eine Frage von Politik und Resourcen und nicht von der Technik. > Ich hoffe mal du hast recht. Es wäre echt schade, wenn man Rust nicht > auf 8 oder 16 Bit µC zukunftsfähig einsetzen könnte. Du kannst die Sprache bei Microcontroller nicht zukunftsfaehig einsetzen weil dort seit >20Jahren C das Mass der Dinge ist. Du hast jede Menge alten Source in C und du hast jede Menge Entwickler die nur C koennen. Und jeder neue coole Rustentwickler muss auch C koennen weil er sonst mit den altlasten nicht klarkommt. Und wenn er nun schon mal C kann, dann kann man auch gleich bei C bleiben da er ja noch fuenf Arbeitskollegen im Projekt hat die nur C koennen. Das ist dann ein Henne/Ei Problem. > Es ist sehr wohl relevant, ob alle Daten + Code in einen linearen > Adressraum passen oder nicht. Das ist dann allein ein Aergernis fuer den Compilerbauer. Als Entwickler der den Controller programmiert merkst du das doch gar nicht. Fuer maximale Energieeffizienz ist es viel wichtiger ob ein spezieller Controller zu deiner Anwendung passt oder nicht. > 16bit sind schon wenig, selbst AVRs haben teilweise mehr Speicher als > 64kB und müssen mit Bankswitching arbeiten (Krücke - verkompliziert Ich hab jahrelang die M16C programmiert. Die laufen Kreise um die AVRs. Hat aber deutsche Entwickler nie interessiert. Die essen nur ihre gewohnte Currywurst. .-) Oder ein anderes interessantes Detail. Ein SH2A hat 16Registerbaenke. Der ist schneller in einem IRQ und wieder draussen als so oller AVR braucht um nur seine Daten auf den Stack zu schaufeln. Bei Anwendungen mit hoher IRQ-Last sicher ein wichtiges Kriterium oder? Solange man nur eine LED blinken laesst vollkommen egal. Oder moderne Controller die es erlauben das interne Ram in Segmenten abzuschalten. Spart Strom wenn man es nutzen kann, spart nix wenn man das ganze Ram immer braucht. Manche Controller (Silabs/Gecko) haben auch die Faehigkeit den internen RC Oszilator zu kalibrieren. Dann brauchst du den externen Quarz nur noch manchmal. Spart auch Strom wenn man das nutzen kann. Wenn du unter 100uA mittlere Stromaufnahme angekommen bist dann haengt es wirklich sehr davon ab wie der aktuelle Prozessor zu deiner Anwendung passt. Und auch wieviel Zeit die Entwickler in die Optimierung stecken duerfen. Olaf
Alex D. schrieb: > Aber ein 32bit Kern hat noch mehr Vorteile, es ist beispielsweise recht > aufwendig eine Multiplikation von breiteren Datentypen durchzuführen. Es gibt in jeder Grösse gelegentlich den Wunsch, es noch grösser zu machen. Und umgekehrt, Unnötiges wegzulassen. Bei ARM7 war der kombinatorische Multiplizierer optional (das zweite M in ARM7TDMI), weil er Platz brauchte. Im Kleinstbereich wie dem ATtiny4 lässt man den halben Registersatz weg, damit der Chip bei der für diese Chips üblichen alten Fertigungstechnik ins SOT23 Gehäuse passt.
A. K. schrieb: > Worin bestehen bei Mikrocontrollern dieser Anwendungsklasse > die Einschränkungen durch 32 Bits gegenüber 64 Bits? Sie können nur maximal 4 GB RAM adressieren. SCNR
Alex D. schrieb: > Doch, viele Mikrocontroller haben einen linearen Adressraum in dem > Flash, RAM und Peripherieregister enthalten sind. Viele? Mach' bitte mal eine Liste. Und dann mach eine Liste von all denen, bei denen das nicht der Fall ist. Nur, damit du mal ein Gefühl für die tatsächlichen Relationen bekommst...
A. K. schrieb: > Alex D. schrieb: >> Aber ein 32bit Kern hat noch mehr Vorteile, es ist beispielsweise recht >> aufwendig eine Multiplikation von breiteren Datentypen durchzuführen. > > Es gibt in jeder Grösse gelegentlich den Wunsch, es noch grösser zu > machen. Und umgekehrt, Unnötiges wegzulassen. Bei ARM7 war der > kombinatorische Multiplizierer optional (das zweite M in ARM7TDMI), weil > er Platz brauchte. Im Kleinstbereich wie dem ATtiny4 lässt man den > halben Registersatz weg, damit der Chip bei der für diese Chips üblichen > alten Fertigungstechnik ins SOT23 Gehäuse passt. Bei ARM Cortex-M0 hat der Hersteller auch die Wahl, ob er einen 32 Cycle Multiplier oder einen 1 Cycle Multiplier einbaut, aber ich habe noch keinen ARM Cortex M Controller ohne 1 Cycle Multiplier gesehen. Der Kern selbst braucht bei einem solchen Mikrocontroller ja nicht den Großteil des DIEs, RAM + Flash + Peripherie ist deutlich größer (Laut ARM hat ein Cortex-M0 bei 180nm Fertigung ca 0,11mm², allerdings ist das die Minimalversion).
Olaf schrieb: > Ich hab jahrelang die M16C programmiert. Als Ziel für C Compiler ist diese Architektur aber auch eher mau. Wenn man darauf Wert legt. > Die laufen Kreise um die AVRs. Schneller und grösser als für die Anwendung schnell und gross genug hat keinen Nährwert. Mikrocontroller unterliegen deshalb anderen wirtschaftlichen Regeln als PC-Prozessoren. Ein Motiv kann Vereinheitlichung der Entwicklung sein. Hauptsächlich deshalb gibts die kleinen Cortexe, die mit den 8/16-Bittern konkurrieren. Nicht weil man dafür unbedingt 32 Bits braucht. Aber wo ist das Motiv für 64 Bits? Damit man mit einem Apple-PCs einen Mikrocontroller ersetzen kann?
:
Bearbeitet durch User
c-hater schrieb: > Alex D. schrieb: > >> Doch, viele Mikrocontroller haben einen linearen Adressraum in dem >> Flash, RAM und Peripherieregister enthalten sind. > > Viele? Mach' bitte mal eine Liste. Und dann mach eine Liste von all > denen, bei denen das nicht der Fall ist. > > Nur, damit du mal ein Gefühl für die tatsächlichen Relationen > bekommst... Mit linearem Adressraum: - Alle ARM Cortex M Controller - PIC32 - MSP430 (soweit ich gefunden hab, noch nie was damit gemacht) - STM8 Mit getrenntem Adressraum: - AVR - wahrscheinlich noch einige, besonders ältere Architekturen
Komisch, dass noch niemand die eine Mikrocontroller-Architektur aller Mikrocontroller erwähnt hat: 8051. Besonders unter Berücksichtigung der Qualitäten, wie genug Adressräume für jeden und umständliche Adressierung von allem jenseits von 128 Bytes RAM. Trotzdem gibts den weiterhin massenhaft.
:
Bearbeitet durch User
A. K. schrieb: > Komisch, dass noch niemand die eine Mikrocontroller-Architektur aller > Mikrocontroller erwähnt hat: 8051. Genau der fehlte in der Liste wie auch die ganzen Intel-Infineon Nachfolger 251, 80C16x und was alles so entfernt mit x86 zu tun hat: Alex D. schrieb: > Mit getrenntem Adressraum: > - AVR > - wahrscheinlich noch einige, besonders ältere Architekturen Lustig auch, daß beim 8051 nur ein minimaler Stack vorhanden ist, der aber erstaunlicherweise immer ausgereicht hat. Der Keil-Compiler war sehr geschickt in der Optimierung.
m.n. schrieb: > Der Keil-Compiler war sehr geschickt in der Optimierung. Keil gebührt Respekt dafür, einer Architektur leidlich effizientes C nahe gebracht zu haben, die dafür denkbar ungeeignet ist. Aber nachdem es immerhin eine 32 Bit Z80 gibt: Wärs nicht an der Zeit, im Sinne des Threads einen 64 Bit 8051 zu definieren?
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > MSP430 ist die Reinkarnation der 8051 Serie. Vergleich mal das Programmiermodell des MSP430 mit dem der PDP11. Besonders im Bezug auf Adressierungsarten und deren Verwendbarkeit.
Nano schrieb: > Wie stark macht sich die Bitbreite beim Stromverbrauch bemerkbar Siehe "Freescale erlaubt gerade mit dem Flexis QE128 auch den direkten Vergleich von 8 bit CPU zu 32 bit CPU bei ansonsten gleichen Bedingungen, 8 Bit $3,59/10k 11mA, 32 Bit $3,80/10k 27mA. Der 8 Bit hat natürlich bessere Codedichte und es gibt ihn auch optional in kleinerem Gehäuse (wohl wegen kleinerer Chipfläche)." aus www.dse-faq.elektronik-kompendium.de/dse-faq.htm
Nano schrieb: > Wie stark macht sich die Bitbreite beim Stromverbrauch bemerkbar Das kommt u.a. auf die Größe der Strukturen auf dem Chip an. Der dynamische Stromerbrauch ist wegen umzuladender Kapazitäten proportional zur Taktfrequenz.
Olaf schrieb: > Ich hab jahrelang die M16C programmiert. Das kenne ich: So lange dauert es bei mir auch oft, bis das Programm fehlerfrei ist. :)
Ich hab da noch irgendwo eine Masterarbeit rumfliegen, welche sich mit Laufzeit eines Frameworks welches in verschiedenen Sprachen in verschiedenen Testzenarien bezüglich Laufzeit getestet wurde. C++, C, RUST, PASCAL ... Es ist ausgewertet worden wie lange die Implementierung gebraucht hat, wie viele BUGs im Code waren und die Laufzeit der Aufrufe. RUST war wenn ich mich richtig erinnere Faktor 10000 langsamer als C. Hatte mehr Fehler und die Implementierung hat mehr Zeit in Anspruch genommen. Ich behaupte mal RUST kann nicht so schlecht sein, da müssen die Programmierer schon ihren Beitrag geleistet haben. Auch die C++ Ergebnisse waren sehr ernüchternd. Nach dem lesen hatte ich Verständnis dafür warum man sich bei der Linux-Kernel Entwicklung so gegen C++ wehrt. Da wurde ja mal von jemandem gessagt: C++ wäre das kleinere Problem, vor allem wolle man keine C++ Programmierer. Ich kenne auch Implementierungen welche auf Cortex-R5 (600 MHz) und Cortex-A53 (1,2 GHz) laufen. Hier ist es so das ein "Softwaredurchlauf" auf dem R5 ca. 60% waren es glaube der Energie des A53 gebraucht hat. Allerdings braucht es > 3 R5 wenn man so schnell sein will wie der A53 und wird Final beim Stromverbrauch auch schlechter dastehen (Synchronisierung usw. Qualcomm hatte da mal Zahlen, ich glaube die waren bei 64% der Leistung bei Octa Core gegenüber einem hypthetischen 8x schnelleren Singelcore ... ist allerdings ja auch stark von Software/Problemstellung abhängig). Den A53 sollten pro Befehl bezüglich Energieverbrauch nicht primär 64 Bit zu schaffen machen, sondern vor allem dürften es wohl eher MMU, Sprungvorhersage, Stalls, Cache usw. sein. Ich habe die letzen 24 Monate Primär in folgenden Sprachen programmiert: C++ > C > Assembler > Python > BAT/SHELL-Scripte
Olaf schrieb: >> gegenüber solchen mit 8, 16 oder 32 Bit? >> Bzw. von wie vielen mA sprechen wir hier? > > Da gibt es keinerlei Zusammenhang. Der Stromverbrauch haengt stark von > der Faehigkeit der Hardware ab, der Faehigkeit der Entwickler und der > Aufgabe die damit geloest werden soll. Stark vereinfachend kann man aber > sagen das moderne 32Bit Controller weniger Strom brauchen weil man bei > deren Entwicklung staerker auf Stromsparen geachtet hat. Das geht sogar > soweit das Renesas jetzt mit den SOTBs einen komplett neuen Prozess > vorgestellt hat. Renesas ist bei den Halbleiterprozessen in bestimmten bereichen schon immer beeindruckend. Allerdings wurde ihr schneller Flash, der schnelle Cortex-M3 wegen der vielen Stalls hinter RX-Cores zurückfallen ließ ja durch den z.B. ART Accelerator™ von ST schnell belanglos. Aber auch bezüglich Ausbeute sind die recht beeindruckend. Einige übernommene Firmen hatten ja nach Lehrstunden bezüglich der Halbleiterprozesse erschreckend bessere Ausbeuten. Mich hätte da ja schon mal interessiert was die da verändert haben jeweils ... an die Infos werde ich wohl aber niemals kommen :D
Nano schrieb: > gegenüber solchen mit 8, 16 oder 32 Bit? > Bzw. von wie vielen mA sprechen wir hier? > > Wie stark macht sich die Bitbreite beim Stromverbrauch bemerkbar > und könnte man auch sparsame 64 Bit Mikrocontroller bauen, die sich für > Kleinstaufgaben eignen, wie sie auch von einem MSP430 (16 Bit) oder > PICmicro (8 Bit) oder ATtiny (8 Bit) erfüllt werden? > Das hängt vor allem von der verwendeten Technologie ab. Eine 40nm Technologie ist wesentlich sparsamer als eine 180nm Technologie, hat aber in der Regel höhere Leckströme. Ausnahmen bestätigen die Regel. Da die 8-Bitter in der Regel in 180nm oder 130nm gefertigt werden, während 32 Bitter eher in kleiner Strukturen gefertigt werden, sind die 32-Bitter im Betrieb sparsamer, wobei man nicht vergessen darf, dass hier in der Regel auch die Frequenzen deutlich höher sind, was das wieder kompensiert. Dazu kommt aber, dass gerade Speicher relativ hohe Leckströme haben, so dass die größeren Speicher bei den 32-Bittern den Standby-Stromverbrauch hochtreiben. Und PLLs oder USB Schnittstellen, die bei den 32 Bittern häufiger sind, brauchen auch ordentlich Strom. Die 64-Bitter sind dann eher in 65/40nm Strukturen und feiner unterwegs, was den Stromverbrauch weiter senkt. Aber auch hier gilt, dass das durch größere Speicher und höhere Frequenzen kompensiert wird. Zum Teil hat man aber in den feineren Strukturen mitlerweile Massnahmen gegen die Leckströme implementiert, was die Situation wieder verbessert. Ein 32-Bitter, den man mit 8 Mhz betreibt, dürfte daher sparsamer sein, als ein 8-Bitter bei 8 Mhz. Gruß Axel
Axel L. schrieb: > Da die 8-Bitter in der Regel in 180nm oder 130nm gefertigt werden, > während 32 Bitter eher in kleiner Strukturen gefertigt werden, sind die > 32-Bitter im Betrieb sparsamer, wobei man nicht vergessen darf, dass > hier in der Regel auch die Frequenzen deutlich höher sind, was das > wieder kompensiert. Dazu kommt aber, dass gerade Speicher relativ hohe > Leckströme haben, so dass die größeren Speicher bei den 32-Bittern den > Standby-Stromverbrauch hochtreiben. Und PLLs oder USB Schnittstellen, > die bei den 32 Bittern häufiger sind, brauchen auch ordentlich Strom. Bei den STM32 sind auf jeden Fall die F0 und F1 in 180nm gefertigt, G0, L0 und L4 soweit ich weiß in 90nm und H7 in 40nm. Über die meisten 8-Bitter kann ich nichts sagen, allerdings ist zumindest der Attiny13A laut https://zeptobars.com/en/read/atmel-attiny13a in 500nm gefertigt, also gehe ich mal davon aus, dass die meisten AVR Controller in 500nm gefertigt sind.
Axel L. schrieb: > Ein 32-Bitter, den man mit 8 Mhz betreibt, dürfte daher sparsamer sein, > als ein 8-Bitter bei 8 Mhz. Das ist wahrscheinlich falsch. Du bringst in deinen Darstellungen zwei Sachen durcheinander: die dynamische Stromaufnahme und die Leckströme. Ersteres hängt wesentlich vom Takt ab, aber auch von den Gatekapazitäten. Bei gleichem Takt sind die im Vorteil, die die kleineren Gatekapazitäten haben, also die mit der geringeren Strukturgröße. Genau das ist nämlich der Grund, die Strukturgröße zu verringern: um einen höheren Takt erreichen zu können. Blöderweise haben die geringeren Strukturgrößen gleichzeitig den Nachteil, die Leckströme zu erhöhen. Je geringer also der Takt ist, desto mehr sind die Dinger mit den großen Strukturen im Vorteil. Für die Situation mit Takt=0 gibt es bei den schnellen Teilen zur Lösung des Leckstrom-Problems einen "einfachen" Trick: es wird nicht nur der Takt abgeschaltet, sondern auch die Stromversorgung. Aber schon dieser "einfache" Trick ist in Wirklichkeit recht komplex (und damit anfällig für Designfehler). Dazu kommt aber: er hilft nicht für kleinen Takt (aber größer 0). Da knallt der Leckstrom-Nachteil voll rein. Umso mehr, je geringer der Takt.
Nano schrieb: > enn die Entwickler dieser Sprache aber nicht einmal die Unterstützung > von 32 Bit CPUs einplanen, dann bliebe im Mikrocontrollerbereich nur > noch ein Verzicht auf diese Sprache oder eine Vergrößerung der Bitbreite > bei Mikrocontrollern übrig Nein, man kann auch auf 8 bit Controllern eine Sprache so implementieren, dass der Grunddatentyp und Adressbereich mit 64 bit beschrieben wird. Ist natürlich eher resourcenfressender Overkill. Aber Rust ist eh für Kinderprogrammierer, vergiss sie.
MaWin schrieb: > Nein, man kann auch auf 8 bit Controllern eine Sprache so > implementieren, dass der Grunddatentyp und Adressbereich mit 64 bit > beschrieben wird. Ja, das wäre tatsächlich die Lösung. > Ist natürlich eher resourcenfressender Overkill. Das müsste nicht so sein. Schließlich hat die Sprache zur Designzeit bereits alle Informationen über die Speicherbereiche und ihre Eigenschaften. Der Teil wird ja in den gegenwärtigen Backends auch abgehandelt, die mit sowas umgehen müssen. Also sollte es nach den Gesetzen der Logik möglich sein, ein generelles Sprachmodell dafür zu schaffen, welches eine Behandlung ohne Ressourcenfrass zur Laufzeit ermöglicht. Natürlich müsste man sich von der Idee einer universellen Verwendbarkeit von Pointern verabschieden. Aber komischerweise ist genau dies ja eigentlich ein Sprachziel, was mit erstaunlich viel Syntax-Bombast durchgesetzt wird. Da wäre ganz sicher auch noch Platz für "Speicherbereiche" gewesen. Wenn man beim Konzept nachgedacht hätte... C ist Dreck!
Squierrel schrieb: > Auch die C++ Ergebnisse waren sehr ernüchternd. Nach dem lesen hatte ich > Verständnis dafür warum man sich bei der Linux-Kernel Entwicklung so > gegen C++ wehrt. Da wurde ja mal von jemandem gessagt: C++ wäre das > kleinere Problem, vor allem wolle man keine C++ Programmierer. Ich hab eine Master Projekt Arbeit, die das Gegenteil beweist. Der "jemand" was übrigens Linus Torvalds, welcher seine Behauptungen durch den exzessiven Gebrauch von Schimpfworten "belegt". Faktor 10000 ist heftig. Das bedeutet, Rust ist völlig witzlos und für Performance kritische Teile ungeeignet, obwohl es genau dafür intendiert ist - wie z.B. Browser, bei denen es auch verwendet wird. Komisch.
MaWin schrieb: > Nano schrieb: >> Wie stark macht sich die Bitbreite beim Stromverbrauch bemerkbar > > Siehe > "Freescale erlaubt gerade mit dem Flexis QE128 auch den direkten > Vergleich von 8 bit CPU zu 32 bit CPU bei ansonsten gleichen > Bedingungen, 8 Bit $3,59/10k 11mA, 32 Bit $3,80/10k 27mA. Der 8 Bit hat > natürlich bessere Codedichte und es gibt ihn auch optional in kleinerem > Gehäuse (wohl wegen kleinerer Chipfläche)." > > aus www.dse-faq.elektronik-kompendium.de/dse-faq.htm Danke, das sind doch mal Zahlen mit denen man einen Richtwert hat.
Squierrel schrieb: > Ich hab da noch irgendwo eine Masterarbeit rumfliegen, welche sich mit > Laufzeit eines Frameworks welches in verschiedenen Sprachen in > verschiedenen Testzenarien bezüglich Laufzeit getestet wurde. > > C++, C, RUST, PASCAL ... > > Es ist ausgewertet worden wie lange die Implementierung gebraucht hat, > wie viele BUGs im Code waren und die Laufzeit der Aufrufe. > > RUST war wenn ich mich richtig erinnere Faktor 10000 langsamer als C. Von wann war die Masterarbeit? Rust ist noch nicht so alt, das kann gut an fehlender Optimierung liegen. Die neueren Benchmarks die ich bisher so gesehen habe, lassen Rust keineswegs so schlecht dastehen. > Hatte mehr Fehler Dann dürfte das ein noch recht unreifer Compiler gewesen sein, was dann aber auch nicht verwunderlich wäre. Was für eine Version war das?
Axel L. schrieb: > Da die 8-Bitter in der Regel in 180nm oder 130nm gefertigt werden, > während 32 Bitter eher in kleiner Strukturen gefertigt werden, sind die > 32-Bitter im Betrieb sparsamer, wobei man nicht vergessen darf, dass > hier in der Regel auch die Frequenzen deutlich höher sind, was das > wieder kompensiert. Ich hätte jetzt gedacht, dass man zwar ältere FABs durchaus noch für weniger wichtige Chips nutzt, aber man die Fertigungsgröße auch bei den 8 Bittern nachzieht. Denn je kleiner die Strukturen, desto kleiner kann die Die Fläche sein und das senkt die Kosten. Aus China gibt's z.B. Mikroprozessoren zu einem Preis von 3 Cent/Chip. Irgendwie muss das ja zu schaffen sein. Eine Verkleinerung der Strukturgröße wäre hier nahelegend. Lohn- und Energiekosten spielen natürlich auch noch eine kleine Rolle, wobei sich China im Fall von letzterem gegenüber anderen Ländern wie z.B: Südkorea nicht mehr so groß unterscheidet und bezüglich Lohnkosten gehe ich mal davon aus, dass die modernen Fabriken sowieso hochautomatisiert sind. > Dazu kommt aber, dass gerade Speicher relativ hohe > Leckströme haben, so dass die größeren Speicher bei den 32-Bittern den > Standby-Stromverbrauch hochtreiben. Und PLLs oder USB Schnittstellen, > die bei den 32 Bittern häufiger sind, brauchen auch ordentlich Strom. > > Die 64-Bitter sind dann eher in 65/40nm Strukturen und feiner unterwegs, > was den Stromverbrauch weiter senkt. Aber auch hier gilt, dass das durch > größere Speicher und höhere Frequenzen kompensiert wird. > > Zum Teil hat man aber in den feineren Strukturen mitlerweile Massnahmen > gegen die Leckströme implementiert, was die Situation wieder verbessert. > > Ein 32-Bitter, den man mit 8 Mhz betreibt, dürfte daher sparsamer sein, > als ein 8-Bitter bei 8 Mhz. Das ist gut zu wissen. Danke für deine Antwort.
Programmierer schrieb: > Squierrel schrieb: > ... > Faktor 10000 ist heftig. Das bedeutet, Rust ist völlig witzlos und für > Performance kritische Teile ungeeignet, obwohl es genau dafür intendiert > ist - wie z.B. Browser, bei denen es auch verwendet wird. Komisch. Ich tippe auf einen alten Compiler mit geringer Optimierung. Die aktuelle Compilerversion schlägt sich, je nach dem was man testet, recht gut: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
Nano schrieb: > Denn je kleiner die Strukturen, desto kleiner kann die Die Fläche sein > und das senkt die Kosten. Auch da gibt es Grenzen und zwar durch die IO-Zellen. Die werden in deutlich gröberen Strukturen als die minimale Strukturbreite der Logik hergestellt um bestimmte Spannungsbereiche und Treiberstärke zu erreichen. Sobald die Logik komplett in den Bereich des geschlossen IO-Rings passt wird der Chip trotz kleinerer Strukturen nicht kleiner. Ab diesem Punkt müsste man auf Flip-Chip umsteigen. Stattdessen packen die Hersteller mit kleineren Strukturen mehr Logik, z.B. 32 Bit statt 16 Bit, in diese Fläche.
Squierrel schrieb: > RUST war wenn ich mich richtig erinnere Faktor 10000 langsamer als C. > Hatte mehr Fehler und die Implementierung hat mehr Zeit in Anspruch > genommen. Ohne Belege würde ich diese Behauptung mal direkt im Reich der Legenden verorten. Nano schrieb: > Yalu X. schrieb: > >> Das steht nirgends geschrieben. Es ist ausdrücklich die Rede von >> 32-Bit-APPLE-Plattformen. > > Ja, der Grund ist allerdings sicherlich nicht Apple, sondern die > Einschränkungen durch 32 Bit. Warum sollte das denn so sein? Welche Einschränkung sollte das denn sein? Warum gibt es dann nach wie vor Support für 32-Bit Linux (sowohl x86 als auch ARM)?
Beitrag #6128966 wurde von einem Moderator gelöscht.
> Blöderweise haben die geringeren Strukturgrößen gleichzeitig den > Nachteil, die Leckströme zu erhöhen. Je geringer also der Takt ist, > desto mehr sind die Dinger mit den großen Strukturen im Vorteil. Gerade das behauptet Renesas mit ihren SOTB geloest zu haben. https://www.renesas.com/sg/en/solutions/key-technology/sotb/process.html Natuerlich Marketing redet viel und es ist die Frage wie sich das in der Praxis macht, aber ich hab ihr Demokit schon auf dem Tisch. .-) Olaf
Ernst schrieb im Beitrag #6128966:
> Dafür langen einfach beherrschbare 8 Bit, richtig programmiert locker.
Wenn der Automat WLAN o.ä. zur Kommunikation verwenden soll wird das
schon eher schwierig. In WLAN-Modulen sind vermutlich immer 32bit
Prozessoren. Ein solches Modul mit 8bit-Prozessor ansteuern gilt
nicht...
Es ist kann insgesamt einfacher sein, mit einem 32-Bitter Aufgaben zu erledigen, die auch ein 8-Bitter mit links macht, als umgekehrt.
Nano schrieb: > Ich hätte jetzt gedacht, dass man zwar ältere FABs durchaus noch für > weniger wichtige Chips nutzt, aber man die Fertigungsgröße auch bei den > 8 Bittern nachzieht. > Denn je kleiner die Strukturen, desto kleiner kann die Die Fläche sein > und das senkt die Kosten. Ja. Aber: Kleinere Strukturen können dann auch nur kleinere Spannungen ab. Bei den 8-Bit und 16 Bit PICs hat Microchip das auch gemacht. Die neuere laufen intern nur noch mit 2.5 oder 1.8V, und nur der IO-Ring läuft noch mit 3.3 oder 5V. Atmel hats bei den AVRs verpennt. So kleine Designs sind aber pad-bound. Heißt: Die Bondpads und die IO-Treiber bestimmen die Die-Größe, d.h. auch eine kleinere Technologie bringt für die Die-Size nichts mehr. Da kann man dann einfach mehr Logik reinwerfen, oder wie bei den dsPIC33CH einfach einen zweiten Core. fchk
Ernst schrieb im Beitrag #6128966: > Dafür langen einfach beherrschbare 8 Bit, richtig programmiert locker. > Deren potentieller Einsatzbereich ist ohnehin größer als man hier > glauben lassen will. Kann man machen. Würde ich aber nicht mehr machen. Weil ein einfacher 32bit ARM M0/M0+/M1 heute bei gleichen Preis mehr Leistung und mehr Speicher bietet. Die Dinger kosten einfach weniger und man arbeitet auf einer Plattform. Also ich benutze für so gut wie nichts mehr einen 8bitter.
Frank K. schrieb: > laufen intern nur noch mit 2.5 oder 1.8V, und nur der IO-Ring läuft noch > mit 3.3 oder 5V. Atmel hats bei den AVRs verpennt. Wenn man den Finger an einen dsPIC30 hält, der noch nicht so arbeitete, dann weiss man sofort, weshalb Microchip sich diese Mühe machte.
Olaf schrieb: >> Blöderweise haben die geringeren Strukturgrößen gleichzeitig den >> Nachteil, die Leckströme zu erhöhen. Je geringer also der Takt ist, >> desto mehr sind die Dinger mit den großen Strukturen im Vorteil. > > Gerade das behauptet Renesas mit ihren SOTB geloest zu haben. > > https://www.renesas.com/sg/en/solutions/key-technology/sotb/process.html > > Natuerlich Marketing redet viel und es ist die Frage wie sich das in der > Praxis macht, aber ich hab ihr Demokit schon auf dem Tisch. .-) > > Olaf Also auf den ersten Blick sieht deren SOTB Transistor eigentlich gleich aus wie STs UTBB-FD-SOI hier: https://www.st.com/content/st_com/en/about/innovation---technology/FD-SOI/learn-more-about-fd-soi.html
Blechbieger schrieb: > Nano schrieb: >> Denn je kleiner die Strukturen, desto kleiner kann die Die Fläche sein >> und das senkt die Kosten. > > Auch da gibt es Grenzen und zwar durch die IO-Zellen. Die werden in > deutlich gröberen Strukturen als die minimale Strukturbreite der Logik > hergestellt um bestimmte Spannungsbereiche und Treiberstärke zu > erreichen. Sobald die Logik komplett in den Bereich des geschlossen > IO-Rings passt wird der Chip trotz kleinerer Strukturen nicht kleiner. > Ab diesem Punkt müsste man auf Flip-Chip umsteigen. Stattdessen packen > die Hersteller mit kleineren Strukturen mehr Logik, z.B. 32 Bit statt 16 > Bit, in diese Fläche. Danke für die Info.
c-hater schrieb: > Da wäre ganz sicher auch noch Platz für > "Speicherbereiche" gewesen. Wenn man beim Konzept nachgedacht hätte... Da stimme ich Dir zu. Allerdings ist C deswegen nicht "Dreck". Man kann sich jeder Programmiersprache irgendein missing Feature heraussuchen und dann sagen, dass die Sprache Dreck sei. Wenn man aber mal schau, wie lange diese Programmiersprache großflächig eingesetzt wird, muss man schon erkennen, dass sie (warum auch immer) zu den erfolgreichsten aller Zeiten gehört. Dein geliebtes Assembler kennt übrigens auch keine unterschiedlichen Pointer-Typen für Speicherbereiche. PS: Wo ist eigentlich deine Homepage oder dein Buch, wo du dich mal so richtig gründlich über C ausgekotzt hast? Dann könntest du darauf verweisen anstatt Dir immer wieder die Mühe zu machen, dich mit neuen Hassbeiträgen lächerlich zu machen.
Unfassbar schrieb: > Also ich benutze für so gut wie nichts mehr einen 8bitter Du bist ein ganz toller Hecht. Wahrscheinlich programmierst du auch alles noch in Assembler. Auf Hochsprachenebene kann es einem nämlich egal sein, wie viel Bits der ausführende Prozessor hat. Da benutzt man einfach den billigsten uC der den Job erfüllt.
> Also auf den ersten Blick sieht deren SOTB Transistor eigentlich gleich > aus wie STs UTBB-FD-SOI hier: Kannte ich noch garnicht. Irgendwie ist der Vertrieb von ST relativ muede. Kann mich garnicht erinnern ob die schonmal in der Firma zu besuch waren. Aber es zeigt natuerlich auch mal wieder das so allgemeine Aussagen Familie A mit xbit braucht mehr Strom als Familie B mit ybit Unsinn sind. Da steckt einfach zuviel drin. > Wenn man aber mal schau, wie lange diese Programmiersprache großflächig > eingesetzt wird, muss man schon erkennen, dass sie (warum auch immer) > zu den erfolgreichsten aller Zeiten gehört. C hatte zu Anfang einfach den Vorteil am besten das Hirn der vorhandenen C-Programmierer anzusprechen. Und C war sehr frueh verfuegbar: https://de.wikipedia.org/wiki/BDS_C Und danach war die Sprache einfach immer schon da. Ich koennte mir auch schoeneres vorstellen. Aber gleichzeitig bin ich froh das es embedded nur eine Sprache gibt. Es waere doch zum kotzen wenn es da genauso einen Wirrwar gaebe wie auf PCs. Olaf
Programmierer schrieb: > Olaf schrieb: >> Es ist fuer eine Sprache vollkommen irrelevant wieviel Bit der >> Zielprozessor hat > > Es ist sehr wohl relevant, ob alle Daten + Code in einen linearen > Adressraum passen oder nicht. Der AVR-GCC muss ja diverse Verrenkungen > machen um die getrennten Flash/RAM Bereiche zu verwalten (__flash und > so). Das liegt aber nicht an dessen Bitbreite, sondern daran, dass er zwei getrennte Speicherbusse hat, um auf beide gleichzeitig zugreifen zu können. > 16bit sind schon wenig, selbst AVRs haben teilweise mehr Speicher als > 64kB und müssen mit Bankswitching arbeiten (Krücke - verkompliziert > Compiler und C-Programmierung). AVRs sind aber keine 16-Bit-Prozessoren. > Für 64bit-uC könnte man die ALU und den Bus so bauen, dass 64bit > Operationen als 2 sequentielle 32bit Operationen gemacht werden. Welchen Vorteil hätte man dann noch von den 64 Bit? Abgesehen davon: Wie machst du eine 64-Bit-Multiplikation mit nur zwei 32-Bit-Operationen?
Olaf schrieb: > Und danach war die Sprache einfach immer schon da Ich ergänze: und sie erfüllt ihren Zweck nach wie vor. Diese beiden Punkte zusammen werden wohl ausschlaggebend sein. Olaf schrieb: > Aber gleichzeitig bin ich > froh das es embedded nur eine Sprache gibt. Ich glaube, das stimmt nicht so ganz. Mir falle da spontan noch diese ein: C++ (Arduino, Symbian), Basic (Bascom), Java (Android), Python (ESP32)
Rolf M. schrieb: > Das liegt aber nicht an dessen Bitbreite, sondern daran, dass er zwei > getrennte Speicherbusse hat, um auf beide gleichzeitig zugreifen zu > können. Linearer Adressraum und getrennte Speicherbusse schließen sich nicht gegenseitig aus. Alle ARM Cortex M3/M4/M7 Kerne haben einen I-Bus und einen D-Bus, die einfach an anderen Adressbereichen liegen, trotzdem kann darauf mit den gleichen instructions zugegriffen werden.
Rolf M. schrieb: ... > >> Für 64bit-uC könnte man die ALU und den Bus so bauen, dass 64bit >> Operationen als 2 sequentielle 32bit Operationen gemacht werden. > > Welchen Vorteil hätte man dann noch von den 64 Bit? Abgesehen davon: Wie > machst du eine 64-Bit-Multiplikation mit nur zwei 32-Bit-Operationen? Vielleicht um Chipfläche zu sparen. Das wäre ja nicht neu: http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html Vermutlich kommen daher die "Halfcarry"-Flags in vielen 8-Bittern.
Carl D. schrieb: > Vermutlich kommen daher die "Halfcarry"-Flags in vielen 8-Bittern. Nope, das kommt von BCD-Rechnung.
Carl D. schrieb: > Rolf M. schrieb: > ... >> >>> Für 64bit-uC könnte man die ALU und den Bus so bauen, dass 64bit >>> Operationen als 2 sequentielle 32bit Operationen gemacht werden. >> >> Welchen Vorteil hätte man dann noch von den 64 Bit? Abgesehen davon: Wie >> machst du eine 64-Bit-Multiplikation mit nur zwei 32-Bit-Operationen? > > Vielleicht um Chipfläche zu sparen. Das wäre ja nicht neu: > http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html > Vermutlich kommen daher die "Halfcarry"-Flags in vielen 8-Bittern. BTW, über den Z80-Designer sagten Kollegen, daß er für jeden Zusatzbefehl genau vorhersagen konnte, wieviel Platz das zusätzlich braucht.
Meine Frage war nicht, warum man es intern 32-bittig macht, sondern warum man es dann überhaupt nach außen hin als 64-Bitter erscheinen lassen will. Ein µC wird in der Regel keinen 64-Bit-Adressraum brauchen, und wenn dann auch keine echten 64-Bit-Rechenoperationen zur Verfügung stehen, was hab ich dann davon?
A. K. schrieb: > Carl D. schrieb: >> Vermutlich kommen daher die "Halfcarry"-Flags in vielen 8-Bittern. > > Nope, das kommt von BCD-Rechnung. Was man mit 4-Bit einfacher hinbekommt, als mit 8. was man auch hinter dem Link lesen kann, zum Thema "bessere BCD-Unterstützung Z80 vs 8085".
Wo ist eigentlich in diesem Zusammenhang "nach aussen hin"? Viele µCs haben aussen nur I/O-Pins.
Rolf M. schrieb: > Ein µC wird in der Regel keinen 64-Bit-Adressraum brauchen, > und wenn dann auch keine echten 64-Bit-Rechenoperationen zur Verfügung > stehen, was hab ich dann davon? Adressraum und Rechenregister sind zwei paar Schuhe. Bei Prozessoren <32bit war das noch sehr offensichtlich.
Carl D. schrieb: >> Nope, das kommt von BCD-Rechnung. > > Was man mit 4-Bit einfacher hinbekommt, als mit 8. Marginal. Das war sicher nicht der Grund. Zumal eine 4-Bit ALU bei einem 8-Bitter weniger häufig ist als das half carry. Eine 4-Bit ALU kenne ich nur von der Z80.
:
Bearbeitet durch User
Beitrag #6129576 wurde vom Autor gelöscht.
Beitrag #6129582 wurde vom Autor gelöscht.
A. K. schrieb: > Wo ist eigentlich in diesem Zusammenhang "nach aussen hin"? Es ging um diese Aussage: Programmierer schrieb: > Für 64bit-uC könnte man die ALU und den Bus so bauen, dass 64bit > Operationen als 2 sequentielle 32bit Operationen gemacht werden. Es wurde also vorgeschlagen, einen µC so zu bauen, dass sowohl das Rechenwerk, als auch der Bus intern nur 32-bittig ist, er sich aber dem Programmierer gegenüber (und das meinte ich mit "nach außen hin") als 64-Bitter präsentiert. Und meine Frage dazu war, was das bringen sollte. Stefan ⛄ F. schrieb: > Rolf M. schrieb: >> Ein µC wird in der Regel keinen 64-Bit-Adressraum brauchen, >> und wenn dann auch keine echten 64-Bit-Rechenoperationen zur Verfügung >> stehen, was hab ich dann davon? > > Adressraum und Rechenregister sind zwei paar Schuhe. Ja, aber man wird heute sicherlich keinen Prozessor mehr bauen, der eine 64-Bit-ALU, aber nur einen 32-Bit-Adressraum hat.
Rolf M. schrieb: > Es wurde also vorgeschlagen, einen µC so zu bauen, dass sowohl das > Rechenwerk, als auch der Bus intern nur 32-bittig ist, er sich aber dem > Programmierer gegenüber (und das meinte ich mit "nach außen hin") als > 64-Bitter präsentiert. Und meine Frage dazu war, was das bringen sollte. In dieser Dimension wohl nichts. Aber vielleicht bringt ARM ja mal einen Cortex M-1, dessen 32-Bit ISA intern platzsparend bitseriell implementiert ist. Wär nicht neu, die 8-Bitter Motorola 6804 und der SC/MP von NS waren intern bitseriell.
Carl D. schrieb: > Rolf M. schrieb: > ... >> >>> Für 64bit-uC könnte man die ALU und den Bus so bauen, dass 64bit >>> Operationen als 2 sequentielle 32bit Operationen gemacht werden. >> >> Welchen Vorteil hätte man dann noch von den 64 Bit? Abgesehen davon: Wie >> machst du eine 64-Bit-Multiplikation mit nur zwei 32-Bit-Operationen? > > Vielleicht um Chipfläche zu sparen. Das wäre ja nicht neu: > http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html > Vermutlich kommen daher die "Halfcarry"-Flags in vielen 8-Bittern. Das war zu den Zeiten interessant, als so ein Prozessor das einzige Bauteil auf dem Die war. Heute ist da noch der Speicher (Flash und RAM) sowie jede Menge Peripherie drauf. Die CPU ist nicht so besonders groß im Vergleich. Gruß Axel
Axel L. schrieb: > Carl D. schrieb: >> Rolf M. schrieb: >> ... >>> >>>> Für 64bit-uC könnte man die ALU und den Bus so bauen, dass 64bit >>>> Operationen als 2 sequentielle 32bit Operationen gemacht werden. >>> >>> Welchen Vorteil hätte man dann noch von den 64 Bit? Abgesehen davon: Wie >>> machst du eine 64-Bit-Multiplikation mit nur zwei 32-Bit-Operationen? >> >> Vielleicht um Chipfläche zu sparen. Das wäre ja nicht neu: >> http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html >> Vermutlich kommen daher die "Halfcarry"-Flags in vielen 8-Bittern. > > Das war zu den Zeiten interessant, als so ein Prozessor das einzige > Bauteil auf dem Die war. Heute ist da noch der Speicher (Flash und RAM) > sowie jede Menge Peripherie drauf. Die CPU ist nicht so besonders groß > im Vergleich. > Das war ja nicht die Frage. Wenn weiter oben zu lesen war, daß die IO-Treiber/Pads den Hauptanteil der Chipfläche ausmachen, dann kann man gut nachvollziehen, warum man gerne noch einen Parallel-32-bit-Multiplizierer zum ARM dazu baut, denn selbst wenn der 50% der CPU-Fläche ausmacht, dann ist das kaum was in Vergleich zur Gesamtfläche. Zum Thread-Thema: 32-Bit ist genug um alles in einem linearen Adressraum ansprechen zu können, typische μC-Rechnungen ohne Reguster-/Befehlssplit hinzubekommen und damit einhergehende Synchronisationsprobleme zu umgehen. Manchmal (oft?) reicht auch weniger, aber mehr stört nur die Puristen.
> Ich glaube, das stimmt nicht so ganz. Mir falle da spontan noch diese > ein: C++ (Arduino, Symbian), Basic (Bascom), Java (Android), Python > (ESP32) Aehem...ich dachte Embedded und ohne Bastler. Da hab ich bisher ausschliesslich C gesehen. Gelegentlich kommt mal die Frage auf ob man nicht auch C++ nehmen koennte, aber irgendwie versandet das immer... Olaf
Olaf schrieb: >> Ich glaube, das stimmt nicht so ganz. Mir falle da spontan noch > diese >> ein: C++ (Arduino, Symbian), Basic (Bascom), Java (Android), Python >> (ESP32) > > Aehem...ich dachte Embedded und ohne Bastler. Da hab ich bisher > ausschliesslich C gesehen. Gelegentlich kommt mal die Frage auf ob man > nicht auch C++ nehmen koennte, aber irgendwie versandet das immer... > > Olaf Hast du mal geguckt, was alles für Luftfahrt, Raumfahrt und Smartcards verwendet wird?
Jemand schrieb: > Olaf schrieb: >>> Ich glaube, das stimmt nicht so ganz. Mir falle da spontan noch >> diese >>> ein: C++ (Arduino, Symbian), Basic (Bascom), Java (Android), Python >>> (ESP32) >> >> Aehem...ich dachte Embedded und ohne Bastler. Da hab ich bisher >> ausschliesslich C gesehen. Gelegentlich kommt mal die Frage auf ob man >> nicht auch C++ nehmen koennte, aber irgendwie versandet das immer... >> >> Olaf > > Hast du mal geguckt, was alles für Luftfahrt, Raumfahrt und Smartcards > verwendet wird? In Fliegern sicher ESP, dann kann man sich dank Wifi die fehleranfälligen Verdrahtung der Sensoren sparen. PS: Wer sich aufregt, sollte seinen Ironiesensor kalibrieren lassen.
Olaf schrieb: > Da hab ich bisher > ausschliesslich C gesehen. Auf SIM-Karten läuft Java. C++ geht auch sehr gut. Rolf M. schrieb: > Ein µC wird in der Regel keinen 64-Bit-Adressraum brauchen, Darum ging's - große Mengen an Speicher über 4GB ansteuern, weil 64bit-Operationen selbst nicht so wichtig sind.
Carl D. schrieb: > Wer sich aufregt, sollte seinen Ironiesensor kalibrieren lassen. Man darf dann aber den Ironiesensor vorher nicht anhand von Information über Boeings internes Netzwerk der 787 kalibirieren. https://www.darkreading.com/vulnerabilities---threats/boeing-787-on-board-network-vulnerable-to-remote-hacking-researcher-says/d/d-id/1335463
A. K. schrieb: > Carl D. schrieb: >> Wer sich aufregt, sollte seinen Ironiesensor kalibrieren lassen. > > Man darf dann aber den Ironiesensor vorher nicht anhand von Information > über Boeings internes Netzwerk der 787 kalibirieren. > https://www.darkreading.com/vulnerabilities---threats/boeing-787-on-board-network-vulnerable-to-remote-hacking-researcher-says/d/d-id/1335463 Ja, Netzwerk gibt es auch als Kabel, aber davon hab ich nicht geschrieben ("Wifi").
Programmierer schrieb: > Rolf M. schrieb: >> Ein µC wird in der Regel keinen 64-Bit-Adressraum brauchen, > > Darum ging's - große Mengen an Speicher über 4GB ansteuern, weil > 64bit-Operationen selbst nicht so wichtig sind. In einem µC? Nenn mir doch mal einen, der auch nur annähernd an die Grenze kommt.
Carl D. schrieb: > Zum Thread-Thema: 32-Bit ist genug um alles in einem linearen Adressraum > ansprechen zu können, [...] > Manchmal (oft?) reicht auch weniger, aber mehr stört nur die Puristen. Variablen brauchen dann mehr Platz im Speicher. 64 Bit sind immerhin 8 Byte. Fuer z.B. einen Boolean-Wert. Byteweiser Speicherzugriff kann helfen, aber ob der Chipdesigner auch 16- & 32-Bit-Zugriffe vorsieht? Alignment?
Maxe schrieb: > aber ob der Chipdesigner auch 16- & 32-Bit-Zugriffe vorsieht? Bei einer für Mikrocontroller vorgesehenen Architektur wärs schon seltsam, käme die ohne sie? Bei DEC Alpha und den ersten ARM-Generationen wurden manche Teilwortzugriffe "vergessen". Beide legten nach.
:
Bearbeitet durch User
Maxe schrieb: > Carl D. schrieb: >> Zum Thread-Thema: 32-Bit ist genug um alles in einem linearen Adressraum >> ansprechen zu können, [...] >> Manchmal (oft?) reicht auch weniger, aber mehr stört nur die Puristen. > > Variablen brauchen dann mehr Platz im Speicher. 64 Bit sind immerhin 8 > Byte. Fuer z.B. einen Boolean-Wert. Byteweiser Speicherzugriff kann > helfen, aber ob der Chipdesigner auch 16- & 32-Bit-Zugriffe vorsieht? > Alignment? Aber den Unterschied zwischen n*2 und n*2^32 kann man schon erkennen, oder?
Carl D. schrieb: > Das war ja nicht die Frage. Wenn weiter oben zu lesen war, daß die > IO-Treiber/Pads den Hauptanteil der Chipfläche ausmachen, dann kann man > gut nachvollziehen, warum man gerne noch einen > Parallel-32-bit-Multiplizierer zum ARM dazu baut, denn selbst wenn der > 50% der CPU-Fläche ausmacht, dann ist das kaum was in Vergleich zur > Gesamtfläche. Das bezog sich auf einen 8-Bitter in einer 40nm Technologie.
Maxe schrieb: > Byteweiser Speicherzugriff kann > helfen, aber ob der Chipdesigner auch 16- & 32-Bit-Zugriffe vorsieht? Selbstverständlich beherrschen sowohl 32bit-ARM als auch 64bit-ARM 8, 16, 32 und 64bit-Zugriffe. Somit wird hier nix verschwendet. Die Architektur stellt entsprechende Alignment-Anforderungen, welche die Compiler aber korrekt umsetzen, sofern man korrekten Code schreibt.
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.